I recently prepared a proposal for a client that along with new feature development, included a bank of hours to address the technical debt plaguing his fledgling tech start-up. When he asked me to explain the proposed expense, I had the sad task of revealing the ugly underbelly of his software. The product was stuck, painted in a corner due to decisions rooted in misaligned business and development goals, lack of test coverage, and a mismatched techstack. Pair all that up with the absence of a product road map to guide balanced investment in the codebase, and you have a product adrift and at the mercy of forces that can tear it apart. I’ve collectively named these forces, Technical Debt.
Sounds a bit scary, eh? But chin up. Technical debt is not like the actual Plague…even if no one is immune, and it could kill your tech company. Greenfield start-ups, established tech co’s and decades-old enterprise companies are all carrying around varying amounts of technical debt. And just like normal financial debt, it can be managed and even leveraged toward success or it can cripple your company in ways you might not see coming. How can something as potentially disastrous as technical debt remain off so many people’s radar for so long?
Perhaps we should start by learning what technical debt actually is so we can identify those seemingly innocuous decisions, often made in a moment, which can lead to a pile of problems down the road. The term technical debt was first coined by Ward Cunningham whose definition goes something like this: Technical debt (also known as design debt or code debt) is a recent metaphor referring to the eventual consequences of poor system design, software architecture or software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy.
The big take away from that statement for me is the idea that the initial debt is expected; getting a demo built or bringing an idea to MVP for user testing will incur some debt. Starting from zero and building on it will result in a dip at first, that’s easy to understand. But that the debt must be repaid or interest is accumulated…that’s where things get dangerous for the unsuspecting product owner. Codebases that are less than complete or proper can accumulate debt, with interest! That means that a shortcoming in a codebase doesn’t stay insular to itself, overtime it can affect the entire stability of the software. This conjures a vision of cancer spreading; quietly weakening the organism rendering it unable to recover to full vitality.
So, we can expect to incur technical debt initially when we launch, but we’re supposed to get over it and become technologically solvent. Why then, do so many product companies choose to ignore the best-practices advice on paying it back and instead make choices that put them even more in debt? It’s easy to understand how this happens when we consider that technical debt is what you get when the pressure to grow runs smack into the limitations of what has already been built.
As you might expect, I have a theory about this. I call it the Lure of the Sexy Feature Syndrome or Development by Dollars. After months or even years of development, keeping resources allocated to the under-the-hood technical functions over the designed-to-dazzle client-facing features is really difficult. Especially when the customer users are calling for bigger and better features and they are willing to pay for them. Much like we can turn our heads to ignore financial debt in favor of instant gratification spending (I really need to pay down my Visa, but I just gotta have the new iPhone 6!), software product companies turn the blind eye of denial toward addressing the debt while they keep piling on new bling. And if a company is even a little cash-strapped, sometimes the choice to go with less able development team can exacerbate an already existing problem.
Lure of the Sexy Feature and Development by the Dollars Syndromes are directly or indirectly tied to these main causes of technical debt. (adapted from Wikipedia) 1. Business pressures - where business goals or over-promising on the part of the sales team pushes a release before it is proper and complete. 2. Lack of process or understanding - where the business or sales teams do not actually understand imperative of using best-practices 3. Too tightly coupled components or modules - the software will lack the flexibility needed to respond to changing business goals. 4. Lack of test suite - This leads to sloppy bug fixes and risky coding. 5. Lack of documentation - the code is written without creating the documentation that goes with it. The work to create the documentation represents a debt that must be paid. 6. Lack of collaboration - where knowledge it siloed, not shared around the organization. This affects business and development teams, alike. 7. Parallel development or changes made in isolation - this builds technical debt because of the work required to ultimately merge the branches or changes into a single source base 8. Delayed refactoring – The longer that refactoring is delayed, and the more code is written to reflect an updated form, the more debt that piles up that must be paid at the time the refactoring is finally done. 9. Lack of knowledge - when the developer simply doesn’t know how to write good code and then more bad code is added to cover earlier bad code.
We all know a company that has been making development decisions that look like those above. Is yours one of them? Are you in danger of experiencing that all too terrible moment when it’s obvious that the only way forward is a total rewrite? How can we make choices that keep paying down debt even as the software evolves through iterations?
One key to managing technical debt is in understanding that it exists and is a natural part of iterative software development. In fact without the idea of incurring some debt we wouldn’t even have iterative development since the very notion implies that the product is in motion; it is not complete and may not be entirely proper. We can’t do everything at once; something will always remain to be done.
Another key is in always keeping track of it. Being clear about the decisions that incur or repay debt so that you always know where your product stands in relation to this burden. For instance, you might agree to not write documentation on new code now while you focus on launching the new feature but you need to be sure that writing the documentation ends up on your project task board for the next sprint.
Additionally, actually including all technical debt issues in the product road map and agreeing to allocate resources to address them regularly will keep the debt from blowing out of proportion.
It’s my opinion that the most important method to overcome technical debt is to prioritize goals that align business and development priorities. The leadership must work just as hard to assure that the product is as technically solvent as they do to make sure the company is financially solvent. There are many ways to accomplish this, but using the Agile methodologies is a good place to start.
If you think you might be dealing with a looming technical debt load and you are unsure how to whittle it down to a manageable size, it might be a good time to get another pair of eyes to come take a look. We can all benefit from having someone hold up a mirror for us to help us see where we are most vulnerable and how we might become strong. Coshx Labs has offered many impartial, insightful and honest remarks to enterprise industries and startups alike. What have you got to gain by peering into the looking glass?