You'll Have Debt Get Used to it!

In the classic The Mythical Man-Month, author Fred Brooks speaks of the intricacies of software development. This collection of essays is a must read for any IT professional, particularly when the reader learns about the concept behind Brook’s Law: Adding manpower to a late software project actually makes it later. 

While many other intricacies of software development are exposed in this classic, there is one point Brooks did not define clearly: technical debt. While he spoke of entropy to express the growing complexity of software, we had to wait for another legend of our profession to improve our understanding of technical debt. When Ward Cunningham coined the term, he did our profession a favor. It expanded the conversation from being not only between developers to include the businesses that use the systems we build and maintain.

At its simplest form, technical debt is the consequence of a lack of technical rigor - be it voluntary or involuntary - during software development. Regardless of the source, it must be managed at one time or another in our product. As with a lot of other software themes, technical debt should be managed from a strategic standpoint, with the support of our backlog and with the help of our client. 

For example, creation of debt is not always due to a lack of skill or discipline. Sometimes, for strategic purposes, we will deliberately create a debt to meet a business opportunity that, otherwise, could be missed and lose some market share.

One of the first things to discuss about debt is its different levels and the consequences of each. Martin Fowler states how a credit card debt will cost you much more if you miss a payment compared to your long term mortgage. The cost of not paying your monthly credit card bill will hurt your wallet much more. Eric Evans, author of the book Domain-Driven Design, uses this personal debt analogy to identify the debt in your various domains.

 

Evans proposes how the core domain of your system, just like your credit card bills, should be debt- free. As it is the core of your software, it should be in line with Agile development practices (testable, balanced between emerging and anticipation, low coupling and high cohesion, etc.) so we are able to embrace change more easily and quickly. On the other hand, utility domains are like your long-term mortgage, they can handle more debt as they are less critical to your application right now.

While a technical backlog can be a useful place to list your debt, we have found that putting that debt in the product backlog makes more sense. First of all, these debts belong to the product and they will affect the total cost of ownership of the product. Second, we find it is easier and less confusing to put everything about the product in the same place. It simplifies tracking everything related to the product, business and IT. 

Once our debt is listed, we have found that the decision to eliminate debt should be business-oriented. What are the cost, risk and urgency of leaving such and such debt in place?

This is particularly true with start-ups. These young enterprises, looking for an engine of growth, are probably not interested at fixing debt right away. They have more important things to do if they want to stay alive. As Fred Brooks wrote: “[I] t is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow.” Another case where debt can be ignored is a system that will turn obsolete. As in the start-up example, it is the business factors which will guide you in your decision to work on your debt.

We have also seen the involvement of the customer as a factor on how to handle the technical debt. When in a product mindset, the team gives the product owner the guarantee that growth of the product will stay the most important part, not just for short term requirements (e.g. performance) but also for long term objectives (eg. maintenance). 

In a project mindset, this can become problematic as we have seen product owners being temporary allocated to a team before being returned to their original job once the project is done. In this scenario, it can become problematic to have a conversation about technical debt where the product owner is focusing on its short term objectives. As your organization matures with Agile, we would recommend you think about having a long term product owner so the right conversations about technical debt happen. 

When you buy a car, you don’t just pay the big number on the price tag. There will be insurance, maintenance, a new set of tires, parts to replace and so on. If you don’t do your oil change, it can have a negative impact on your engine’s performance. The same goes for software. As the owner of the product, managing your technical debt the same way as your oil change will ease things out on the long run.

While the Agile community had a few clashes in the last years (the debate on doing TDD, #noestimates), our community has never disagreed on the importance of managing technical debt. Now that we have a great metaphor to address it, we can only hope you will have the right conversations between the team and its customer to have long lasting products on the market.

If you would like to learn more about Scrum, find Scrum training or take a Professional Scrum certification assessment you can visit Scrum.org.

If you have questions on the topic or want to contact either of us, you can email Francois or Louis-Philippe.