Correction : la différence de coût vient essentiellement du fait que les instructions ne sont pas indépendantes les unes des autres et ne sont pas indépendantes de la manière de décrire les entitités manipulées. A chaque fois que l'on veut par exemple modifier la structure d'un objet (ajouter un attribut typiquement), il convient de propager cette modification à toutes les occurences d'utilisation de cet objet dans le code. Il convient de faire ce que l'on appelle des "tests de non régression", c'est à dire vérifier que tout ce qui marchait auparavant marche encore. Si par malheur, ce n'est pas le programmeur initial qui modifie le code, alors tout se complique encore, car lui, il n'a pas rencontré l'expert, et ne sait pas "interpréter" le code écrit en termes de connaissances mobilisées pour résoudre un problème. Seul un effort considérable de documentation (rarement fait) sur le lien entre les connaissances décrites par les experts et le code réalisé permettrait de limiter les dégats....

Illustration de la correction: Imaginons une application informatique destinée à gérer des plannings étudiants. Une première version EXCEL est mise au point permettant à une secrétaire de rentrer le planning d'une semaine pour chaque classe. Cette version est capable de contrôler qu'il n'y a pas de collision de salles, et permet d'ailleurs de calculer les plannings de salle à partir des plannings de chaque classe. Ce développement (simple) a pris 40 heures.

Une réforme pédagogique met en place la pédagogie par projet. Les étudiants se regroupent librement pour travailler sur les projets, et doivent se mettre d'accord avec un tuteur pour éventuellement utiliser des dispositifs techniques (informatiques par exemple). Le programmeur reprend la feuille de calcul Excel et s'aperçoit qu'il doit généraliser la notion de classe à la notion de groupe et qu'il doit insérer les réservations des salles informatiques (traitées par ailleurs) avec les salles de cours et qu'enfin, il doit veiller à vérifier la non collision des tuteurs dans les créneaux de projet.

En théorie, il va toucher assez peu au principe de l'application, mais en pratique il va devoir modifier toutes les formules, introduire des tables supplémentaires et vérifier que tout ce qui marchait avant marche encore. Résultat 40 heures de travail.

Quelques mois plus tard, lors de la réunion des responsables de formation, il apparaît qu'il faudrait maintenant essayer d'intégrer la publication de ces plannings sur le portail étudiant que chacun peut consulter sur un poste informatique chez lui ou sur les postes de l'université. Le programmeur initial ne connait pas bien la programmation WEB, et c'est un autre programmeur qui va reprendre l'application. La notion d'élève devient obligatoire, une table des élèves avec son appartenance à un groupe nécessaire, il faut toutefois garder l'ancien système pour les affichages, ....Résultat 120 heures de travail et un système qui est devenu instable.

Toute ressemblance avec une histoire de développement logiciel existant ou ayant existée est fortuite et non volontaire!