The prolific Mark Twain wasn’t talking about computer programmers, but he could have been.

There are a lot of differences between excellent computer programmers and your average, run-of-the-mill hackers. But there’s one major difference, and it’s subtle but critical. And, in my experience, it doesn’t have anything to do with age or tenure.

Great programmers can accomplish the same thing as run-of-the-mill hackers with a lot less code and a lot less complexity. I’m not talking about the kind of code you write for the IOCCC contest or Perl golf. I’m talking about simple, readable, minimal code that gets the job done.

It’s story time

A couple years ago, I was sitting in a room with some great programmers. Management had asked them to solve an engineering problem. The problem seemed hopelessly complicated, and most of our engineering team had put it on the back burner because it was so unapproachable. Finally management forced the problem on us, and we all sat down in a conference room and brainstormed solutions. Ideas slowly began to emerge. After 30 minutes, the engineers had produced lots of complex ideas to solve the problem: client/server approaches, database-driven approaches, roll-your-own-Linux-distro approaches, and so on. All the ideas scared us. At that point, a light turned on. Ideas started getting simpler, and simpler, and by the end of the meeting we had whittled the solution down to something more elegant, a simple Python script that Byron hacked out in a couple hours.

The point of the story is this: Great programmers produce simple solutions.

The converse of this point is that bad programmers produce huge, complicated, and expensive solutions.

It’s time for another story.

To protect the guilty, I won’t share any specifics. I’ve heard tell of a team that had produced a piece of software over the course of a few years. The software had, as usual, grown to be quite complex, and the engineering team had grown to a dozen people. The software was deployed at a few customer sites, and was reasonably successful. I talked to some of the users, and every time the story was the same: “This software is so complicated”. The users weren’t judgmental. I think they just assumed that the problem was hard to solve, so the software was hard to use, and equally hard to write. One of the most complicated parts of the software was its installation procedure. It required the user to run several scripts in a custom csh environment. The user had to become an expert in a lot of areas unrelated to the problem domain. Customers approached the team and asked them to package the software in a standard installer format for Linux. The engineers dutifully estimated how much this would cost, and came back with an estimate of nearly … are you sitting down? … a half million dollars. Why so expensive you may ask? Their software had grown so complex and so hard to maintain, that a simple change like this would cost hundreds of thousands of dollars. Customers agreed (great customers, eh?), and the team went to work. After a few months, the job was so badly done, that the installer wasn’t “standard” at all, and it totally failed.

Why does this happen?

I don’t know for sure, but I think this blog post might give a hint.