In a popular online discussion group the following question was asked: “Why does technical debt accumulate? “Why do technical and functional project team members let that happen?
What is technical debt? Personally, I had not heard the phrase “technical debt” before. Interested, I looked it up on the internet. What I found was that technical debt (also known as design debt or code debt) is a metaphor referring to the eventual consequences of poor system design, software architecture or software development. 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 deliver a winning product – one that delivers what is needed, within budget and schedule, with the desired quality. Unaddressed technical debt increases software disorder – in short, like any kind of debt, too much leads to a failed project.
A key part of the concept of technical debt is that, like financial debt, it must be paid at some point in the future. Moreover, like financial debt, accumulated technical debt incurs interest on top of interest, making it cumbersome to build a project. Although the term seems to be used mainly in software development, it can also be applied to other product development efforts.
Why does technical debt accumulate? The main reason for technical debt accumulation is that the development team (whether using agile or other approaches) does not have a complete understanding of the “big picture” at the outset of the project. It is understood that such a “big picture” is hard to obtain at the beginning of a project, especially on large complex projects. However, there are three things you can do early in the project to begin to bring such a view into focus is to:
- Understand the stakeholder expectations from the beginning,
- Translate these expectations into a verifiable and feasible language for the developers, and
- Use the verifiable and feasible language to verify the design and coded product meets what was translated and validate the coded and verified product meets its intended purpose in its operational environment.
Failing to spend time at the beginning to understand stakeholder expectations and define the scope of the project leads to an accumulation of technical debt. It is like the old saying: “Pay me now or pay me later, if later you will be paying me a lot more!”
Stakeholders’ Expectations: The key to minimizing technical debt is to ensure that stakeholders’ expectations are well understood and the translations are complete, correct, and unambiguous. Furthermore, team members need to be aware of not only the explicit expectations the stakeholders possess but also their implicit expectations. Implicit expectations are what is implied but is not stated explicitly by the stakeholders. This is where interfaces, -iliites, and standards come into play. These represent requirements, which if not included in the requirement set, will result in a product that does not meet the stakeholder expectations. The development team needs to understand these things exist and if not addressed there will be a large technical debt at the end.
User stories, use cases, scenarios, etc. are helpful, in part, to driving out both the explicit and implicit expectations. While valuable tools, they tend to focus solely on the user interaction with the product being developed. Thus functionality and performance are the main focus FROM THE USER PERSPECTIVE. For each item in a use case or user story, someone needs to address the SYSTEM PERSPECTIVE by asking : “What does the product need to do to enable the user to interact in their expected manner?” The result is what needs to be translated to the developers. The main form of this translation? Requirements.
Projects that don’t understand the role requirements play in the development process are doomed to fail.
Technical debt and risk: Personally, I like the concept of technical debt and the need to take steps to prevent the technical debt and avoid the high interest consequences later on in the project. Technical debt represents risk to the project – risk that will prevent the project from delivering a winning product. We at ArgonDigital have been preaching the need to minimize risks for years. A high amount of technical debt, as you reach the end of the project, puts your project at risk of failure of system validation and exposes your project to potential costly rework in order to meet the stakeholder expectations.
You can read more about risk and requirements in my paper on the subject Triple Your Chances of Project Success Risk and Requirements . The emphasis of this paper is the common requirement development and management risks that can have an impact on a project’s success, the possible consequences of these risks, and strategies to mitigate the risks and avoid the associated consequences.. Recognizing the fact that poor requirements represent a significant risk to your project and mitigating these risks can triple your chances of project success.
Comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.
