Was thinking recently about how any good code base tends to go through a continuous cycle of expansion and compression. (This thinking may have been inspired by the recent frantic development work on SearchTempest in the wake of craigslist blocking framing…) The ‘expansion’ part is the standard stuff. Building something new, adding features, even fixing bugs most of the time tends to involve writing more code, causing the code base to expand.

However, if you only expand and never compress, eventually you will inevitably end up with a giant pile of pasta.

It’s critical to occasionally go through your code and simplify. Trace through the logic and figure out how it can be improved. Look at places where procedural stuff could be made object-oriented. Even just strip out legacy crap that isn’t used anymore.

Of course, this can be difficult to justify. There are always higher priorities, and it’s tough to put a bunch of time into a project that, in the best case, has no immediate visible effect. (Especially if you happen to answer to a manager who hasn’t personally done much/any coding.) And that’s the best case. It’s ironic, but this process of cleaning up code can very well introduce new bugs. After all, it may involve making fairly significant structural changes to a code base that is by all appearances working just fine. (And those bugs tend to make people… irate. Don’t do something like this then go away for the weekend.)

So, why do we bother? Here’s a similar issue: why do we bother researching sources of renewable energy? It has always -so far- been cheaper to just stick with fossil fuels. That may well continue to be the case nearly until they run out, since the incremental cost of extracting a barrel of oil does not increase linearly with its scarcity. But if we wait until we run out of oil, or until we destroy our atmosphere burning coal, it’s too late.

Of course, the consequences of ugly code are rather less dramatic, but the analogy holds. If you wait long enough, eventually you will be forced to clean up your spaghetti code because you’ll get to the point where adding one more hack will break the camel’s back. You’ll have a feature to add, or a bug to fix, and it simply won’t be possible to shoehorn it into the existing morass. When that day comes, it is NOT a fun day to contemplate redesigning your whole code base. Especially if the bug you’re trying to fix happens to be a critical one.

On the other hand, when such a fateful day rolls around, a clean code base can be a truly beautiful thing. A little irony: the best thing about nice clean code is that it makes it really quick and easy to slap on an ugly hack. And when your site’s down and the hysterical emails are rolling in, that ugly hack that gets you running again can be a beautiful thing too.

Or more generally, by periodically cleaning up your code, you make your job a lot easier the rest of the time. Of course, you could try to just ‘do things right the first time’. But even without deadlines (which takes us into imaginary-land), it’s pretty difficult to always keep the entire big picture in mind while solving a specific problem. Of course you should still try to write nice, clean, extensible code whenever possible. Sometimes though, you still have to take a step back.

In the real world, the cleanup of a given module will likely be spurred by some other development, which is okay. For me at least, there’s no motivation to sit down for the express purpose of prettifying code. But when you’ve already dug into something a bit and you start to see avenues for improvement -and you’re not in an absolutely critical time crunch- go for it! (If you’re always in a critical time crunch, you’re doing it wrong. Or someone is.) It’s just like cleaning in real life actually. Ever go to pick up a dirty sock and end up doing all the laundry then cleaning the entire house? Do that with code! (If not, go vacuum something. I bet your partner/roommate/cat will appreciate it.)

Nice clean code is a beautiful thing, but it’s elusive; you can’t aim straight for it. What you can do is write fairly decent code, then occasionally compress it. Channel your inner Superman and squeeze that code coal into a precious diamond. (Ha! Tied those analogies together!)

If it ain’t broke, now’s a great time to fix it!