In a traditional agile context, code refactoring must systematically be performed in parallel with a functionality. Refactoring brings no added value to users, but to our colleagues and the next individuals who will have to implement new features. In such a context, it can become rather difficult for a project manager, who sometimes has no knowledge of the code, to approve this type of work.
This should not be the case .
The developer judging that a piece of code should be rewritten should never be discarded without performing the return on investment calculation.
Positive aspects of refactoring
If you are asked what is good regarding code rewriting, the points to raise to these people may be:
- Improved maintenance of the program.
- Increase the velocity over the medium / long term.
- Introduction of new developers greatly facilitated
- Refactored code is much easier to improve in case of performance issues. The fact that the methods are short and well expressed makes the work of profiling much simpler.
If the person in charge is much more focused on the quality of the product
Product managers aiming at long-term quality of the product will be those most easily aware of the need for refactoring. These people know that a quality product must be able to iterate and renew itself quickly and appropriately, regardless of market constraints. A quality product is composed of modules properly designed, and implemented in the best way possible. However, the best implementation is rarely the first, hence the importance of refactoring.
If the manager is focused on time and money
We should not tell them. Really. If you want to keep your efficiency and want to increase productivity by delivering code faster, inflate your estimates to help correct the mistakes of the past. You will win in the long run. However, you have to be very cautious!
In service mode, what does it do?
If your job is to serve a customer at the hourly rate:
- The customer does not have to know that a refactoring has been done in its application. I believe, however, that it is necessary to be honest and share the benefits of such practices, even if it is more complicated to explain to someone outside the field.
- You always have to do refactoring with added value and not because it tempts us.
- Some pieces of code that have been in production for a long time and that require no modification, no matter how ugly they are, do not deserve to be rewritten.
If you are told that refactoring should not be charged to the customer, I think that is also wrong. Let's take a less precise context and head to the automobile space: when you buy a car, you use it for a certain time. You ride and take full advantage of it, however it comes a day when the oil will be used out and you will have to unblock a monetary effort to do it. The mechanic is entitled to charge you for his services and the right is identical in a software context. We are professionals working on solutions that evolve, they should not be surprised if at some time or other it is necessary to do maintenance.
I originally published this post in french on 42 lignes à l'heure
Top comments (1)
Hello, Gabriel!
Although a nice article I can honestly say that hiding the fact that a piece of code "requires" refactoring is not the best advice to give.
First of all, a developer will ALWAYS be short on time. If it is an on-going project the developer will always be asked to develop new functionality and I don't think there will be many managers paying a developer to rewrite what he/she should have written in the first place. As such the dev will always have to "inflate your estimates to help correct the mistakes of the past".
Secondly, code evolves. The term "refactor" in today's world means simply modifying the code to accomodate a new feature, which, in the vast majority of the cases, wasn't thought of when the code was written. And IMHO this is a perfectly normal process in development. A developer no longer writes a piece of code that our grandchildren will inherit and have to maintain.
If you define the term "refactoring" as fixing a problem in the code, then I think that is called bug fixing and not refactoring.
Or if you think of "refactoring" as a means to replace and code that you identified as written less optimised, than I don't think that is a thing for the client/manager to understand and pay.
Just my thoughts. ;)