In this ProductTank Prague talk, Jan Kaltoun, Chief Technology Officer at STRV dives into debt in the eyes of the developer and how to navigate tech debt.
Watch the talk in full, or read here for a summary of his main points:
- What is tech debt to you?
- How did it affect you in your career?
- How would you solve it?
How the talk works
For his talk, Jan asked 20 engineers who worked on a project with tech debt the above 3 questions. This puts the answers through the lens of those who have experienced it first-hand and displays what debt means to the developer.
What is tech debt to you?
Jan begins by presenting the answers he gathered to his first question, ‘What is tech debt you?’. He received a handful of answers, which include “a state where the team prioritised a quick solution over a clean one”, “occurs after some time when the project is not maintained regularly”, “a simple solution that is quick to do, but not robust or extendable” and “a nature of any software development”.
These are his takeaways from what tech debt is to engineers:
- It is inevitable
- It is prioritising development speed over output quality
- It is postponing issues for future us to solve
- It is the lack of maintenance
- It is a result of bad architectural decisions and not doing the best job possible
- It is unreadable or unclear code
- It is the fear of changes
- It is a lack of robustness and extendability
- It is a “temporary” solution
How have you been affected?
Jan then moves on to his second question, ‘How have you been affected’ by tech debt. Again, he goes through his answers, which include that “tech debt is a never ending story”, that happens “mostly on quickly growing projects” and “it is always hard to define the line when the costs saved by introducing technical debt are higher than the costs of maintaining an unsustainable codebase”.
The takeaways from how people have been affected by tech debt are:
- It was very stressful
- It meant code was duplicated all over the place
- The bad practices bulk up when fragile codebases are hard to refactor
- Time pressure was often the culprit
- Overcomplicated tech is tech debt too
- Long running projects are the ones which suffer the most
- Tech debt complexity only tends to grow
- Sometimes a little tech debt does not hurt
- Sometimes a shortcut is simpler and much faster to develop
- Documentation is essential
- Tech debt needs to have the perfect balance of the right solution, but also not over-engineered.
How to solve tech debt
Jan then concludes by looking at how to solve tech debt. The engineers he asked gave a variety of answers, which are all based on the idea that “tech debt is inevitable” and the only way forward is “to minimise it as much as possible”. The solution given is to be careful, organised and calculated with tech debt: “Get time. Refactor. Upgrade”. Jan’s answers recommend that “by documenting tech debt”, encouraging “the refactoring mindset” and to “keep thinking forward on how to prepare the code for the future” it can be made manageable.
Jan’s takeaways on how to solve tech debt:
- Think about how the code can be decoupled later on
- Always make sure to document your tech debt
- Stay up to date with the tech and the best practices for it
- Do proper code reviews, automated testing can help
- Find time to refactor, upgrade and encourage the refactoring mindset
- Make continuous improvements part of the process, define clear goals
- Assign priority to each piece of tech debt
- Do not over-engineer
- Don’t be afraid of tech debt, control it
- Choose your dependencies wisely
- Take to and make agreements with your product managers and clients
- Always leave the tech base better and clearer than you found it.
Learn more about ProductTank and find some exciting new ways to get involved!
