Table of Contents
Introduction
Developers tend to feel very fearful when they must take responsibility for the maintenance of software that has been built a long time ago. I will not refer to a specific time because that depends on the project and its magnitude. Some consider a project to be old if it is more than 6 months old, while others consider it old when it has been in operation for years.
The biggest fear programmers face when having to take care of an old project is the legacy code and the technical debt growth. However, nothing makes developers happier than starting a new project, where the latest and most modern can be applied to its construction.
Most of the time, it is assumed that starting a project from zero, such as a baby, does not bring ailments or discomforts of their previous past. But is this always the case? That is what we are going to discuss in this article.
My project experience with technical debt
Today, I would like to share an experience I had recently on a project I was working on.
Our development team began the project, with a lot of enthusiasm and other advantages. But, as if it were a horror movie, while new functionalities were being developed (agreed upon in each sprint), technical debt was starting to grow. The entire team was solely focused on building new functions and delivering them on time.
The technical debt growth began to get noticed when additional unplanned efforts were incurred and the speed of delivery of functionalities began to decrease, without changing the equipment. After having analyzed this problem, we stopped to take measures to redirect this situation.
What was done to reduce this burden?
We noticed a drop in the team speed after the fourth or fifth sprint, starting with the initial sprints. Because we detected these issues at the beginning of the project, we were able to examine the roots of the problem and implement solutions as soon as possible.
What was the main cause we discovered?
The team was continuously working on developing new features. At the end of each sprint, the customer was delivered for feedback. By regularly correcting all critical errors, the team unknowingly introduced defects into the system.
However, they continued to work with the desire to deliver new and agreed functionalities to the client, and correcting those defects was not given priority in some cases. In other cases, this correction caused the delivered functionality to change, and what could not happen ended up happening. There were differences between what was planned and what was delivered.
Obviously, there was a great need to manage the technical debt growth. Well, it was decided to manage and work on the technical debt as we developed new functionalities.
In the sprint planning meetings, which is where the amount of work to be done to achieve the sprint objectives is discussed and planned, a job was created to settle the technical debt growth. This also established the right expectation with the client who understood that managing the technical debt growth would no longer be an overload. That is, we made technical debt an integral part of the product portfolio to make sure it is considered and addressed. User stories began to be estimated considering refactoring when necessary.
A vital role in this whole process of developing new functionalities and correcting technical debt in previous functionalities were integration tests and automated tests. For every technical debt corrected and a defect found, the team wrote automated tests. This practice helped them detect the defect early if it happened again.
From then on, we made sure that each sprint had room for refactoring. We also helped ourselves with pair programming and it was much easier.
By implementing these practices, the team reduced technical debt and once again enjoyed the development of a new product (a dream of every programmer), as well as better predictability and productivity.
Conclusion
When tasks in our development turn out differently than expected, it is a clear symptom that something is wrong, and it is critical to stop and investigate the problem.
Faced with the problem of technical debt growth in our code, we were able to totally eradicate this evil that developers fear by using simple and effective measures.
