Do you ever find yourself too busy “fighting fires” to do things “the right way”? Do you know that there are better ways of managing your project, but you find that you just need to get things done and can’t be bothered to fix underlying problems because it may slow you down? Ever find yourself wondering if you will ever have time to go back to a feature you released a year ago to make it better and move valuable to your users?
If so, you may be in debt.
No, I’m not talking about your personal financial situation. I’m talking about debt at it applies to building software. Specifically, I’m going to talk about what I call Best Practice Debt and Product Debt. I think I just invented these terms – as they are derivatives from something called Technical Debt (forgive me if there are other terms that I haven’t come across that refer to the same thing). If you haven’t heard of Technical Debt before, here is a great quote from Martin Fowler:
“You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
The tricky thing about technical debt, of course, is that unlike money it's impossible to measure effectively. The interest payments hurt a team's productivity, but since we CannotMeasureProductivity, we can't really see the true effect of our technical debt.”..
I’ll leave Mr. Fowler and Mr. Cunningham to better explain the deep dark secrets of Technical Debt, however, from my experience the metaphor of Technical Debt boils down to the growing set of things you will have to deal with that don’t produce customer value. Customers don’t care about design patterns, refactoring, unit test coverage, and data access techniques. Team’s incur technical debt when they take a quick and dirty approach to a problem and are forced to revisit the issue again in the future – work that extra work that you must come back and do will displace value.
Side Note: Technical Debt isn’t necessarily a bad thing – in the same way that financial debt may not be a bad thing. Many people do not own their houses and live by paying down the mortgage debt one month at a time – paying a bit against principle, and a bit against interest. Uncontrolled debt is the bad kind of debt – spending way more than you can ever pay back. If we didn’t have debt, many of us would have to save up for 20+ years before buying a house – which is a very long time to go without living in a house.
Defining Best Practice and Product Debt
What are Best Practice and Product Debt? Well, very much like Technical Debt, they are things that you are putting to the side in order to get things done “quick and dirty”
Let’s start with Best Practice Debt. I guess I could have also called it Team Debt or Learning Debt, but it just didn’t have the same ring. Best Practice Debt occurs when teams put aside good team practices in order to get things done. Instead of properly recording requirements and work, they don’t. Instead of tracking progress of their work, they don’t. Instead of following practices prescribed in methodologies such as Retrospectives and Reviews prescribed by Scrum, they don’t. They put these practices aside because they either don’t feel they have the time to follow good team practices, or they don’t feel they have the time to learn and implement good team practices without impacting the work they need to deliver today. I’ve seen this happen all the time – teams are working sooo hard – fighting fires and using heroics to achieve success – and not putting time aside to learn or implement team management best practices or keeping project tracking data up to date. The mountain of Best Practice Debt increases as teams put aside improving team management techniques. For example, if your team decides to forgo tracking their progress (because they are too busy writing code of course) – the longer they go without tracking, the more work they will have to do to get everything back up to date. The greater the debt, the more effort it will be to clean things up – and the less likely it will get done.
Product debt is a different type of debt and has to do with the enhancement of features as you continue through incremental releases. Everyone wants new features; every release we like to focus on fixing bugs and delivering new features – but how about enhancing some of the existing features in your product – do you ever go back to them and make them better (which is different than fixing bugs)? We may know that an existing feature should be enhanced, as we may have either had to limit the scope of a feature in an initial release (delivering version 1 of a feature) or we may realize after we release that a particular feature just doesn’t work as it should. I know that for consulting organization, going back and enhancing features only gets done when the customer asks for it – eventually becoming a contentious issue – however this problem is even difficult for product vendors as well. Product debt happens when we focus on driving new features versus enhancing existing features. As this debt continues to grow, it gets tougher and tougher to repay that debt in the form of feature enhancements. When you address Product Debt your team will spend a bunch of effort on enhancing a feature without changing how a feature works – and thus, provides little measurable value to your customers (or your marketing team).
Figure: With every version (V1, V2, V3..) we release new features, when do we enhance existing features?
The secret to all forms of debt is debt management – regularly contributing to debt payment in order to keep the debt at a manageable level. Debt isn’t bad. Debt that is unmanaged or ignored is bad.
How do you keep Best Practice Debt in control? Through regular reviews and a continual process of improvement where you can increment on Best Practice Debt (again, it will be nearly impossible to get rid of all Best Practice Debt all at once). Your team should work hard to inspect your processes (including the data your process relies upon – such as the way you track requirements, work and updates) and find ways that you can slowly adopt new practices.
Product Debt works in much the same way. One thing I like to recommend is that every release should allocated a percentage of work dedicated to enhancements and fixes as well as new features. For example, you might allocate 30% of an effort to release a piece of software on bug fixes, 40% on enhancements, and 30% on new features.
Just like Technical Debt, Best Practice and Product Debt is likely to always exist on virtually every team.
Debt isn’t a bad thing, however, you should work hard to address this debt as you move forward, and making “payments” every release to ensure your debt never gets out of control.