In this ProductTank Prague talk, Nick Barbariyskiy, managing partner and tech lead of Applifting, covers the ins and outs of tech debt and how to manage it.
Watch the talk in full, or read on for a summary of his key points:
- What actually is debt?
- Is debt dangerous?
- What is technical debt?
- What are the causes?
- Where is the problem?
- So what do we do?
What actually is debt?
Nick begins his talk by defining debt. He says that we are all in debt, as the more economically developed a country, the more debt it finds itself in. This is because money is borrowed for immediate action and to invest in development, which is the same for businesses and households. Nick says hand-in-hand with this is the fact that at some point we will need to pay off the debt, with interest.
Is debt dangerous?
This leads Nick onto the question of whether debt is dangerous. He concludes that while it could be, it is also just a tool we can use. Nick’s advice is that as long as debt is careful and controlled, it is not dangerous.
What is technical debt?
Nick defines technical debt, as “the implied cost of additional rework caused by choosing an easy (limited) solution instead of using a better approach that would take longer”. Technical debt is a problem we all face in our development, says Nick, as we need a solution which is “good, cheap and fast” and to achieve all three together is impossible without it. Technical debt borrows time and effort instead of money, yet as Nick points out, in businesses and organisations “time is money”.
Nick describes two different types of technical debt:
- Reckless technical debt (to be avoided)
- Prudent technical debt (can be useful)
This useful, prudent debt usually comes from good sources, such as light technologies for startups, low effort investment into experimental features or on temporal features as well as having a mindful approach in selecting between speed and quality. Nick reminds us to always set a clear boundary between reckless and prudent technical debt, as “mess is not technical debt, mess is just mess” and the decision to make it is never rational.
Where is the problem?
Nick tells us when it comes to technical debt, the source of the issue is in culture and communication. The problem lies, he says, in the difference between the product and development sides of a business. This is because the product/business area is able to evaluate the business impact, but not always technical debt and vice versa, the development team will be able to see the technical detail, but not always judge the business impact. In order to tackle technical debt, an organisation needs to be able to evaluate its impact, which Nick says “is only possible in the collaboration between both the business and the technology”.
So what do we do?
In order to combat technical debt, Nick suggests a set of active steps and passive steps:
Active steps:
- Sort out communication
- Face the truth, every project has technical debt, log and prioritise it
- Monitor it
- Pay the interest and acknowledge it exists
- Assess how deep your debt is, in order to properly allocate resources
Passive steps:
- Set and align quality standards
- Set and align coding standards
- Define your DoD (definition of done)
- Automate
- Always review and refactor
Summary
Nick finishes with a summary of the points in his talk:
- Technical debt is unavoidable
- Technical is not explicitly bad, only uncontrollable technical debt is
- Technical debt is the same thing as your day-to-day tasks
- The core of the issue is in culture and communication
- Lending tech effort and time must be a conscious decision
