Technical Debt
Creating a system is not always an easy task, especially when you have several main stakeholders working on a project (developers, testers, managers, stakeholders and so on…). Everyone has different opinions about the same thing, and it can be hard for everyone to be on exactly the same page all the time. This article is about a slightly controversial topic because everyone has different opinions about what Technical Debt actually is.
According to Martin Fowler:
“(…) Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt (…)”
Technical Debt is an indicator that shows a whole team the effort it takes to create a new feature or solve a bug. If, as Developer of Project Manager, you’re not aware of the existence of Technical Debt, it can lead to:
· Your team becoming quite demotivated
· The deadline can continue to increase sprint after sprint
· Communication becomes harder
· The review of code becomes exhausting
A Technical Debt usually is overlooked in a project because it can appear in a variety of different ways:
· A developer created a function with a fuzzy name or code smell that no one understands.
o Problem: Developer 1 writes the function doSomething(). After a few weeks no one really understands what doSomething() actually does. Now imagine the whole project with non-understandable names within codes - it becomes extremely hard to maintain.
o Solution: In order to avoid this, it’s important that all developers understand what Clean Code and Code Smell are and use these best practices to write better code, no matter what language they are using.
· A specification is not well defined or a developer misunderstood a specification.
o Problem: it’s normal for a Project Owner to provide an overview describing a ticket request to create a blue button to save a formulary (for example). From a developer’s perspective they can create this button wherever they want - there is no information about acceptance criteria and it may require a lot of rework and easily create a technical debt.
o Solution: In this case, it’s important that the team has an agreement about the ticket template (user story, acceptance criteria and technical observation) to be discussed in meetings.
· The Developer team didn’t write a unit test, and the rest of the team has some concerns regarding changes in the code:
o Problem: Communication is hard in any department and if the message aren’t clear, it will provide room for errors
o Solution: In this case, everyone in the project needs to understand what is being asked of them, including the QA team.
Usually, the team needs to finish a new feature in a short amount of time, and the deadline doesn’t always allow developers to have the best practices. It’s normal and fine, but the whole team is responsible for reviewing the code smell and fixing it. Some managers reserve the whole day for solving the Technical Debt, which in my opinion it is an excellent practice.
Conclusion
Technical debt can destroy a whole project, usually it can snow ball, where it starts as small issue and easy to solve, but it’s so easy for it to be overlooked, causing the debt to grow it will be. You as developer, leader or even manager, should be tracking this indicator.
References:
· https://martinfowler.com/bliki/TechnicalDebt.html
· https://www.productplan.com/glossary/technical-debt/
· https://www.oreilly.com/library/view/clean-code-a/9780136083238/
Written by Lucas Rodrigues