Refactoring comment convaincre vos managers...

[Anthony Cassaigne]

Suite aux conversations que nous avons eu lors du club de lecture sur comment convaincre les managers ou certains développeurs (?) à la pratique du refactoring, je propose d'ouvrir ce sujet
afin de compiler une liste d'arguments que l'on peut par exemple (mais pas exclusivement) trouver à la lecture du livre "Refactoring: Improving the Design of Existing Code" de Martin Fowler.
Certains dirons pas besoin de convaincre. Appliquons cette pratique et je ne vois pas pourquoi un manager me dirait comment je dois travailler ! Argument utilisé par Martin Fowler lui même (pas exactement en ces termes).
Plutôt en ces termes :
"Of course, many people say they are driven by quality but are more
driven by schedule. In these cases I give my more controversial
advice: Don’t tell!  Subversive? I don’t think so. Software developers
are professionals. Our job is to build effective software as rapidly
as we can. My experience is that refactoring is a big aid to building
software quickly. If I need to add a new function and the design does
not suit the change, I find it’s quicker to refactor first and then
add the function. If I need to fix a bug, I need to understand how the
software works—and I find refactoring is the fastest way to do this. A
schedule-driven manager wants me to do things the fastest way I can;
how I do it is my business. The fastest way is to refactor; therefore
I refactor."

Cependant la lecture des deux premiers chapitres ce n'est pas cet argument que je retiens mais le suivant :
"Refactoring Makes Software Easier to Understand

Programming is in many ways a conversation with a computer. You write
code that tells the computer what to do, and it responds by doing
exactly what you tell it. In time you close the gap between what you
want it to do and what you tell it to do. Programming in this mode is
all about saying exactly what you want. But there is another user of
your source code. Someone will try to read your code in a few months’
time to make some changes. We easily forget that extra user of the
code, yet that user is actually the most important. [...] It does
matter if it takes a programmer a week to make a change that would
have taken only an hour if she had understood your code.

The trouble is that when you are trying to get the program to work,
you are not thinking about that future developer. It takes a change of
rhythm to make changes that make the code easier to
understand. Refactoring helps you to make your code more
readable. When refactoring you have code that works but is not ideally
structured. A little time spent refactoring can make the code better
communicate its purpose. Programming in this mode is all about saying
exactly what you mean.  I’m not necessarily being altruistic about
this. Often this future developer is me [...]"

Et vous quel est le ou les arguments que vous retenez ?