Restraint and the Right Thing

In computer programming, there is this idea called the Right Thing - that for a given programming problem there is one, and only one, correct solution. This idea is mostly obsolete, but many programers still believe it.

According to Steven Levy in the book Hackers, the idea of the Right Thing sprang up at MIT in the 1960s. At that point, the idea was valid, but there are some points to note about the programming environment at the that time and place:

  1. Everyone had similar technical abilities
  2. Everyone was working on the same architecture
  3. Memory and processing power were extremely limited

Given that environment, it is easy to see how one could conclude that there was only one correct way to solve a given problem. If you only have a kilobyte of memory, you cut corners to get everything to fit. If your CPU is running in the kilohertz, you make every clock cycle count. And so you ended up with programs that were as short and clever as possible to make the best use of the limited resources. This was okay, because the programming group was a monoculture, and your peers could be expected to understand and appreciate your cleverness.

But those constraints no longer apply. Let’s constrast that environment with our current one:

  1. Everyone has different technical abilities
  2. Everyone is probably working on the same architecture, but may be working on different architectures
  3. Memory and processing power are vast, readily-available, and cheap.

Every constraint placed on the early programmers is now gone. Software teams can choose how to optimize their programming environments. The Right Thing is now relative. Maybe you’re working on a problem that takes a lot of processing power, so you optimize for that. Maybe you deal with terabytes of data, so memory and space are still constraints. If you work with embedded systems, you will have to deal with both.

Realistically though, most of us are web developers working on problems that are neither new nor novel. We take data, store it, and return it at a later time. That’s it. Given that environment, the Right Thing is different. The biggest cost on a software team is the programmers themselves. Therefore, care should be taken to write code that is easy to understand and easy to maintain. If that is done, the pool of programmers available is as large as possible. Clever code requies clever programmers to untangle, and they often come at a price.

In the first draft of this essay, I wrote that “dumb code was the new Right Thing.” But this is not correct. Dumb code is easy to write, but not very easy to maintain. It’s what you write when you are a novice, or when you need a quick script that will run once. Clever code is worse. It is difficult to write and even harder to maintain. (And often, the programmer is not as clever as they think.) The balance (as always) is somewhere in the middle, and this is where restraint comes in. You write dumb code as a novice, clever code when you know just enough to be dangerous, and maintainable code when you have the knowledge to be clever, but the wisdom to restrain yourself.

Programmers are right up there next to evangelicals when it comes to being dogmatic and bull-headed. There is a reason that famous programming arguments have been called “religious wars.” We learn design patterns. We learn about objects, factories, Single Responsibility and Tell Don’t Ask. We learn a slew of other acronyms. And we try to use all of this any chance we get, because it’s the “Right Thing.” But that’s academic. Anyone in industry is not being paid to be academic. The CEO is paying you to (1) ship and (2) not cost them an arm and a leg when you decide to leave but your code stays.

I’m not suggesting that we throw all the design concepts out the window. I think many of those ideas can still be useful. But we have to be aware that every pattern or abstraction we introduce is one more roadblock in the way of that new programmer trying to understand our code. So if you decide to introduce that roadblock, you’d better have a good justification for doing so. And you know that fancy ServiceLocatorFactoryBean you’ve been working on? You’re not going to need it.