Refactoring is not a task in Backlog

Original author: Ron Jeffries
  • Transfer
Some time ago, there was quite a lot of noise on the Internet and questions at conferences about whether code refactoring tasks are the same kind of tasks as everyone else, with the need to describe them, put them in Backlog, and then move them to a new sprint. I think this is a bad idea, even in the case of the prohibitively "technical debt" of the project. And here's why:
image
When a new project starts, its code is clean and beautiful. It's time to design beautiful abstractions, write good interfaces and professional implementations. Life is Beautiful! Our project too.

image
We continue to add functionality, everything goes smoothly. Then at some point we have to cut the corner a bit, turn a little off the intended track, add a very, very small treatment for one particular case ... No, no, no crutches! Just some necessary code that brings a beautiful theory closer to a working practical implementation. Nothing bodes ill and development is going on quite vigorously.
image
Nevertheless, small blots still appear on the canvas of our ideal code picture. Some people call them "technical debt." This does not mean that you really owe someone something: this is just not very good code. But he somehow works, solves his problems.
image
As the development continues, we will come across such places in the code more often and each time we will have a choice: rush to the embrasure and rewrite everything or bypass the problematic place in order to solve another problem (the one you are currently working on). Sometimes we rush into battle, but still more often we choose the option with a workaround.
image
In each case, it only slows us down a bit. But, since as the deadline approaches, the requirements for development speed only grow, we have to gradually lower the bar of our requirements for code quality - and this leads to an increase in the number of "blots".
image
These new problem areas (in addition to the old ones) inhibit us more and more. We are aware of the problems, but the rush to solve current problems does not allow us to focus on anything else. We are forced to work more, just to maintain the same speed.
image
At some point, it suddenly turns out that half of the code that we write is intended for props, workarounds, hacks and overcoming other types of obstacles that we created earlier. Here is a good code, there is bad, but here we wrapped the fish.
image
Each walk along this minefield instead of a straight line from point A to point B suddenly becomes a tangled route through the maze, without any guarantee of achieving the final goal. Even super-efforts no longer allow you to move toward the goal at the same speed as before.
image
The importance of the problems is now visible to the naked eye. And they cannot be fixed simply by throwing everything away and starting the project from scratch. We need to perform many tasks to refactor the code, and for these tasks we need time that we have to ask the customer. Often this time will not be allocated to us: we ask for time in order to fix our own code, for the development of which time has already been allocated earlier and of which we ourselves announced earlier.
image
Even if time is allotted, you should not count on a quick result. We can only fix those problems that we see specifically now and only in that volume for which there will be enough allotted time (and there will not be much of it). We wrote this bad code for many weeks (or months), and we certainly will not have as much time to rewrite this code.

This is not the way we need to go. Long refactoring periods do not bring great and immediately noticeable benefits to the project. They are very difficult to sell to the customer, because he will not see what kind of functionality he is being asked for money. That is a bad idea. What to do?
image
Simplify! Upon receipt of each next task, we outline a plan for its implementation. If in the course of this plan we run into a “blot” of technical debt, then the task of refactoring it becomes part of the implementation of the current feature. Of course, we cannot immediately take up all the bad places in the code. But this is not necessary! If during the implementation of any new functionality you fix more old “blots” than create new props and crutches, the overall quality of the project code will improve. The next time, when working on a new task, you suddenly have to turn to the already corrected place, you will be pleased to note that it no longer requires file polishing, but immediately works well and looks nice. This is how software development happens.

Perhaps the development of each individual feature in this way will take a little longer than you originally thought. But the development of the entire set of functionalities with this approach will take less time, because at the last stages before the deadline you will be able to work with a relatively clean code base, adding new functionality will not take time to find workarounds. In addition, such a personal approach to your development will have a good effect on the performance of the entire team.
image
Repetition is the mother of learning. With each new feature, we make the code a little cleaner. Only a little bit, but every time. Many times, “a little” at some point, they will allow with a calm soul to write a new, well-working feature, for which it is not a shame, instead of tearing your hair out and struggling with the desire to remove all this garbage altogether.
image
The moment of awareness of the usefulness of continuous refactoring is not as far away as you might think. Some people began to notice him by the end of the same sprint in which they began to use this approach. The forces of continuity and incrementality of the process make themselves felt very quickly. FROM some moment, LESS TIME takes less time to complete a new task with refactoring than to do the same task without refactoring (due to the time spent earlier on improving the accompanying code).

The work goes better, the code becomes cleaner and we give the customer more functionality than we could before. Everybody wins.

So refactoring is not a task in Backlog, it is part of every task in it.

Also popular now: