Hoarding Code is Technical Debt

The idea seems so innocent: a feature is no longer needed or is obsoleted, but what’s the harm in leaving it? For a visual of this, consider any of the “Hoarders” episodes on YouTube. What is the harm in keeping this old cuckoo clock? How about this old skateboard? Mcdonalds bag?

The years go by quickly and soon no one has any recollection of why that feature ever had merit. But then, there may be some customer that has some odd requirement that needs this feature – we think. (And, for sure, Junior will be stopping by to pick up his skateboard.) There hasn’t been a bug recorded against this, so it can’t be broken, can it? (The cuckoo clock hasn’t worked in years, but no one complains.)

Unfortunately with software there is a cost to this old junk. The cost is repeated re-learning what this does, coding around it, and occasionally designing & testing it. A great¬†feature would be documented; a good feature would be obvious to end-users and pretty plain to see in the code; the rest is probably junk. What’s the old rule of thumb? 20% of the code fulfills 80% of the need?

From a security perspective, code adds “attack surfaces”. The more code, the more opportunity for bad things to happen. The opportunities for what can go wrong can get sizable¬†very quickly.

Let’s revisit the hoarder’s analogy for a moment. After some time, a new, sleek hot-shot feature is incorporated into the product. Kinda like a new modern, contemporary house being built next to said hoarder’s house. What is the value of the new house? Has the hoarders dump reduced the net gain? From the customers perspective, why would it be any different?

Let’s keep our code (product) lean & trim!

Hoarding Code is Technical Debt