How to sell the idea of â€‹â€‹refactoring to the project manager?
Tags: refactoring, code, webdev, management
Published: 2017-07-06 20:53:10

---
title: "How to sell the idea of â€‹â€‹refactoring to the project manager?"
published: true
description: "This can become rather difficult for a project manager, who sometimes has no knowledge of the code, to approve this type of work."
tags: refactoring, code, webdev, management
---

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](http://42lignes.com)*