This article in Dr. Dobbs claims an obsession with code simplicity exists among some (i.e. agile) programmers. It refers to that old received hacker wisdom that any fool can write complex code, but it takes real talent to write simple code. The author attacks this point of view, saying that in reality some problems are genuinely complex and must be implemented in complex code.

I happen to agree that inherently complex problems sometimes can’t be reduced to “simple” solutions. I wasn’t aware any developer seriously thinks any different.

But I also think that this analysis misses the point. As I understand it, this old wisdom refers to problems that do have a simple solution, but require some time and skill to work out. I think every programmer can hark back to their very earliest coding days and recall the typical quality of programs from their youth. Or maybe they have a colleague who couldn’t give a stuff about code quality and sees what sort of code they produce? In any case, a solution that’s not sufficiently thought-out prior to implementation tends to become a mass of multiple-level if-statements, endless switch-case blocks or functions hundreds of lines long.

I see a striking similarity with writers. They also need to produce something that’s simple to digest, ideally so that the reader becomes so absorbed in the story they lose all awareness that they’re actually reading.  Rare is the writer who composes a novel by jumping straight into the implementation without any planning. Writers who do, as J. R. R. Tolkien famously did, will usually get into a mess. (Unconventionally, Tolkien wrote Lord of the Rings with lots of ideas but without any detailed story plan and had to restart multiple times. Luckily for us, he persisted and got his story worked out in the end.)

A writer needs to develop certain skills — like plot development, pacing, characterisation — and use these to compose a “plan of action”. Once that’s done, everything is in place: the characters are worked out, their relationships with one another are established, what happens when is settled, and so on. With a plan in place, the actual writing practically takes care of itself and the writer can focus purely on making the prose pleasurable to read.

Similarly, a programmer has a set of skills that he/she uses to analyse the initial problem, using their knowledge and experience to anticipate probable hotspots of complexity, and work out the steps, structures and relationships to mitigate them. If, let’s say, your new e-commerce app has to deal with different sales tax rates, it’s very easy to just choose between rates by way of a switch statement because we learn about switching very early in our programming career.

switch (country) {
  case UK:
    return 17.5;
    break;
  case IRELAND:
    return 23.0;
    break;
  // etc
}

But experienced programmers know that some parts of any program are volatile, changing often in response to new requirements. Just imagine that this e-commerce application became widespread and suddenly had to support the tax rates of more and more countries. Or maybe additional types of tax suddenly needed to be taken into account. The code could potentially become horrific.

As an alternative to switch statements, you could use a strategy pattern to implement taxation instead, sub-classing each variant. This would make the resulting program simpler and less brittle. But the pattern approach means you would need to possess knowledge about patterns, and patterns aren’t learned quickly or easily.

This example illustrates what I’ve always taken this old wisdom to mean. I’ve seen a fair few inexperienced programmers by now (I was one once), and I’ve even known a few coders who just didn’t give a damn about writing simple code. Their efforts, even when an alternative, simpler solution existed, was usually a nightmarish example of code spaghettification. With knowledge, experience and the right attitude, their solutions would no doubt have been much less complex.

Still, there’s plenty of room for agreement here, specifically the article’s championing of readability. Even some of the best programmers forget that source code is somewhat like a novel – a story from one coder to another. Like a novel, the source code should be a pleasurable read too… but I’m not convinced readability comes before simplicity. It wouldn’t matter how beautiful the writer’s language — if their story was a structurally complex mess then I would be putting it back on the bookshelf pretty quickly.