Developers tend to be very intimidated when they have to take on the responsibility of maintaining software that was created a long time ago. I will not name a specific time, because it depends on the project and its scale. Some consider a project old when it is over 6 months old, while others consider it old when it has been running for years.
The biggest fear that programmers face when they have to deal with an old project is legacy code and rising technical debt. However, nothing pleases developers more than the launch of a new project, where the latest and most modern can be applied for its construction.
In most cases, it is assumed that starting a project from scratch, for example, a child, does not bring ailments or discomforts of their previous past. But is it always like this? This 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 started the project with great enthusiasm and other benefits. But, like in a horror movie, as new features were developed (agreed in each sprint), technical debt began to grow. The entire team was solely focused on creating new features and delivering them on time.
The increase in technical debt began to be noticed when additional unplanned efforts were made and the rate of delivery of functionality began to decrease, without changing equipment. After analyzing this problem, we stopped to take measures to change this situation.
What has been done to reduce this burden?
We noticed a drop in team speed after the fourth or fifth sprint, starting with the initial sprints. Because we discovered these problems early in the project, we were able to get to the root of the problem and implement solutions as soon as possible.
What is the main reason we found?
The team has been constantly working on developing new features. At the end of each sprint, the customer received feedback. Regularly correcting all critical errors, the team unknowingly introduced defects into the system.
However, they continued to work with a desire to provide the customer with new and consistent features, and in some cases, fixing these defects was not a high priority. In other cases, this fix resulted in a change in the delivered functionality, and something happened that could not happen. There were discrepancies between what was planned and what was implemented.
Clearly, there was a great need to manage the rise in technical debt. Well, it was decided to manage and work on technical debt as we developed new functionality.
The sprint planning meetings, which discuss and plan the amount of work that needs to be completed to achieve the sprint goals, created the task of managing the growth of technical debt. It also created the right expectation in the client, who realized that managing the growth of technical debt would no longer be an overload. That is, we have made technical debt an integral part of the product portfolio to make sure it is accounted for and addressed. User stories began to be evaluated taking into account refactoring if necessary.
Integration tests and automated tests have played a vital role in this whole process of developing new features and fixing technical debt in previous features. For each fixed technical debt and discovered defect, the team wrote automated tests. This practice helped them to detect the defect at an early stage, should it occur again.
Since then, we’ve made sure there’s room for refactoring in every sprint. We also helped ourselves with pair programming and it was much easier.
By implementing these practices, the team reduced technical debt, enjoyed new product development again (every programmer’s dream), and improved predictability and productivity.
When tasks in our development turn out not to be as expected, this is a clear sign that something is wrong and it is very important to stop and investigate the problem.
Faced with the problem of increasing technical debt in our code, we were able to completely eradicate this evil that developers fear with simple and effective measures.