Notes on Simplicity

First, some inspiration.

Three simple improvements which anyone can understand. RAF planes take off more easily by using a ramp at the end of an aircraft carrier's flight deck. Ski jumpers fly further if they splay their skis. A turned up tip at the end of an aircraft wing improves long-haul efficiency.

I don’t know who came up with these ideas, whether by accident or design, or what percentage improvement they were on what was there before. I just love the simplicity of each of them.

Why Simplicity is a good thing

Because it’s cheap and it’s knowable.

There are established reasons for Simplicity in Extreme Programming. A simple design needs less documentation. It’s easier to improve a simple design than to build perfection from day one. Others have explained these better before. I thought I’d add these two reasons.

Simple things are often cheap in themselves, cheaper to develop and make less expensive the things around them. The ski jumper above has paid no more for his skis to use the splayed pose. The aircraft carrier ramp reduces the overall size of the ship, because it does not need the catapult technology used by the Americans.

And cheap is good because either (a) you get to spend more of the budget on comfy chairs and faster computers, or (b) because it increases the number of people who can get involved in the programming community. Your preference for (a) or (b) may say a lot about you, by the way.

Simple things are easy to use. You can just see what they do, you know how to use them. Whether that’s a door bell or a database connection, the simpler it is to use the better. Steve Krug’s book on web usability Don’t Make Me Think is brilliant on this subject, even down to the title telling you everything you need to know. Web sites must not need manuals – they should just work as the man on the Clapham omnibus expects them to work.

I illustrate this by contrasting two kitchen items made by Hackman in Finland. On the left we have the bottle opener. It’s a joy to use, fits in the hand, reassuring weight so you know you won’t bend it, and it opens bottles. On the right is the salt cellar. It dispenses salt. It’s lovely to use as long as you don’t have wet hands or arthritis. You can distinguish it from the pepper grinder because the little dot on the top is white not black (that’s not visible in the photo). And after owning one for six years I finally found how to fill it with salt without dismantling it completely.

My point is that simplicity and minimalism are not the same thing. You want to see enough of how something works, not too much and not too little. At that point it becomes knowable.

How to get into a simple frame of mind

You could do a Maths degree. I’ve talked to people with English degrees, History degrees and so on, and there was nothing in their university course that was simple – that was the whole point. In my Maths degree we were taught various simple techniques to make complicated problems soluble. Substituting a value in a formula, proof by induction, a single counter example. Use any of these in the right way and you have the answer. Just as significantly, we were taught to celebrate that simplicity.

A three year Maths course may be a bit much. Alternatively, I recommend looking for the simpler thing all the time, in everything you do. Is the music you listen to simple? If the food you eat simple? Do you talk simply? Practice simplicity everywhere and it will get easier.

Let’s start with music. I’m listening to Yo-Yo Ma playing Bach’s cello suites. That’s one man, one cello, no need for anything else. Of course it’s not simple in the sense of trivial. But it is simple in comparison with a whole orchestra bashing out some symphony. There’s no distraction, no waste, just purity.

Apply that to your art form of choice. Realise that The Lord of the Rings, both the book and the film is complexity gone mad. Whereas Doctor Seuss’s Green Eggs and Ham is a masterpiece of simplicity, needing a vocabulary of only 50 words. If that’s too great a disjunction for you, put Moby Dick alongside Bartleby. Prefer Picasso’s single line sketches to Guernica. Go to stand up comedy rather than Shakespeare.

Now food and drink. The best coffee is just coffee. Un espresso in Italy, un café in France. Starbucks is the enemy of this simplicity, all flavours and froths. Just say no. Pasta with a home made tomato sauce is a fine dish. If a dish on a restaurant menu has a two line description using words new to you, then it’s not going to help you to embed a simple mindset.

In conversation, the same thing. Congratulate yourself every time you speak simply. If someone asks a question carefully, a simple "yes" or "no" may be all the answer required. You’re failing if the person you’re talking to needs a word explained, so watch for saying "heuristic" if "guideline" would do just as well.

Do this today and tomorrow. By the weekend you’ll have examples of the simple thing you admire, the moment you took the simple path. It may be a door handle. It may be a three-second input that saved someone three hours. Well done, you kept it simple.

What this means to me as a programmer

Here’s a simple test for you. At a bookshop, pick out the "for Dummies" book on a subject you know about. Flick through it. See what you think.

I went for C for Dummies by Dan Gookin. Here’s a quotation. "Don't forget the ampersand (&) required in front of the variable used in a scanf statement. Without that & there, the program really screws up." I like that. I don’t think the book should be discussing exactly what happens without the ampersand, it should just be drumming the point home that leaving it out is bad bad bad. There’s some discussion about how a preprocessor works but it’s prefaced with "Long, tedious information that you want to miss". As you’re learning C, the important thing is to know to use #define MAXLENGTH 200, not the curious behaviours possible of #define MAX(x,y) (x>y?x:y).

OK, here’s the uncomfortable truth. If you get cross that the surface is being skated over, that the authors are missing out crucial stuff, that no-one should ever read “Firewalls for Dummies”, then you may have to admit you don’t like simplicity. I remember Kent Beck saying that the five values of XP can be used as a test. If a person or an organisation does not intrinsically believe in communication, for instance, then XP is not for them. If you don’t like simplicity, maybe you shouldn’t be doing XP.

Time for a few examples.

Multiple returns from a function can be good. They support simplicity because the moment you have the answer you quit the function. The dogmatists who hate the following coding style are not keeping it simple.

int MyFunction( int param )
{
 if( param <= 0 )  
  return 0;
 for( int i = 0; i < param; i++ )
 {
  if( MySecondFunction( i, param ) )
   return i;
  if( MyThirdFunction( i, param ) ) 
   return i;
 }
 return 0;
}

Database normalisation can be bad. Simple data tables tend to have lots of columns and a fair amount of data duplication. This makes them easy to query – no need for joining multiple tables together. And it makes them tolerant of poor input. If someone puts in an incomplete address, for instance, a simple database design will hold what was entered, whereas a normalised design requiring county or state to be chosen from a predefined list will fail.

Refactor a bit and then stop. Merciless refactoring can take too much time, or just set up too much expectation amongst the programmers. To quote from an Apple report presented at Agile 2006, "refactor … only on demand, when the code is grossly missing the intended functionality or needs major optimization." Beware the salt cellar example where “simplicity” tipped over into minimal unusability.

Enough already

Some people find that the perfection of "simple" solutions makes simplicity difficult to practice. To them I say, "enough". You practice simple design by doing "enough design up front". Ask yourself what "enough" would be in a context, and you’re headed down the simple path.

If a ten-minute build is proving difficult, a simple solution may be beyond your reach. An "enough" solution is to work round a 30 minute build. Then let the team find a rhythm which hits the build button at convenient moments – first person to arrive, at the start of lunch, before any meeting.

A good example came over lunch at Agile 2006. One delegate wanted help with introducing continuous integration. Other delegates, who really knew their stuff, gave him chapter and verse on Subversion, Tortoise, Nant, Cruise Control and the kitchen sink. All I did was to ask how big his company was. When told three people, I suggested that an "enough" solution might not need all of the above.

The great thing about an enough solution is you can improve it the next day. The London Transport map is a classic of design, working from the realisation that it did not need distances to be shown consistently. Even then, the simplicity matured over many years and many editions, as the designers understood how to use their concept. Again it can be carried too far. New Yorkers hated a subway map that took the London Underground approach and simplified Central Park to just a square.

The End

That’s enough from me. Simplicity is good because it is cheap and knowable. Practice it in everything and it will get easier in your work. Enough may be enough – don’t force yourself to over do it.