Published on Thursday, February 27 2014
Sometimes, after finishing the implementation of a new part of a program, I like to take a break and sort of aimlessly browse the code that I’ve written so far. I will pick a module and start reading a couple of classes, and see where that takes me. It’s a form of procrastination. That’s me coming back up to the surface to breathe, to gather up my willpower before I again dive deep into another intense round of coding.
While code reading, I will often find things about the program that can be improved on. Some things will be small – add some documentation; fix typos, whitespace or indentation. Maybe pick a better name for a variable. But sometimes, I will find bigger opportunities for improvement, and I will do some ad hoc refactoring.
I believe that this is a healthy form of procrastination. It keeps my knowledge of the program domain current, and keeps the code lean, the best I can make it. This creates a virtuous cycle of implementation, polishing, implementation, polishing again and so on. I do not consider it wasted time. A codebase that is sound is easier to add to. It’s an investment towards less work in the future.
However, sometimes I have to work on a codebase that is in a bad shape. When that happens, I just want to go in, make the changes that I need to make, and get out of there without leaving too many brain cells behind. I will leave things in a better state than I found them, but I want to be out of there as soon as I’m done. I will not go out of my way to seek out things that I can improve on. Because I can already see the issues staring at me in the face, and there are so many of them. Motivation has taken a quick look and said “Look, I just remembered that there’s this thing I gotta do. Call me later, you know, after you’re done here.”
Maybe you’ve heard about the Broken Windows Theory. It goes like this:
Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.
Or consider a pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of refuse from take-out restaurants there or even break into cars.
So fix up your broken windows. Be vigilant and always worry about what you’re presenting to a visiting programmer. If it’s obvious that you don’t care about your code, then the next person to add to it will care even less. Soon badly indented code becomes poorly structured code. People start spawning state needlessly simply because they can’t be bothered trying to untangle the mess. They’re holding their breath while running through corridors that stink of urine. They just want to get in, add this thing they need to add, and run out again. One day someone trips over some wiring and the building is on fire.
Fix them broken windows.