Breaking old habits: Delete your crusty old code
Lately, I’ve been trying to become a better programmer — not by learning new languages or new concepts, but by kicking old habits. One habit I’ve successfully kicked is code hoarding.
Code hoarding happens when you get into the malicious routine of commenting out code you think you probably might re-use later. I used to do this a lot. It usually happened when I had a change of heart during the implementation. I’d either decide what I was building actually wasn’t helping the application, or, I would think of a completely new way of coding it. In both cases, I commented out code because, why just delete it? What a waste of my precious thinking.
A few weeks ago, Mustafa (a non-hoarder) mentioned that I was “doing it again.” We version control all of our code anyways, so there isn’t a good reason to comment out unused code in the first place. Code hoarding isn’t just unnecessary, but it’s counter-productive.
The reality is, 99% of the time, I never un-comment code that I commented out days or weeks ago. Instead, the blobs of monochromatic jibberish are interspersed with the actual code I’m writing at the moment. It’s annoying to look at. Every time I work on something around the old code, it’s distracting me from what matters right now.
Even if I do decide to re-implement something I wrote awhile back, the code I commented out usually doesn’t fit properly anyways. Maybe, I’ve moved that entire piece of logic somewhere else. Objects or methods I reference in the old code may have changed. Trying to bring old code back to life means I’m spending time jerry-rigging things rather than writing it correctly and cleanly again. The code I wrote last week was written by a version of me that only knew what last week’s application looked like.
Look beneath the surface
Code hoarding is one of many habits that seem right on the surface. It’s a carryover from other staple engineering principles that aren’t really relevant to programming. If you were building a car, you would save all your scraps and half-built parts. You could reuse them later. It would be stupid do dump them.
Labor, time, and material are really critical in traditional engineering. It’s much easier to finagle something almost-right in the physical world than to rip it apart and start over again.
In programming, we tend to overvalue labor (typing is not that hard), time (whether we save time by hoarding is debatable), and material (there really isn’t any). In the same breath, it’s also easy to undervalue really critical aspects of efficient programming:
- Keeping your code clean. What’s on the page should reflect exactly how the app works right now. Nothing more, nothing less.
- Maintaining your zone. Programmers think and implement at the same time. In traditional engineering, you think through everything before you implement. Having unused code lying around or trying to resuscitate old code breaks your train of thought.
On the off chance that I’ve rewritten logic I originally deleted, I haven’t found the experience to be all that bad. It gives me a chance to make it more elegant this time (that’s probably why it was commented out in the first place). I don’t spend time comparing the old solution to the new solution (If the new one works, who cares what the old one did?). And, I maintain my train of thought better.
How do you know which habits to break?
In the end, it comes down to relevance. Are your methods actually relevant to the way you work today?
Many find agile (or even semi-agile) development a better fit for web apps than traditional waterfall methods. Refactoring wouldn’t be practical in the traditional engineering sense, but is extremely helpful in programming. You can even make the case for the advantages of loosely-typed languages over strongly-typed ones.
Deleting code follows along these same lines. It’s just not relevant to hoard your code.
