Living with technical debt

What is Technical Debt?

Taking the initial definition from Girish Suryanarayana et al, on their work at "Refactoring for Software Design Smells", design debt, code debt or technical debt, is a concept in software programming that reflects the extra development effort that will happen in the future because we have chosen and applied a quick and fast solution instead of applying the best technical solution.

Why we have Technical Debt?

Martin Fowler summarises this on his Technical Debt Quadrant:

	Reckless	Prudent
Deliberate	We don't have time for design.	We must ship now and deal with consequences.
Inadvertent	What's layering?	Now we know how we should have done it.

So, analysing this, here’s how each type may occur:

• We don’t have time for design. The team feels the time pressure and understands it will break the best practices without having yet an estimation or solution on how to address the consequences. 
• We must release now and deal with consequences. The team decides that is better to release a "quick yet not ideal solution” now and adds more debt. They understand the consequences but have a plan and solution to address them.
• What’s layering? The team does not know the best practices and takes bad decisions and implementations on the code.
• Now we know how we should have done it. Initially, the team thought they had the best solution to the problem, but now they have more knowledge of the problem and know how it should have been designed.

What can happen?

Almost everyone knows what debt is (at least you know your financial debt, right?). It is difficult to explain to stakeholders, product owners and even technical people the problem of accumulating technical debt. Worse, you might not even know what your project’s current technical debt is.

Here are some examples of when you have technical debt:

• The cost and difficulty of a change increases, eventually to the point where it becomes unmanageable. This usually happens when a product owner expects the team’s effort estimation on a feature to be small. However, in time the estimation increases significantly because someone says "well, this will be hard because we depend on an old library, and upgrading it will break our code, and then we would need to change almost every line of code.”
• Feature releases become few and far between, making customers unhappy and preventing the team from learning more about their customers sooner. The development team faces a fear of changing the code, unsure of what might break. New features require much longer development timelines and testing cycles to be safe and certain.
• The feature is difficult to estimate, making its development costs unpredictable, which happens a lot because the estimations are always changing (and usually they increase), making it very difficult to plan ahead or preview a team’s capacity.
• The change introduces more bugs. You will get more support calls, and software operations teams will need to apply more patches, hotfixes and rollbacks.
• Team morale, employee turnover, and company management are affected due to constant failures and/or bad publicity when bugs, security issues or outages appear in the live environment. Developers don’t want to work on a codebase that is hard to maintain and requires them to continually clean someone else’s mess.

How do we tackle this?

To tackle the "deliberate” technical debt at Farfetch, we have a rule of thumb that ensures that all technical decisions made are documented as "Decision Logs”.

If the chosen recommendation from a decision log adds technical debt, we track it by raising it on our Task Tracking System as a "technical debt” item that is added to the team’s backlog. Being on backlog gives the product owner and all team members the chance to groom it, apply story points, and discuss the priority of resolving it on sprint planning.

Decision Logs document the context and the reason why we are adding this technical debt to the project. We also document the expected "correct” implementation as acceptance criteria so any developer can take this on a sprint and pay down the debt. The acceptance criteria also help team members to validate the issue and closing it, which means the technical debt ended.

Regarding the "Inadvertent” type, we evangelise that anyone on our teams can raise technical debt issues on their team’s backlog, so if a development team is debugging code and finds an issue they think is technical debt, they can raise it, document it, and put it on their team’s backlog. Besides, if someone from another team comes across a bad design decision or missing code coverage on automated tests, they can either follow the "Boy Scout Rule" and leave the code better than they found it, or raise it on the team’s backlog.

Finally, when it comes to sprint planning, we also advocate that teams should allocate a part of the sprint effort to address technical debt. This is one of the biggest challenges, as it requires all team members to understand the value of addressing technical debt on their backlog, which is why it is very important to document the technical debt items and explain the impact on the business if the team does not address that technical debt soon.

How can we measure?

Since technical debt issues have story points associated with the backlog, we can quickly understand how much technical debt the project has by generating reports via our Task Tracking System.

To understand how much technical debt the team has paid off over a specific period of time, we can also see it with the number of story points that were closed with that type of item. 

Conclusion

Dealing with Technical Debt is not trivial. It requires that all your teams understand how important it is to monitor and pay the technical debt on all your projects, especially stakeholders, project managers and product owners.