Technical debt. It sounds like a scary new investment mechanism that too-big-to-fail banks created after the whole CDO/credit swap/Big Short thing ended... poorly. But it's much scarier than that. It's the time bomb lurking in every software product, waiting for the right time to jump out and take down your newest beautifully crafted feature. It's the source of zero-day security holes, back door hacks, and plain old everyday performance issues. It's a fact of life for every software company and the bane of every application architect's existence. In my office, it's also the prime catalyst for torrents of muttered (or not) curse words. Sometimes, it even comes with a name, usually the name of the person who thought he'd found a brilliant shortcut... at the time.
So what is it? It's old code, shortcuts that felt necessary, compromises in quality and flexibility based on ignorance or tight deadlines. It's the code that you wish you hadn't written, or that you'd like to smack someone else for writing. In short, it's software development's loan against future functionality. Like Popeye's friend Wimpy, it will gladly pay you next year for two features hacked together today. And when the bill comes due, it sucks.
So how do you keep technical debt from taking over your product? First, you need to recognize whether technical debt is a problem that you have to worry about. So ask yourself these questions?
- Do you have a software product?
- Do you plan to keep adding features to that product?
- Do you still plan to have that product two years from now?
If you answered yes to these three questions, then yes, you need to worry about technical debt. If you answered no to #2 or #3, congratulations! You are the proud owner of a legacy product and can look forward to many years of saying, "No, we aren't investing in this anymore so I can't add that enhancement. Please see our list of new products and let me know if you're interested in migrating." If you answered no to #1, thanks for reading, Mom. You can stop now and just tell me how great you thought the article was.
For those of us with active, growing software products, technical debt is a constant worry, or at least it should be. Because even if you have genius architects, brilliant developers, and aggressively detailed QA testers, you still can't escape one fact: software decays. Even perfect code, designed to account for every known variable at the time, will feel slow, awkward, and difficult to work with three years from now. Technology moves quickly, and user expectations move with it. So join the rest of us, Mr. Perfect, and start thinking about tech debt.
There are different kinds of tech debt, and you need to know which kind you're dealing with before you can manage it. Let's look at these different debt instruments, in order of urgency.
1. Visiting The Software Loan Shark
2. Emergent Debt
- Design for what you know you'll need
- What's salvageable? Is it still usable?
- How much will it slow us down to keep building around it?
- Should we rebuild or build a replacement beside the old code?
- What's the cost of the new solution relative to continuing to work around the old one?
3. Code Decay
4. Moronic Predecessor Syndrome
You see, developers are smart people who thrive on complexity and problem-solving. I've kept brilliant teams working together in stultifyingly boring industries simply because the problems were interesting (the secret is to keep feeding them problems at the proper rate so they don't notice that no one understands what they do). Sometimes, though, this problem-solving tendency runs out of control, especially when a developer is bored or feels a need to prove himself, as when he enters a new role. This is where MoPS rears its ugly head, and you have to decide if you're facing a real problem or an aesthetic difference of opinion.
Once the beeps and clicking noises wind down, try asking a few questions:
- Why do you think the code is all wrong? Is it functionally deficient or is it built "the wrong way?"
- What's the impact of the current design? Is it slowing us down or making it difficult to add new functionality?
- Does the rest of the team who works with this code agree with you or are you the only one seeing this? (Try to avoid using the word "visionary" here: it will sound sarcastic).
- How long do we have before the problems you foresee come to pass?
If you determine that you do have a problem, then follow the same steps as for Emergent Debt: assess the risk, understand the cost and benefits, plan the work.
And did I mention that you should create a user story?
Paying Off Your DebtsDevelopment teams get weird when it comes to paying off their technical debt. There seems to be this shame attached to fixing old code, as though the company should have known better and written code that would stand the test of time. Yet tech debt accrues in a myriad of ways, and as long as you aren't making weekly trips the software loan shark, you don't have anything to be ashamed of. This is life in the digital world, so stop trying to sneak your debt payments into your new feature estimates! (And yes, I know who you are).
Eliminating technical debt is just like any other piece of work: you're investing to improve your product, and you expect certain benefits from doing the work. Just because they're often invisible to users doesn't mean they don't exist, and everyone wants a product that stays usable over time, right? Of course, you can't blackmail the budget keepers with "do this or your precious site will crash," so you need to make your case. New features have business benefits (new revenue, increased customer satisfaction, competitive advantages) to offset their costs, so why aren't you doing this for your technical debt?
Here's how the conversation usually goes when a developer wants to fix old code:
Developer: "We need to fix this."
Product Owner: "Why?"
Developer: "Because old code sucks and the new code will be better."
Product Owner: "Shut up and go build my new feature."
What if, instead, we created a business case for out debt payments? All you have to do is quantify "better." If spending 4 weeks building a new service means that the next 5 features can be built in half the time, that's obviously a good investment. If rebuilding the calc engine means that our product stays performant for another 3 years, that's probably also a good investment, assuming that it doesn't take a year to build. The question behind every business case is simple: how can you make the benefits quantifiably outweigh the costs? And since costs are easily measured (people * time = $$$) the more quantifiable the benefit, the better. If you tell me that you can guarantee that a $10,000 investment will return $100,000 in the next year, I'd be an idiot not to take it. If you tell me that you want $10,000 so you can make something "better," then you're asking for a lot of trust.
And if you can't quantify the benefit? Then you probably have a bad case of MoPS. Take two beers and a good look in the mirror and call me on Monday.