Slow software practices

Alex Tabarrok highlighted this chart about eating. Somewhat paradoxically, more time spent eating actually resulted in lower obesity.

I wondered whether a similar effect might exist for software.

It's easy to think of a hypothesis where this could be true. Quickly built software, with fingers flying, usually allows little time for planning. The goal is to get the code out as soon as possible, and lots of code is what happens.

All that code begets more code fixes. Also, the code likely doesn't involve a lot of abstraction, having been built for some specific cause, the emergency of the day. Thus the next emergency requires new, specific code for it, as well.

Perhaps a slow software movement is what we need. Of course, our company owners and business managers would freak out if we started saying that we're adopting "slow software practices".

So, of course, we call it other things -- requirements gathering or architecture review or quality control. But at the heart, one of the main elements of all of them is to slow things down, to create room to stop and think.

Keep that in mind the next time you're facing a project. Yes, it needs to get done right away, but invest in yourself and the project, and slow down.