Simplism

Every red-faced technical debate that I’ve ever gotten into has almost always devolved into one topic:  is this solution simple or is it complex?  And yet, there’s one alternative that we always forget about: simplism.  Simplism is simplicity’s evil twin, and it can be difficult to tell the two apart.  The difference between the two is that simplicity will grow up to be a successful adult who will make you proud, while simplism will grow up to be in jail, doing drugs, and always borrowing money from you.

Ok, so that analogy is a little bit hokey.  Let’s try looking at the dictionary definitions:

simple – easy to understand, deal with, use, etc.: a simple matter;simple tools.

simplistic – oversimplifying complex problems; making unrealistically simple judgments or analyses

When you do something simplistic, you are essentially sticking your head in the sand. You’re implementing a solution that meets the requirements of some problem that’s much simpler than the one you’re presently facing or will be facing in the future. And it’s always the latter part of the last sentence that gets you. Most people are smart enough to know when a solution doesn’t meet their present needs. But trying to find a solution that will be flexible enough to meet whatever random occurrence should come up in the future is tough.

Some people will tell you to stop right there. You don’t know what’s going to happen in the future, so don’t worry about it. But I think that the sign of truly elegant code is that it can be made to do all sorts of things its original author never dreamed of. There’s no need to contort it to do crazy things because it just works. And before you write that off as over-engineering, stop to think of the bigger picture. Remember: business requirements have a habit of changing suddenly in the most unforeseen ways. To get things done, sometimes you have to be willing to not get them done right this minute. As the Zen of Python says:

Now is better than never.
Although never is often better than right now.

So how do you keep things simple without making them simplistic?

I’ve found exactly one method that reliably makes software simpler without making it simplistic: make the software do less stuff. From a strictly technical standpoint, this is a surefire way to make software that is simple and not simplistic. Of course the business side will insist that you meet the requirements and then some. And they have good reason. I only said that this makes things simpler from a technical perspective. Technical simplicity might be business simplism.

But 9 times out of 10, there’s a way to satisfy both sides if they’re willing to compromise. There’s something to be said for the 90% solution. It does 90% of the things business people want and is 90% perfect for the programmers. The 10% you cut out might not sound like much, but if you cut out the right 10%, you’ve earned your salary along with one of your coworkers’.

So what’s the moral of this story? Before you decide on the solution that seems “simplest”, stop and think. Is it really simple, or is it simplistic?

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.