Pourquoi réécrire un projet en partant de zéro ? Parce que l'ancien code est un fatras ?

Pourquoi réécrire un projet en partant de zéro ? Parce que l'ancien code est un fatras ?
Ou parce qu'il est plus facile d'écrire que de lire un code ?

Pour un nouveau projet, certains développeurs préfèrent exploiter un code existant et l'adapter à de nouvelles fonctionnalités. D'autres par contre peuvent décider de partir de rien alors qu'il y a un code existant. Mais Joel Spolsky, un développeur de logiciels à New York, estime qu'écrire un programme à partir de zéro est la pire erreur stratégique qu'un développeur puisse commettre.

Dans l'espoir de mieux se faire comprendre, Joel avait énuméré plusieurs cas, dans un billet datant de l'année 2000. Entre autres, le navigateur de Netscape qui n'existe plus aujourd'hui. Netscape 6.0 allait entrer dans sa première version beta publique à l'époque en sautant la version 5.0. La version 4.0 fut sa dernière version majeure et avait été publiée trois ans plus tôt. Trois ans, c'est terriblement long dans le monde de l'Internet, déclarait Joel. « Pendant ce temps, Netscape était assis, impuissant, alors que sa part de marché s'effondrait », ajoutait-il. La cause, selon Joel, est que ses développeurs ont décidé de réécrire la base de code à partir de zéro.

Pièce jointe 373990

D'après Joel Spolsky, les développeurs sont, dans leur for intérieur, des architectes. Et la première chose qu'un architecte veut faire quand il arrive sur un site est de le raser complètement pour construire quelque chose de grandiose. Ils sont un peu hostiles à la rénovation progressive qui consiste entre autres à bricoler et améliorer l'existant.

Il y a une raison subtile pour laquelle les programmeurs veulent toujours jeter le code et recommencer. La raison en est qu'ils pensent que l'ancien code est un fatras. Ils ont probablement tort. La raison pour laquelle ils pensent que l'ancien code est un fatras est qu'il est plus difficile de lire le code que de l'écrire. C'est pourquoi la réutilisation du code devient si difficile.

L'idée que le nouveau code est meilleur que l'ancien est manifestement absurde, déclarait Joel. L'ancien code a été utilisé. Il a été testé. Beaucoup de bogues ont été trouvés et ils ont été corrigés. Il n'y a rien de mal à ça. Chacun de ces bogues a pris des semaines d'utilisation dans le monde réel avant d'être trouvé. Le programmeur a peut-être passé quelques jours à reproduire le bogue dans un laboratoire et afin de le corriger. Même s'il s'agit de beaucoup de bogues, le correctif peut être une ligne de code, ou même quelques caractères. Mais, il ne faut pas perdre de vu que beaucoup de temps et de travail sont allés dans cette ligne de code ou ces quelques caractères.

Quand vous jetez l'ancien code et recommencez à zéro, vous jetez toute cette connaissance, toutes ces corrections de bogues, des années de travail de programmation. Vous jetez votre leadership sur le marché. Vous donnez un cadeau de deux ou trois ans à vos concurrents. Vous gaspillez une quantité exorbitante d'argent en écrivant le code qui existe déjà.

Même des changements architecturaux assez importants peuvent être faits sans jeter le code. Aussi, un ancien code jugé inefficace peut devenir très efficace avec des améliorations. Pour Netscape, l'opinion publique semble être que l'ancienne base de code était vraiment mauvaise et lente. Néanmoins, cela fonctionnait très bien sur un grand nombre de systèmes informatiques réels, et n'affectait qu'une petite partie du projet, qu'il était possible d'optimiser sans être obligé de réécrire tout le code.

Pour clore ses propos, Joel dit qu'il « est important de se rappeler que, lorsqu'on part de zéro, il n'y a absolument aucune raison de croire que l'on va faire un meilleur travail que la première fois. Vous n'avez probablement pas la même équipe de programmation qui a travaillé sur la première version, donc vous n'avez « plus d'expérience ». Vous allez juste refaire la plupart des vieilles erreurs et introduire de nouveaux problèmes qui n'étaient pas dans la version originale ».

Source : Joel Spolsky

Et vous ?

:fleche: Qu'en pensez-vous ?
:fleche: Préférez-vous recommencer les projets en partant de rien plutôt que de faire évoluer un code existant ? Pourquoi ?
:fleche: Avez-vous déjà pris l'initiative de réécrire un projet en repartant à zéro ? Comment a été cette expérience ?

Voir aussi :

:fleche: Trolldi : une brève histoire totalement exacte des langages de programmation, qui est complètement inspirée de faits
:fleche: Quel est l'effet du langage de programmation sur la qualité du logiciel ? Une étude tente de clarifier la situation
:fleche: Quelques points clés sur la programmation défensive, destinée à assurer la fonction continue d'un logiciel dans des circonstances imprévues

En principe, dans une entreprise qui fonctionne normalement, ce ne sont pas les développeurs lambda qui devraient prendre la décision de réécrire un projet.
Cela se décide au minimum au niveau du chef de projet. Et même plutôt au dessus, au niveau d'une direction technique et de la direction générale, parce qu'un simple chef de projet n'a en général pas tous les éléments pour juger du risque qu'il fait courir à sa société.

Tous ses points sont valides, mais il ne faut pas non plus voir le code existant comme le graal et la perfection que l'on ne peut plus atteindre et tout nouveau code comme forcément moins bien.
Je pense qu'un code trop vieux, s'il n'a pas été pensé parfaitement - et plus le code est vieux moins il l'aura été imo -, le faire évoluer devient très difficile voire quasi impossible sans remanier et réarchitecturer un sacré chantier.
De plus ce remaniement aura le même genre d'effets : supprimer du vieux code, réécrire du nouveau, et les problèmes dont il parle peuvent tout autant arriver.
Sans compter qu'un tel chantier sera rarement accepté par les supérieurs, et donc ça finira par du hack ci et là pour corriger le nouveau bug - et quand ils s'accumulent, l'historique des corrections devient de plus en plus un frein à l'évolution..

J'ai voté "pas d'avis" car cela dépend de la tâche, du temps qui est accorder à la réaliser.
Faire confiance au code source si c'est juste modifier une partie du code source ou encore ajouter une "petite" fonctionnalité à un projet interne ou qui a fait l'objet de sous-traitance.
Vérifier les ajout "extérieur" en détail avant ou durant ou après en fonction du temps et charge de travail globale.

P.S. : mais comme je veux arrêter le DEV, c'est déjà une vision abandonnée de ma part...
P.S. 2 : modifier le code source ou remplacer du vieux code par du nouveau, cela dépend de la licence d'utilisation... L'algorithmique reste bien souvent, pas forcément les appels de méthodes et déclarations de class. A l'exception d'une mise à jour de fichier du même groupe d'auteurs extérieur au projet global je n'y toucherai pas...
P.S. 3 : L'usage d'un RAD comme WinDev 22 Express ou C++ Builder ou NetBeans est lui très souvent le choix que je fais pour partir de zéro. Sauf si le projet n'est pas aussi dense ou complexe que cela et qu'une application console/terminal avec ouverture du port réseau pour accéder à une base de données, dans ce cas, VisualStudio ou GCC...
P.S. 4 : Une application terminal/console avec une interface GUI accessible via un port quelconque et exploitant le protocole HTTP est plutôt intrigante à envisager, donc Eclipse...

Je pense que ça dépend de deux facteurs importants:
- la qualité de l'API de la codebase
- la techno utilisée et les alternatives

Une codebase bien structurée dès le début, avec une bonne API, sera simple a améliorer vu qu'il faudra modifier les implémentations, et pas l'architecture.
Ce sera donc juste du refactoring et de la correction de bug (d'ou l’intérêt de voir plus loin que le bout de son nez quand on pense a l'architecture au début).

Au niveau d'un changement de techno, je pense que ça peut en valoir la peine par contre.
Imaginons que l'application est basé a 90% sur une vielle techno, qui fait mal son boulot, et que le passage vers une nouvelle techno réduirait énormément
la codebase tout en la simplifiant... si les dev sont formés a cette nouvelle techno alors cela ne sera que bénéfique, si le projet est un projet a long terme.

Mais dans tous les cas, une ré-écriture de zéro est toujours très risquée, même si cela dépend beaucoup de la complexité de l'application a la base.
Personnellement, je suis plus partisan de gros refactorings, mais pas d'une ré-écriture complète d'un seul coup.
Entre chaque refactor au moins, on peut vérifier que l'application fonctionne toujours bien sur les points liés aux modifications, et cela est bien plus simple a
voir que si on devait tout refaire de zéro.

La reécriture s'impose souvent , car la fonction du logiciel est connu, mais le code source a pu être perdu dans le temps .

Cela arrive plus souvent que l'on pense.

Après la reécriture permet de valoriser la nouvelle équipe, il faut bien qu'elle apporte un plus par rapport à l'ancienne équipe. Comment justifier le ROI sur le redéveloppement si on apporte pas de bonnes raisons même si tenant par les cheveux comme on dit...

Hello,

Je pense qu'un certain nombre de critères impactent la décision, dont entre autres :
- l'ampleur du projet,
- la documentation technique et fonctionnelle existante,
- la situation du code (ancien/récent, avec des tests ou pas),
- réutilisation de certaines fonctionnalités ou pas,
- le temps imparti,
- la pérennisation de l'application à long terme (changement de techno par exemple)

A titre personnel, il m'est arrivé de réécrire des programmes de 30k lignes car trop de codes "spaghettis" et morts dont le résultat était totalement incertain en cas de modifications profondes. Par contre, certains modules étaient très bien écrits, et donc facilement réutilisables. Résultat ? un code allégé de 70% qui répondait aux besoins nouveaux et qui en plus prenait moins de place mémoire.
Dans certains cas restreints (en terme d'ampleur) j'ai totalement réécrit.
Enfin, dans d'autres cas, j'ai juste modifié quelques lignes de codes et surtout modifié les tables de paramétrage. Mais là, le code était quasi totalement paramétré, ce qui facilitait la chose.

Mais tout ça c'est du passé pour moi, je ne fais maintenant plus que tester le travail des développeurs :mouarf:

Je ne suis pas vraiment d'accord avec ce qui est dit dans la news sur le fait que "L'idée que le nouveau code est meilleur que l'ancien est manifestement absurde, déclarait Joel. L'ancien code a été utilisé. Il a été testé.".

Si on réécrit du code, ce n'est pas pour qu'il y ait moins de bugs, c'est pour le rendre plus évolutif, plus facile à maintenir. Un programme lorsqu'il est écrit, est concu pour arriver à un scope fonctionnel donné. Ensuite, lorsqu'on lui ajoute des fonctionnalités, sa conception originale peut révéler des limites. Il arrive aussi qu'a force de corrections, le code initialement propre, devient bordélique. Dans ces 2 cas, il arrive un point où il faut agir (Idéalement, même il faudrait agir au fur et à mesure, mais ce n'est pas toujours possible, pour des raisons de temps ou de vision incomplète).

Lorsqu'on en arrive à un point où il faut agir, la solution de réécrire de zéro est rarement bonne. Parfois elle est inévitable (notamment si on change de langage...), mais souvent il est préférable d'agir en plusieurs phases. La première est de séparer la code base en modules. Cette séparation permettra ensuite de traiter chaque module indépendamment. L'intérêt de cette approche est surtout de diminuer le volume de code à traiter en une fois. Réécrire tout un programme de 0 est souvent une tâche trop grosse et risquée. Traiter un module réduit le risque.

On pourrait se dire que ce serait encore mieux d'avoir cette approche dès le départ et parfois de nouvelles équipes critiquent le boulot de l'ancienne. Mais le fait est que le concepteur original du programme n'avait pas toutes les billes en mains, alors qu'une fois le logiciel écrit et stabilisé, il est plus simple de voir comment on aurait pu l'écrire différemment.

Salut,

Citation:

---

Envoyé par Joel Spolsky

Joel Spolsky [...] estime qu'écrire un programme à partir de zéro est la pire erreur stratégique qu'un développeur puisse commettre. [...] L'idée que le nouveau code est meilleur que l'ancien est manifestement absurde, déclarait Joel. [...] L'ancien code a été utilisé. Il a été testé. Beaucoup de bogues ont été trouvés et ils ont été corrigés. [...] Pour clore ses propos, Joel dit qu'il « est important de se rappeler que, lorsqu'on part de zéro, il n'y a absolument aucune raison de croire que l'on va faire un meilleur travail que la première fois.

---

Je renvoie les propos de M. Joel Spolsky à ce qu'a écrit un jour Thomas Edison : "Ce n'est pas en améliorant sans cesse la bougie qu'on a inventé l'ampoule"

Même si il est vrai que :

- c'est risqué de redémarrer de zéro,
- qu'on va repasser par une longue période de débuggage,
- qu'on risque de découvrir un problème qu'on avait pas anticipé,
- etc

Pour moi repartir de zéro, c'est le chemin de l'innovation.


Je pense que le point de vu de M. Spolsky est plus celui d'un employeur :D "ne pas réinventer le fil a couper le beurre car.... ça fait perdre du temps et ça peut coûter plus cher". Bien évidemment, moi même je ne suis pas toujours repartie de zéro lorsque je développais du matériel électronique mais à chaque fois que je l'ai fait j'ai innové et ce n'était pas moins fiable que lorsque je réutilisais.

Citation:

---

Envoyé par Bousk

Tous ses points sont valides, mais il ne faut pas non plus voir le code existant comme le graal et la perfection que l'on ne peut plus atteindre et tout nouveau code comme forcément moins bien.
Je pense qu'un code trop vieux, s'il n'a pas été pensé parfaitement - et plus le code est vieux moins il l'aura été imo -, le faire évoluer devient très difficile voire quasi impossible sans remanier et réarchitecturer un sacré chantier.
De plus ce remaniement aura le même genre d'effets : supprimer du vieux code, réécrire du nouveau, et les problèmes dont il parle peuvent tout autant arriver.
Sans compter qu'un tel chantier sera rarement accepté par les supérieurs, et donc ça finira par du hack ci et là pour corriger le nouveau bug - et quand ils s'accumulent, l'historique des corrections devient de plus en plus un frein à l'évolution..

---

J'ai déjà vu des applications que je qualifie personnellement d'amas de hacks, plein de hacks peuvent donner un soft :ptdr:

Citation:

---

Joel Spolsky, un développeur de logiciels à New York

---

A lire ça on pourrait croire que Joel Spolsky est un développeur lambda, ce qui est loin d'être le cas... Son blog était très suivi à une époque (mais il n'écrit plus beaucoup aujourd'hui), et c'est un des fondateurs de StackOverflow. Il a même son article Wikipedia ;)

Sinon j'aime bien le concept de faire une news à partir d'un article qui date d'il y a 18 ans :P (même si l'article est toujours d'actualité)

Pour revenir au sujet, je suis moins catégorique que Joel Spolsky. Parfois le code existant est une sombre m***e, et on perd moins de temps à repartir de zéro qu'à essayer de régler tous les problèmes du code existant. En d'autres termes, et pour reprendre l'analogie avec l'architecture : si les fondations sont pourries, impossible de construire un immeuble solide dessus. Et si l'immeuble est déjà construit sur des fondations pourries, toucher aux fondations est délicat, voire impossible, sans faire écrouler l'immeuble.

l'histoire de netscape me semble peut viable car entre netscape 4 et 6 la vision n'était plus la même netscape 4 utilisait le système de layer qui fut un mauvais choix et fort possible qu'il fallait soit faire des modification de façon profonde ou repartir de zero de plus il me semble que firefox a été fondé a partir du code de netscape 6.

Je cite un passage important de l'article original :

Citation:

---

As a corollary of this axiom, you can ask almost any programmer today about the code they are working on. “It’s a big hairy mess,” they will tell you. “I’d like nothing better than to throw it out and start over.”

Why is it a mess?

“Well,” they say, “look at this function. It is two pages long! None of this stuff belongs in there! I don’t know what half of these API calls are for.”

[...]

Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

---

À mon avis, le problème de fond de l'exemple ci-dessus, c'est le manque de commentaires dans le code.
Quand les API nous obligent à écrire du code bizarre et contre-intuitif pour que ça marche dans les cas limites, il faut commenter pourquoi on a écrit telle bizarrerie et quel cas particulier cela prend en compte.

De manière générale, chaque fois que l'on écrit un code qui ressemble à du mauvais code, mais qui est justifié si on connaît la raison, alors cette raison doit apparaître dans le code, par exemple sous la forme d'un commentaire. Sinon, le code que l'on écrit est effectivement mauvais et, parmi les développeurs qui reprendront le code et se plaindront de la mauvaise qualité du code, certains auront raison de se plaindre. (D'autres auront tort de se plaindre, car ils feront pareil.)

La problématique avec du code existant c'est qu'au moment de sa création il répondait à un besoin précis.
Puis au fil du temps de la vie du projet , il est surement refactoré plusieurs fois - toujours en urgence, et jamais comme il faudrait - pour finalement au bout de 10 ans ne plus faire du tout ce pour quoi il était prévu à la base (j'exagère à peine). Du coup le code n'est pas forcément mauvais mais la conception initiale n'est plus adapté au nouveau besoin.
C'est dans ces cas là que je juge pertinent de réecrire.

Parfois, c'est l'équipe initiale qui préfère réécrire : évolution du contexte technique (outils) ou recentrage (changement de spécifications larvé : apparaitre à un point B tout en disparaissant du point A, c'est un déplacement).
Il faut des retours utilisateur très précis (qu'est-ce qui est utile, qu'est ce qui sert peu, qu'est-ce qui est gênant/inutile) de sorte à associer une évolution technique à une évolution des spécifications : il faut solidariser la demande, laquelle n'est souvent pas assez forte sur ce genre de projet.
Au niveau maitrise d'ouvrage, une fois n'est pas coutume, il faut des gens compétents sachant demander (et comprendre) des documents de conception justifiant l'effort (à la fois les nouveaux et les anciens ...).
Parfois, un peu de demande de rétro-ingénierie suffit à mettre une nouvelle équipe dans le code d'un ancien projet ...
Je pourrais citer d'autres écueils, mais avec ceux-là, on a déjà 90% des échecs.

J'ai sans doute cité cet article de Joel Spolsky des dizaines de fois en dix ans, et il n'était pas nouveau quand je l'ai personnellement découvert. C'est donc très rigolo de le voir en actualité ce jour.

Ce qu'il dit d'ailleurs, ce n'est pas qu'il ne faut jamais réécrire. C'est qu'il ne faut pas réécrire en oubliant les leçons du passé. J'ai appris à la dure :aie: qu'il avait raison. Une bonne partie des horribles verrues qu'on trouve dans un code ancien sont des réponses à des expériences douloureuses, et qu'il ne faut ps perdre. repartir d'une page blanche en se disant "c'étaient tous des nuls", c'est aller droit dans le mur. Repartir d'une page blanche en se disant "bon, c'est horrible, mais il doit bien avoir une raison pour laquelle ils se sont fait chier à faire ça", par contre, ça marche. Je l'ai fait. Dans la douleur, mais je n'ai perdu aucune des fonctionnalités de ce code de 36 ans d'âge que j'ai entièrement refait depuis zéro.

(Bon, soyons honnête, il y a deux algos, j'ai rien compris, j'ai repris tel quel, et vérifié que le résultat ne changeait jamais, sur une volumétrie de 2 millions de cas de prod, soit un an de traitements. Tout le reste, propre et maintenable. Et le client a mesuré qu'il a économisé plus d'un équivalent temps plein en maintenance, sur les 4 premières années. Pour un projet de 172 jours).

Le problème qui peut se poser aussi c'est qu'un vieux code est écrit avec de vieilles technos et qu'il est dur de recruter de jeunes talents sur des technos obsoletes (on peut les comprendre). Avec un marché de l'emploi des développeurs comme il est aujourd'hui, et les nouveaux langages ou framework qui attirent les jeunes tous les 4 matins, avoir du code "frais" c'est aussi faciliter le recrutement et donc la survie du projet.

Citation:

---

Envoyé par persi

Le problème qui peut se poser aussi c'est qu'un vieux code est écrit avec de vieilles technos et qu'il est dur de recruter de jeunes talents sur des technos obsoletes (on peut les comprendre). Avec un marché de l'emploi des développeurs comme il est aujourd'hui, et les nouveaux langages ou framework qui attirent les jeunes tous les 4 matins, avoir du code "frais" c'est aussi faciliter le recrutement et donc la survie du projet.

---

Certaines applications sur lesquelles je travaille sont encore en Cobol.
Curieusement, je n'ai pas trop de mal à trouver des dev (y compris des jeunes) mais j'ai surtout un gros problème de TJM et de turn over.

Si je prends quelqu'un de déjà formé, le TJM explose et j'ai mon contrôleur de gestion qui bloque.
Et lorsque je prends un jeune que je fais former, j'ai besoin qu'il reste au moins 20 mois sur le poste pour amortir le coût de la formation mais assez souvent, trop souvent, ils partent avant ou en tout cas, beaucoup trop rapidement car une fois formé et avec un peu d'expérience, leur valeur sur le marché grimpe et ils vont au plus offrant.
Je ne peux pas leur en vouloir car j'ai fait de même à mes débuts (après 3 ans dans ma première SSII, je suis parti ailleurs en augmentant mon salaire de 30% d'un coup).

Citation:

---

Envoyé par persi

Le problème qui peut se poser aussi c'est qu'un vieux code est écrit avec de vieilles technos et qu'il est dur de recruter de jeunes talents sur des technos obsoletes (on peut les comprendre).

---

Sachant que l'esprit est modelé par son environnement, cela arrive. Mais il a un instant il c'est plongé dans l'histoire technique, il y a effectivement des chances que les vielles techno aient réussi à séduire comme elles l'ont fait avec les "pionniers". ;)

Citation:

---

Envoyé par persi

Le problème qui peut se poser aussi c'est qu'un vieux code est écrit avec de vieilles technos et qu'il est dur de recruter de jeunes talents sur des technos obsolètes (on peut les comprendre). Avec un marché de l'emploi des développeurs comme il est aujourd'hui, et les nouveaux langages ou framework qui attirent les jeunes tous les 4 matins, avoir du code "frais" c'est aussi faciliter le recrutement et donc la survie du projet.

---

(1) oui, mais si tu fais un code "frais" qui ignore tout l'historique des vieux nanards, tu vas te retaper tooooooous les bugs qui avaient tant fait souffrir tes prédécesseurs. Pas glop. Une refonte de code, ça se fait avec des outillages systématiques de test automatique. C'est ce que dit l'article. C'est ce que j'ai fait.

(2) On peut former des cobolistes, hein. Moi, je n'avais pas d'informatique sur mon CV, on m'a lançé dans le grand bain, et on m'a tutoré. Et j'ai fini par être productif. ce qui nous amène à :

Citation:

---

Envoyé par Saverok

Certaines applications sur lesquelles je travaille sont encore en Cobol.
Curieusement, je n'ai pas trop de mal à trouver des dev (y compris des jeunes) mais j'ai surtout un gros problème de TJM et de turn over.

Si je prends quelqu'un de déjà formé, le TJM explose et j'ai mon contrôleur de gestion qui bloque.
Et lorsque je prends un jeune que je fais former, j'ai besoin qu'il reste au moins 20 mois sur le poste pour amortir le coût de la formation mais assez souvent, trop souvent, ils partent avant ou en tout cas, beaucoup trop rapidement car une fois formé et avec un peu d'expérience, leur valeur sur le marché grimpe et ils vont au plus offrant.
Je ne peux pas leur en vouloir car j'ai fait de même à mes débuts (après 3 ans dans ma première SSII, je suis parti ailleurs en augmentant mon salaire de 30% d'un coup).

---

Pour le turn-over, ben, de toutes façons, il y a le même problème sur les nouvelles technos. On a beaucoup de mal à retenir nos devs, ici. Spécialement les jeunots.

Pour les anciens, c'est le problème des grands comptes, ils sont incapables de s'adapter aux réalités du marché. Ils ont contrôlé les couts pendant 15 ans, et ça leur revient dans la gueule maintenant. si j'étais totalement cynique, je dirais que le marché a attendu que je ne sois plus dans le pool disponible pour exploser niveau tarif(ben oui, je ne tire plus la moyenne vers le bas...). Un vieux qui a vingt ans de bouteille, et qui est capable de corriger un problème avant même que sa hiérarchie ne s'en rende compte, ça a un cout. et il n'y a quasiment plus que ça sur le marché, en effet. J'ai vu entre 2000 et 2014 la qualité moyenne du coboliste moyen croitre radicalement. En 2000, j'étais nul, débutant, et la plupart ne m'arrivaient pas à la cheville. En 2010, j'étais un vétéran efficace, proactif, et apprécié, et il était difficile de trouver moins bon que moi sur le marché.

Fatalement, le TJM augmente, dans ces conditions. Mais tant que l'acheteur moyen ne comprend pas la valeur ajoutée qu'on les cobolistes du jour par rapport à ceux de 2000(une productivité multipliée par 10, au bas mot), ben il ne voit pas pourquoi il devrait ne serait-ce qu'ajuster les tarifs de 2000 par rapport à l'inflation.