How do I explain Technical Debt to business?
Para leer en Español clic aquí.
👀 The story
I want to tell you this brief story, and as in the series “Inventing Anna,” “This story is completely true… except for all of the parts that aren’t.”
The story is about an entrepreneur who comes across a dream opportunity. This person has a friend who is a developer and hires them to create the software. The developer starts working day and night to meet the agreed-upon deadline. The day came for the software to be presented, and it was a resounding success. The investors are excited and decide to invest in the product. And this is a story of total success. 🎉🤑
As with any successful product, it starts to evolve. New requirements arise, new features to implement, and the original developer can no longer handle it all. The logical step is to hire new developers, of course! And they do, but bugs become an everyday occurrence. Clients grow furious, chaos ensues, and the investors decide to withdraw their funding. What was once a super happy story turns into something tragic. 😩💸
What could have been done differently? Hiring more developers from the beginning? Rejecting the opportunity?
Opportunities are meant to be seized. Imagine that your dream opportunity arises, but you need money to achieve it. You approach a company to apply for a loan that will help you reach your goal.
When you receive the loan, all the terms are clearly laid out: deadlines, monthly payments, interest rates, insurance, expenses, and so on. With this loan, you manage to fulfil your dream, pay on time, and everything goes well. What can we conclude from this?
Debt is not inherently bad; it’s the failure to repay that creates problems. The same applies to technical debt.
In the case of the entrepreneur, one fundamental aspect was lacking: CLARITY. Even though they were skilled in coding, their lack of sufficient focus or being overloaded with work led to the introduction of technical debt, even if it wasn’t their intention. The issue is that when the project is given the go-ahead, this aspect is not mentioned, and there is no time allocated to stabilize the software. Consequently, there is no time to repay the debt, and the interest starts accruing.
💬How does technical debt manifest in software??
It’s like acquiring a debt that must be paid off at some point in the future. Similar to financial debt, technical debt accumulates interest as its resolution is postponed, which can result in growing problems within the system.
We know that we must pay the interest; otherwise, it accumulates, and the debt becomes increasingly complex to repay. In software, the interest can manifest in various ways. Here are some examples:
- The company may lose money or investors.
- Missed growth opportunities.
- Increased infrastructure costs.
- Extended delivery times.
- Effort and sleepless nights for the entire team.
- General demotivation.
- Employee turnover.
- Difficult integration of new team members.
- Disgruntled users.
💪Why is it often difficult to explain it to the business?
The Visible
In software, there are visible parts, such as functionalities. Clients can see this positive value in their production application, including the user interface, generated reports, exposed services, and more. They can also see the bugs, which, although they have negative value, are present and easy to visualize.
The Invisible
However, in software, invisible or less evident parts are carried out during the software development process and contribute positive value, such as design and architecture, components, responsibilities, interactions, and more. We do all of this, and it exists, but it’s something that is intangible for users or stakeholders.
The same applies to technical debt. It has a negative value but is part of software development. It will always exist regardless of the team’s level and maturity. It needs to be managed, but it can be challenging to do so.
Philippe Kruchten wrote a paper in 2011 where he shows us how we can see technical debt in software.
🔝How do I convey the importance to the business?
As with many software-related topics, the solution lies in communication. I recommend having an alignment session where you can explain what technical debt is and why it is important to manage it. You can also share this article with them hehe… 😉.
Alignment session
- The responsibility of managing technical debt is shared between the business and development.
- Sometimes, consciously introducing technical debt can provide us with some advantages. The important point here is to make it clear that we have to repay it, and the sooner, the better.
- Aligning that all teams face technical debt, even the most mature and high-performing ones, the key lies in how they manage it.
- There are tasks that may not necessarily be visible in features. (Show the previous diagram)
- Emphasizing that neglecting technical debt impacts the developers and the business.
- Agreeing that during development, a percentage will be allocated to technical tasks. A percentage that has worked for me is 20% of the Sprint.
- Discussing the strategy that will be implemented to manage it within the team.
- Speak their own language, and mention the associated costs; this study: “The Annual Cost of Technical Debt: $1.52 Trillion”, will provide you with a lot of data that you can use in your arguments.
Day-to-day follow-up
- In conversations, it’s important to provide arguments by mentioning the business consequences (financial problems, user complaints, costs, etc.).
- Include the business in technical discussions to give them a broader understanding of what we face in software development.
- Don’t make assumptions; ask all the doubts.
- Regularly negotiate, not just when we already have a problem.
- Share results, such as the number of bugs resolved, software quality metrics, etc.
👩💻And how do I manage it in the development team?
I will soon be sharing an article on this topic, but for now, I just want to remind you that managing technical debt is part of the development culture. Referring to the agile principle of “Continuous attention to technical excellence and good design enhances agility,” I have come to a conclusion that…
“WITHOUT TECHNICAL EXCELLENCE, THERE IS NO AGILITY.”
What do you think?
Some time ago, I gave a talk on “How to Survive Technical Debt?” Here’s the talk video; you can download the presentation from here.
Thank you very much for reading. If you have any comments, suggestions, or ideas, I’ll be happy to read and collaborate to grow together. ❤️
🔗 Sources
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html https://martinfowler.com/articles/is-quality-worth-cost.html https://agilemanifesto.org/principles.html
