“Technical debt” is a term used to describe architectural or implementation issues with software that inhibit further development. Practically every successful software project , if it’s been under development for long, has some technical debt.
Some believe that technical debt is purely a consequence of bad coding, lazy programmers or poor decisions. While those factors can greatly exacerbate the problem, it’s actually not true that you can avoid technical debt when working on software that is evolving over time.
Why? Because you can’t predict everything the software will need to do. A programmer years later might be trying to patch on a new feature that was never on the table initially. To him, the current architecture might represent terrible “technical debt” and needs to be dealt with to move forward.
Worse yet, if you try to guess what features you’ll have to support in 5 years, you’ll almost certainly be over-engineering. And worse, you’ll probably be guessing wrong, so you’ll be building unused, overbuilt features that will have to be rewritten anyways.
When does it make sense to buckle down and fix your technical debt ? Some companies never do. Many large companies have VMs running ancient operating systems, with dusty forgotten code bases, written in languages that no one knows, processing business rules that no one person fully understands, and is certainly not documented. Often, they tried to rewrite a couple times and failed.
I’ve been through the cycle of creating and abolishing technical debt many times now – here are a few things I’ve learned that help, while not avoid, certainly reduce the pain of managing your technical debt.
1) Embrace a refactor mentality.
When building a new feature and finding a technical inconsistency or an inelegant construct, it pays to fix the issue right then and there. This is easier with some languages (Ruby) than others (C++), but the sooner you fix little annoyances the better. Wait too long and you’ll end up with a mountain of dependencies to deal with.
It’s far better to make small, incremental improvements than it is to try to rebuild everything all at once. A mistake some programmers make is to come to the conclusion that everything needs rewriting because they don’t understand it. Don’t succumb to this. No, you don’t understand it. You also don’t understand all the little bug fixes and subtle business rules that have been built up over the years. Those fixes and updates have major value – you’re much better off keeping as much as you can. Back in the internet boom days, Netscape completely destroyed itself by deciding on a complete rewrite – don’t let that be you .
3) Don’t alienate your users.
Have to rebuild your UI? Or change the way your API works? Users are the lifeblood of software, and should be treated with tons of respect. You make think your fancy new UI is waay better, but your less computer-savvy users may have spent years building up a workflow for your software that you just destroyed. Remember Digg.com ? Embrace an iterative approach and don’t pull the rug out from underneath users overnight.
Of course nothing here is a hard and fast rule. Sometimes you run into some COBOL web services and there’s no saving them! But these guidelines work for me.
HiringThing is easy to use, intuitive online recruiting software that makes it easy to post jobs online, manage applicants and hire great employees.