Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution
What is it?
The first issue addressed was what the group felt was meant by Technical Debt.
The first opinion was that it’s where the code was not fit for purpose – in that it sort of worked but was Spaghetti Code, hacked together to solve the problem but no underlying structure. There was a strong sentiment that it’s not just programming and code but should also include a lack of adequate testing and documentation.
Some of the traits of Technical Debt identified are:
- NOT Properly Developed
- NOT Architecturally Sound
- NOT Tested
- NOT Documented
Some of the sources of Technical Debt we identified came from quick Hacks to get things to work, Prototypes that become the Product, and Legacy Code.
A very valid point raised was whether we should necessarily use the term “technical debt” as it was felt the negative connotations of the “debt” implied fault and profligacy on the part of the team.
Stories to handle Tech Debt
Agile with its Iterative approach should be a good method to tackle Technical Debt as we should be able to add stories to the backlog to address it.
However can be problematic to sell these technical stories if there is no obvious benefit to the Business. For example if we spend a sprint tackling Technical Debt Stories – any demonstration will appear no different to the previous iteration (to the outside observer). If no obvious progress seen by PO/Business they will question the value of tackling Technical Debt “It works so what are you fixing?”
Prototype become the Product
A very interesting idea to prevent prototypes becoming the product was to keep it ragged enough that it’s obviously not finished article.
A Technical Debt Sprint
One proposal was to tackle Technical Debt as a Sprint at the end of the project. However there is potentially a lack of awareness that this does have a real Commercial Cost.
Just Incur the Debt
There was a 180 degree difference in what some participants felt about dealing with Technical Debt. One side saw Technical Debt as something that the team are happy to incur and let slide for the sake of expediency, and the other side that it’s something that the team are battling to get prioritized.
Selling it to the Business
It was felt that to a large extent that getting the opportunity to tackle Technical Debt is very much a Business Decision and it’s up to us to sell the need to address Technical Debt (see above for why it’s not obvious that we need to).
We need to be clear that putting off dealing with the Technical Debt will (not might) cause problems further down the road. In particular the discussion identified:
Support Teams costs money – the worse state the code base is in the greater the time to identify and correct issues
Any new Development inherits the Technical Debt as a default overhead, which will slow down and so increase the cost of development.
This is going to happen. But these cost can appear very hypothetical to a Product Owner.
What we need is a real cost; If we can say Technical Debt is adding an additional 30% (say) on top of our development costs then that is a figure we can give to the Product Owner that they can relate to.
How can we put a number on it?
Our Agile Metrics can prove very useful here. Two great examples were:
Can we identify that the Technical Debt is (at least partially) responsible?
Comparative Size of Stories.
If we can see a trend that the average Story Estimates are increasing in size – is Technical Debt responsible?
Technical Debt needs to be dealt with or the team will find itself deeper and deeper into a Fire Fighting leading to more Technical Debt spiral. The Scrum team has to give the business options, explain (and lobby) the impacts and put the decision firmly in the hands of the customer (or Product Owner).