As developers, it is a difficult task to explain to our product owner the business value of a piece of technical work that needs doing. It is also difficult to provide risk analysis for these tasks. In turn, as a product owner, it is hard for them to prioritise such technical work with out coming across technical reasoning and jargon.
At Barnardos, together with Readify consultant Abdelmawla Mohamed, we are exploring how we can define these technical work in such way that it is easy for the developers to describe the work involved and the risks associated with it without using technical jargon, while still providing a common language and consistent representation of impact and risks to help the product owner with prioritising.
Workshop – Day One
What is Tech Debt to us?
Today we tried to gather what Tech Debt meant for each developer and how far we are from a common understanding. These are some of our views.
- “Tech Debt is work that has been purposefully set a side to work on at a later time. It is defined, time-boxed and has an expected end result.”
- “Tech debt is a piece of technical work that doesn’t have business requirement, but can still add value to the business.”
- “A programming task, which doesn’t have any business / user requirements and its not adding / taking away functionality from the program.”
- “Tech Debt is a Debt so we need to resolve it whenever we can as early as possible, otherwise we need to pay the interest.”
- “Tech Debt is where we’ve accepted a bad decision deliberately or mistakenly for how to implement some part of the system we’re working on. This decision results in sub-optimal (read bad) code, and will eventually need to be fixed.”
- “Tech debt represents the amount of effort required to refactor code for an ‘optimal solution’ which results from working on small stories where the focus is on short-term and quick results.”
Surprisingly, none of us are wrong here, says Abdo. Everyone views tech debt as an additional technical work that needs doing to avoid more work in the future. Also we agree that it is not a requirement that comes from the business but rather a deliberate decision to postpone some of the technical work due to time constraints or an incorrect design/code found during development that requires rework.
How can we better describe a Tech Debt?
In this exercise, our goal is to identify some keywords that tells us what a particular Tech Debt is about. In other words, what are the impact areas of a Tech Debt?
The following areas were suggested:
- Performance
- Productivity
- Reliability/Stability
- Maintainability
- Obsolescence
- Architecture/Design
- Quality
Workshop – Day Two
To Be Continued.
Rajeev's Curiosity 