Code Hoarding

Life as a software developer is probably not what most people think it is, many imagine coders as we are portrayed in films or series; sun-shy nerds sitting in darkened rooms hammering away at keyboards in a code trance creating the software that will change the world! Yeah not really, in fact being able to create projects and software from scratch, is something of a rarity, for example recruiters often throw around the term “Greenfield Project” in job adverts to garner more interest in their roles.

I would say being a dev is more a hybrid of working at a nursing home and being an archaeologist.

A new product, once out of its embryonic state, will start out hale and healthy like an Olympic athlete but as the years roll on, there will be added requirements, edge cases and general bumps and bruises and the underlying technologies change as the world moves on. Before you know it the product has reached a state of senescence, with some surviving the ravages of the years better than others. For many of us, keeping these old geezers alive is a full time occupation.

That’s where the archaeology part comes in. The chances are, you weren’t around when your product was created and your job involves scouring the code base and understanding how things work, in order to fix and maintain them. It’s not quite Indiana Jones territory, more like dusting through layers of sediment to really grok the architecture and data structures. If you go in there with a hammer you’re likely to destroy things before you’ve even had a chance to understand what you’re doing.

One of my colleagues has recently been given one of these monumental tasks, a piece of software that lies at the critical intersection of just about every product we currently have, and to make matters worse, it’s on life support and has been for a number of years. So needless to say, he’s moving very cautiously. I was chatting with him about this recently and he commented:

“I knew the code base was bad, but I had no idea that <original dev> was a Code Hoarder as well!”.

I’d never heard this phrase before, but instantly recognised what he was talking about without need for explanation. A Code Hoarder is someone who cannot bring themselves to throw code away, instead they will either comment out huge blocks of code or worse, just bypass the obsolete code without ever removing it.

You can imagine the complications this causes another developer, when already facing the daunting task of getting their head around 100,000s lines of code, their life is further complicated by the fact that it’s littered with these unintentional booby traps.

I’m incredibly passionate about this and think that this mindset is one of the skills that shows the difference between experienced developers and more junior ones and that’s not just developing something to the point where it “works”, but considering the future maintenance of the code. If there are 50 lines of code REMed out in the middle of a function, I have to stop and consider why? What purpose is there to leave this behind? Why didn’t they just delete it? Whatever the answers are, they’re sure to get lost in the mists of time. I mean, we’re all using source control right?

So next time you’re about to comment out a huge swathe of your code, or render a function unused, ask yourself “Shouldn’t I just delete this instead?”.

Don’t be a Code Hoarder.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: