The Courage to do things Simply

In my second professional programming job, I had a really interesting boss. When we had a design meeting, we would all sit around a whiteboard, and as Roger (my boss) threw out things we needed to accomplish, the other programmers and I would propose solutions, and Roger would say, “Really? What if you just did X?”, where X was some absurdly, ridiculously, jaw-droppingly simple thing.

Of course, X wouldn’t always work; oftentimes one of us would find a hole in his idea. We’d all then try to fix the hole, but at some point the idea started to become too complicated for Roger’s taste. “How about Y?” Still ridiculously simple, and tantalizingly close to working.

Oftentimes, he “cheated”, by redefining the problem itself to make it a simpler problem to solve, or forcing the problem to fit some existing available solution. We would continue in this vein until the solution was so simple it hardly seemed like any work to actually implement, or it became absolutely clear that the problem would not yield to simplicity. In which case we simply packed it in for the day on trying to solve that problem, and we’d hit it again on another day.

I think that sometimes people think I’m into complexity for its own sake, but that’s really not true. If you see me delving into complexity, it’s only when I’m after the simplicity that sometimes lies on the far side. Sometimes, the differences in things that a program needs to do can mask their underlying secret symmetry, and if you can tease that symmetry out into the open, you can improve the design by simplifying it on both the inside and the outside. The most innovative software products are often not those that merely add new features, but those that discover a new way to approach a problem: one that makes it simpler, such that fewer features are needed in the first place.

Insofar as I can use Roger’s work as a minor example, he had designed a real estate referral tracking package with a field called “Follow-up Date”. He had intentionally chosen this name, because he noticed that people had two different ways of thinking about when to follow up with someone about a referral. One way was to plan ahead by scheduling the next date to follow up, and the other was to follow up with people who hadn’t been contacted a while. With a couple of tweaks to the name, he was able to get it to be what he called “clearly ambiguous”.

This meant that people who think in terms of scheduling would conclude that “Follow-up Date” obviously meant the date they planned to follow up, while at the same time, people who think in terms of keeping contacts fresh would think it clearly meant the date you’d last followed up. Since the software was only used by one person in a given real estate office, (most could only afford one computer at those days’ prices) the ambiguity didn’t cause any “tastes great/less filling” debates within an office, but the benefits we gained were many.

First, since the target machines were dual-floppy TRS-80’s with 48K of RAM, having to have only one field was really important from a technical perspective; it could have significantly reduced the software’s processing capacity to have another field. Second, being able to do things the way the user thought about them was good for sales. During a presentation, you’d just elicit whichever way they did their follow-up, and then you just presented the right way to do it with the software.

But back in those days, I didn’t yet understand the virtue of simplicity. One of my first projects for the company was to port that software and several other products from the TRS-80 to the new IBM PC. At the time, I was 17 and had just discovered the idea of program generators: programs that write programs. So naturally I thought it was the ideal way to go about porting; load up the database schema and generate PC programs from them. Roger, however, had wanted me to write a PC version of the database runtime (ProFile) they used on the TRS-80. But I thought that I could do “better”.

In hindsight gained long after, I realized that Roger’s approach had been simpler, and also that simplicity is not so easy to judge. The long-term effect of my approach was that we couldn’t just prototype new products on a PC-based database runtime, as we could have if I’d done as he asked. I hadn’t yet learned to think of the spinoffs and secondary effects of my design choices.

It took many years of study under Roger’s keen eye before I began to develop the ability to “see” those consequences and effects. I say, “began to”, because you never really stop, and because at first all you really need to know is how to tell when you’ve done something wrong. (Which is surprisingly hard to tell, sometimes. How do you know you’re not still writing with a brick tied to your pencil, after all? Comparing to your colleagues doesn’t help; they might be writing with bricks too!)

Sometimes, a minor tweak to a system produces great benefits; the difference of an inch can be the difference, as Twain put it, betweeen “lightning” and “lightning bug”. If you compare the complexity of the mainframe financial software that VisiCalc replaced, with the simple spreadsheet that replaced it, well, that’s where you’ll find that simplicity on the far side of complexity, and it makes all the difference in the world.

Roger, by the way, was not a programmer by trade. He was a teacher, mostly of learning disabled children. Patience, simplicity – and doing whatever it takes, no matter how absurd – were his watchwords. I owe him a lot for the things he taught me, but today I especially give thanks for the gift of simplicity, and for the courage to ask “What if we just did X? Would that work? Would it be simpler? What else might we gain?”.