The Wolf in Sheep’s Clothing

The idea of simplicity has been on my mind a lot recently. I have yet to meet a developer who doesn’t believe in it. So everyone believes in simplicity, shouldn’t we have a lot of simple code? Well, no. The other thing that every developer I’ve ever met agrees with is that there isn’t enough simple code out there. This implies a few possibilities:

  1. Programmers don’t believe in simplicity as much as they claim.
  2. Programmers don’t agree on what simplicity is.
  3. Programmers mistake other things for simplicity.

I ultimately think our situation is a combination of these three things. Numbers 1 and 2 are just the nature of the beast. Sure, everyone wants simple code, but let’s face it: deadlines can make that difficult. And the fact that very few people can define simplicity (and I don’t claim to be one of them) much less agree what it is makes it even harder.

But number 3 is the nasty one. I see it all the time. I’ve even done it myself (I know that’s probably hard for you guys to imagine ;). There’s one thing that I see people confusing with simplicity over and over again: expediency.

In the interest of full disclosure, I think it’s important to note that I haven’t found a good definition of simplicity in the context of software development. But I do know that whatever it is, it isn’t expediency.

Now, business types and “product people” love expediency. And who can blame them? Their job is to make sure a product gets created. Granted, I think they underestimate how important good code is to building a product, but that’s a different subject. Plus, I’m the first person to advocate working smarter rather than harder. I’m not necessarily saying expediency is bad.

The problem is when we confuse simplicity and expediency. Expedient solutions are easy to create. Truly simple solutions are easy to maintain and expand. Sometimes solutions areexpedient (easy to create) and simple (easy to maintain). But more often that not, you have to consider the tradeoffs. Do you create something to meet your immediate needs, or do you create something that will meet your future needs?

All I’m getting at is this: it would be really cool if people said “I don’t think we have time for a solution that simple.” rather than playing the simplicity card for themselves. After all, it would be the truth. And I think it would make sure that you aren’t confusing simplicity with expediency.