Est-il beaucoup plus coûteux de corriger un bogue à la fin du projet?

Dans un article de blog d'Andrew Hay , l'axiome suivant a été posé:

Corriger un bogue à la fin du projet coûte beaucoup plus cher que de corriger le même bogue plus tôt dans le projet.

Cependant, cela ne semble pas certain, surtout après avoir lu un article de blog sur Less Wrong , et les données que j'ai vues pour le sauvegarder sont extrêmement anciennes.

Cet axiome est-il toujours exact aujourd'hui?

Les seules données réelles que j'ai jamais vues sont Boehm et Papaccio, Comprendre et contrôler les coûts des logiciels .

Cela remonte à 1988 et était une étude d'environ 80 projets logiciels. Ils ont conclu qu'une décision prise tôt et corrigée tardivement pourrait coûter 50 à 200 fois ce qu'elle aurait été si elle avait été corrigée tôt. Mais le type de décisions très précoces dont ils parlent sont le système d'exploitation sur lequel s'exécuter et la langue et la base de données à utiliser.

Ces chiffres peuvent donc être exagérés par rapport au développement logiciel d'aujourd'hui. Cependant, nous avons maintenant beaucoup d'expérience dans le domaine et nous savons instinctivement que cela reste vrai jusqu'à un certain point.

À l'extrême, nous savons que si une défaillance des exigences est détectée juste avant de passer à la production, cela entraîne beaucoup de retouches et retarde ou annule le projet, où s'il avait été détecté avant la fin des travaux, nous ça aurait été bien.

Edit: Doc Brown fait un bon point dans son commentaire.

Les recherches de Boehm ont été effectuées sur les projets COBOL et FORTRAN à une époque où les temps de compilation et d'exécution étaient ridiculement lents. J'ai commencé ma carrière au début des années 90 sur COBOL et le cycle de compilation et de test prenait si longtemps qu'il valait la peine de tester à sec le code avant de passer par le cycle (ou au moins pendant la phase de construction, juste au cas où vous pourriez attraper quelque chose et l'annuler tôt, vous épargnant une heure environ).

À leur tour, nos patrons se moquaient de nos plaintes car il n'y a pas si longtemps, ils devaient transporter une boîte de cartes perforées triées à la main dans la salle des serveurs et la laisser là pendant une journée.

C'était donc bien plus vrai qu'à l'époque.

Et pourtant, très récemment, j'ai vu des blogs réutiliser la visualisation de Steve McConnell de ce problème ( réf , datée de 1996) comme si ce graphique était en fait basé sur des nombres réels. Ce n'est pas le cas. C'est une visualisation, pour expliquer simplement son propos.

Je pense que la prémisse de Morendil, dans l'article cité par le PO, est bonne. La science que nous avons à ce sujet est pauvre et dépassée et pourtant traitée comme un canon. Mais je pense aussi que cela résiste bien et semble vrai parce que nous savons par expérience amère que c'est toujours vrai, au moins jusqu'à un certain point. Et je pense que son phrasé dramatique de «discipline malade» ne lui est d'aucun secours.

Bien que je ne sois au courant d'aucune donnée solide ou autre preuve à l'appui de cette affirmation, au minimum , je pense que c'est du bon sens.

Pensez-y de cette façon. Si vous avez un système complexe avec des sous-systèmes interdépendants (comme le font la plupart des applications non triviales), pensez aux problèmes d'activation qui peuvent être le résultat de modifications apportées à l'un des systèmes. Si les sous - systèmes se sont révélés être correct (via des tests unitaires, etc.) et fixés au début, le nombre de bugs qui seront causés en raison de frapper les modules seuls sont simplement atténué par la fixation précoce.

De plus, si vous corrigez des bogues tôt, la mise en œuvre est encore fraîche dans l'esprit du développeur. Selon la durée d'un projet donné, si vous corrigez des bogues à la fin, le développeur devra passer du temps à comprendre ce qu'il a écrit et (peut-être) comment les sous-systèmes dont dépend leur code dépendent de leur fonctionnement. Temps passé à réapprendre ceci = $.

Je doute qu'il soit possible de trouver une manière scientifiquement rigide de mesurer cela - il y a tout simplement trop d'autres facteurs impliqués, et aucun projet n'est suffisamment comparable pour servir plus que des études de cas. La réflexion logique devrait cependant vous faire avancer. Quelques arguments:

• La quantité totale de code dans un projet a tendance à augmenter vers la fin. Plus vous attendez la correction d'un bogue, plus la base de code que vous devez toucher est grande.
• La qualité du nouveau code ajouté à un projet diminue vers la fin, du moins s'il y a une pression (qui est généralement une donnée): une échéance imminente oblige les gens à jeter par-dessus bord les meilleures pratiques juste pour expédier à temps. Cela signifie que plus vous corrigez un bogue tard, plus vous avez de code à filtrer.
• Même si la duplication de code est généralement désapprouvée, cela se produit tout le temps, et comme il est facile de copier-coller, mais difficile de re-fusionner des sections de code en double, la quantité de code une fois copié augmente généralement au cours de la durée de vie d'un projet. Plus de code copié-collé signifie plus de chances que votre bogue soit dupliqué et doive être trouvé et corrigé plusieurs fois (et par conséquent, plus de chances que certaines de ses occurrences passent inaperçues).
• La correction d'un bogue est une modification d'une base de code; vous espérez améliorer les choses, mais un changement comporte toujours un risque. Un changement qui cause de sérieux problèmes dans un projet avec des mois à parcourir devrait laisser beaucoup de marge pour la gestion des dommages, mais deux jours avant l'expédition, vous avez de sérieux problèmes.
• Plus le bogue lui-même existe, plus il est probable que d'autres parties de l'application commencent à se fier à son mauvais comportement. Ensuite, lorsque vous le corrigez, vous déclenchez soudainement un tas de bogues secondaires dans le code qui ne s'attend pas à ce que votre fonction fournisse réellement les résultats documentés corrects.

Il s'agit d'ingrédients de base acceptés par l'ingénierie des systèmes - et cela s'applique à toute forme de développement technique (que ce soit la construction de ponts, de missiles, de cuirassés ou de logiciels).

Essentiellement, le coût des choses augmente d'environ un ordre de grandeur à mesure que vous progressez dans les étapes de développement.

Quelque chose qui coûte 10 $ à réparer au moment de concevoir l'idée ...

Coûtera environ 100 $ si vous avez besoin de mettre à jour les spécifications ....

Ou coûter environ 1000 $ si quelque chose a été mis en œuvre et vous devez apporter des modifications à ce stade (et mettre à jour les spécifications, obtenir les approbations, etc.), mais il n'a pas subi une sorte de test d'acceptation / de vente officiel

Ou coûter environ 10000 $ si quelque chose a été implémenté et accepté par le client, et vous devez apporter des modifications à ce stade (et mettre à jour les spécifications, obtenir les approbations, et tester à nouveau et réexécuter l'acceptation et la qualification du client, etc.)

Et le coût après déploiement / déploiement / mise en service est encore plus élevé.

Les exemples abondent et il est facile de les comprendre: un système bancaire avec un sérieux changement de périmètre effectué après que 25000 employés l'utilisent coûtera un paquet en temps de recyclage ... avant même d'envisager la portée, le codage, le test, la régression, etc etc etc.

NOTAMMENT, votre kilométrage variera: les coûts et les impacts du changement du site Web de commerce électronique de réchauffement de chaussettes de Fred Nurke sont quelque peu différents des coûts de changement de logiciel sur un ordinateur de contrôle de vol d'avion.

Je n'ai pas accès à des données ou faits concrets, je ne peux donc que vous proposer des observations anecdotiques glanées au cours de mes 20 dernières années en informatique.

Je pense qu'il y a une grande différence entre la façon dont la plupart des développeurs créent des logiciels aujourd'hui par rapport à il y a 20 ans. Avec le mouvement Agile ayant pris tellement d'élan, en particulier au cours des 5 à 6 dernières années, j'ai vu un réel changement d'attitude sur le lieu de travail. À tel point que la qualité de ce que nous faisons semble croître à pas de géant chaque année, et à chaque projet lorsque nous appliquons les leçons que nous avons apprises de projet en projet. Les processus plus légers combinés à l'accent mis sur le développement test-first sont passés de très controversés à banals. À tel point que pour entrer dans de nombreuses entreprises aujourd'hui, si vous n'êtes pas à l'aise avec Agile, vous aurez de la chance s'ils ne vous montrent pas la porte.

Quel impact cela a-t-il donc eu? Tout d'abord, j'ai remarqué que les problèmes sont souvent identifiés bien plus tôt. Il arrive souvent que si le problème ne semble pas trop important, il peut parfois être suspendu indéfiniment. Dans quelques rares cas, j'ai vu des bogues qui étaient considérés comme insignifiants devenir de sérieux problèmes lorsqu'ils sont résolus plus tard, car un problème fondamental devient évident qui n'a pas été pris en compte à l'époque. Parfois, cela peut conduire à un cycle de réparation prolongé, et cela peut être coûteux dans une certaine mesure, mais ce coût est souvent mesuré moins en termes de ressources, et plus souvent en termes d'impact sur la relation entre le client et le développeur. Les clients sont de plus en plus habitués à cette façon de penser agile, qui leur donne des résultats beaucoup plus rapidement qu'auparavant, avec des sprints de développement hautement itératifs et un délai d'exécution rapide entre les demandes et la mise en œuvre, ils attendent donc beaucoup de nous. Et en ce qui concerne les bogues réels, le temps de correction d'un bogue est le plus souvent considérablement réduit du fait de disposer d'une suite solide de tests pour prendre en charge les modifications et de la possibilité de créer de nouveaux tests à partir desquels fournir des informations et des solutions. aux problèmes signalés.

Donc, dans l'ensemble, il semble que l'effort global pour corriger les bogues ait été dans la plupart des cas réduit s'il y a une suite robuste de tests en place, et des procédures pour s'assurer que les tests restent au centre de ce que fait le développeur, mais le coût réel à certains égards, s'est déplacé en partie au moins de la mise en œuvre vers d'autres secteurs de l'entreprise, car à certains égards, l'accent est également passé de l'offre et de la demande pures à la gestion des relations.

Une autre chose qui est devenue évidente, c'est que nos instincts intestinaux d'il y a quelques années, qui suggéraient qu'être Agile réduirait nos cycles de maintenance, ont été prouvés dans une certaine mesure à la fois bien et mal. Juste en ce sens que des tests solides ont facilité le débogage et la correction de notre code dans une large mesure, et de réduire globalement le nombre de bogues publiés dans le code de production, et faux en ce sens que nous travaillons maintenant plus dur pour éviter d'avoir à maintenir le code hérité, en refactorisant constamment le code et en améliorant l'architecture de sorte qu'il devient de plus en plus rare que nous devions développer de nouveaux produits complètement à partir de zéro.

Donc au final, qu'est-ce que cela signifie par rapport à la question du PO? Eh bien, cela signifie que la réponse n'est vraiment pas aussi simple que nous l'aurions cru une fois. Il y a 15 ans, j'aurais probablement répondu à la question par Oui, mais maintenant je pense qu'il est plus réaliste de dire qu'il est vraiment trop difficile de mesurer empiriquement, car la nature de ce que nous faisons pour développer des logiciels a beaucoup changé depuis que nous avons commencé à nous poser la question du PO à l'époque. À certains égards, plus nous faisons progresser nos techniques et nos compétences en tant qu'industrie, plus la question passe d'un oui définitif à un point où je soupçonne que dans un court nombre d'années, nous dirons que cela n'a pas d'importance lorsque nous corrigeons des bogues, parce que nos tests et processus seront tellement plus robustes, que le timing des corrections de bogues sera moins motivé par les efforts pour économiser nos budgets, et plus par les priorités pour satisfaire les besoins de nos clients, et le coût relatif sera devenir pratiquement sans signification contextuellement.

Mais comme je l'ai dit, ce ne sont pas des preuves solides appuyées par des données, juste mes observations des dernières années, et mes tripes me disent qu'il y aura plus de sagesse révolutionnaire à venir qui améliorera la façon dont nous faisons les choses.

Les premiers bogues se propageront à d'autres parties du système, donc lorsque vous corrigez le bogue, vous serez peut-être obligé de réécrire certaines parties du système qui dépendaient du bogue lui-même.

À côté du temps, vous comprendrez comment certaines parties du programme sont construites et vous devrez vous rappeler. C'est une forme de dette technique (si vous précipitez le projet à un stade précoce, vous aurez des problèmes pour le terminer en raison des raccourcis que vous avez pris).

C'est aussi simple que cela et il n'y a rien à prouver.

Je pense que vous essayez de précipiter le projet le plus rapidement possible pour présenter une solution de travail à votre employé. Les bonnes nouvelles sont que vous les aurez très rapidement, les mauvaises nouvelles sont que vous ne les terminerez probablement jamais sans réécriture complète si vous continuez à écrire de la merde aussi vite que possible et prévoyez de tout réparer dans quelques mois. Vous ne pourrez probablement même pas refactoriser cela.

Eh bien, je ne peux probablement pas vous donner la preuve définitive que vous demandez, mais je peux raconter un incident assez récent de mon travail.

Nous avons ajouté une fonctionnalité qui fournissait des capacités de gestion du flux de travail à notre produit. Trucs BDUF typiques, spécifications approuvées et approuvées par le client. Implémenté selon les spécifications. Plaintes du jour 1 sur le déploiement.

Nous n'avions pas fait une véritable revue de la convivialité avec le client, nous avions simplement pris leur parole pour ce qu'ils voulaient. Résultat: des centaines d'heures de retouches - analyse, conception, implémentation et assurance qualité ont dû être refaites. Tout cela parce que la spécification a manqué des cas d'utilisation particuliers. Un bug dans la spécification, si vous voulez.

J'ai vu des choses similaires dans des emplois précédents lorsque quelqu'un dans la chaîne émet des hypothèses différentes de celles de l'utilisateur final. Les bogues de codage simples sont relativement faciles à traiter s'ils sont détectés près du moment où ils se produisent, mais les bogues de conception peuvent tuer des systèmes entiers.

Si vous corrigez le bogue après la publication, vous avez le coût de la recherche et de la correction du bogue - ce qui peut ou non prendre plus de temps / coût pour faire après la publication. Cependant, vous aurez une série de tests d'intégration, de tests de régression, de tests UA, d'activités de publication, etc. qui devront être pris en compte. À moins que le correctif de bogue n'aille avec un certain nombre d'autres correctifs ou une mise à jour de version, vous aurez des dépenses supplémentaires pour les activités de test et de publication qui seraient évitées en incluant le correctif dans la version initiale - car ces coûts seraient partagés sur un certain nombre de correctifs / mises à jour / fonctionnalités.

Tenez également compte du coût que le bogue entraînera lors de son utilisation, s'il n'est que cosmétique, alors cela n'a probablement pas d'importance, mais un bogue de fonction ou de performance pourrait créer un coût avec des activités de support ou une productivité réduite ou des calculs incorrects.

Demandez à Intel combien leur a coûté le Pentium Bug, la fusée Ariane 5 en est un autre bon exemple. Ces bugs ont été corrigés à la fin du projet. J'ai travaillé sur un système où une "tentative" de sortie de logiciel a un budget de 6 chiffres. Dans ces cas extrêmes, il est facile de voir le coût. Dans d'autres cas (la plupart?), Le coût est masqué par le bruit, mais il est toujours là.

Il ne fait aucun doute que les bogues coûtent de l'argent lorsqu'ils existent. Un élément, les rapports de défauts, prend du temps à compiler, à trier et à fermer comme dup, le temps c'est de l'argent - donc un bogue ouvert crée un coût continu. par conséquent, il faut que le report des corrections de bogues coûte plus cher que leur correction plus tôt.

Si un bug s'échappe dans la nature, le coût a un saut pas à pas ...... Est-ce que "La fin du projet" est avant ou après la sortie du logiciel?

J'ai lu une fois un article qui avait deux points intéressants (malheureusement, les références que j'avais avaient disparu depuis longtemps, je vais donc devoir postuler ici). Le premier point qu'ils ont fait valoir est qu'environ 50% de toutes les erreurs ont été introduites dans la spécification des exigences et qu'environ 90% de toutes les erreurs ont été détectées lors des tests UAT ou système.

Le deuxième point qu'ils avaient était que pour chaque phase du modèle en V, le coût avait été multiplié par 10. Que le facteur soit correct ou non, je trouve cela peu pertinent, mais les erreurs les plus coûteuses se produisent lorsque votre conception est basée sur une hypothèse incorrecte. Cela conduit à une énorme quantité de réécriture. Tout le code qui fonctionne à cause de cette hypothèse mais échoue lorsque l'hypothèse correcte est appliquée devra être réécrit.

J'ai rencontré le modèle de domaine entier devant être réécrit en raison d'une hypothèse incorrecte dans les spécifications des exigences. Si un tel bug est détecté tôt, c'est-à-dire lors de l'examen des spécifications des exigences, le coût est très faible. Dans ce cas particulier, il aurait fallu dix lignes de texte. Dans le cas où il est trouvé pendant l'UAT (comme c'était le cas), le coût est substantiel (dans l'exemple donné, le coût du projet a été augmenté de 50%)

Pas de données statistiques, mais une expérience personnelle:

Le code de commande du moteur de fusée sur lequel je travaillais avait une ligne semblable powerCutoff = someCondition && debugOptions.cutoffIsAllowed;. L'option par défaut était aucune coupure autorisée. La version «finale» était censée supprimer toutes les options de débogage, donc la ligne a été modifiée pourpowerCutoff = someCondition; .

Avez-vous attrapé le bogue lors de la révision du code? Nous ne l'avons pas fait. La première fois que la condition de déclenchement s'est produite lors du test, provoquant une coupure inattendue, c'était quelques mois seulement avant le premier vol.

Ce bug aurait coûté moins d'une heure s'il avait été détecté lors de l'examen. Cela aurait pu coûter un jour ou deux s'il avait été intercepté lors de l'intégration, provoquant une seule répétition du test. S'il a été pris lors de la qualification officielle, cela aurait pu coûter une semaine ou deux en provoquant un redémarrage complet de la série de tests avec une nouvelle version.

En l'état, le coût monta en flèche. Nous avons d'abord conçu et exécuté des tests pour déterminer si l'unité de vol pouvait même déclencher la condition. Une fois qu'il a été déterminé qu'il s'agissait d'une possibilité réelle, il y a eu des coûts pour l'ingénierie, la gestion et l'analyse des clients du meilleur correctif, la publication de la nouvelle version, la création et l'exécution d'un nouveau plan de test de régression, les tests du système dans plusieurs unités et simulateurs. Dans l'ensemble, cela a coûté des milliers, voire des dizaines de milliers d'heures de travail. Plus les 15 minutes d'origine pour effectuer le bon changement de code.

Malheureusement, comme beaucoup de choses, cela dépend.

Si un message de dialogue est mal orthographié, il peut être «trivial» à corriger (mise à jour de la chaîne, reconstruction / package, redéploiement). Ou si une mise en page doit être mise à jour, une modification d'un fichier .css peut être suffisante.

Si le bogue est que la sortie d'une méthode critique qui a une spécification de 100+ pages et une preuve est incorrecte, alors l'enquête elle-même peut prendre des heures ou des jours. C'est ce à quoi se réfère l'ancien «axiome» et ce que, entre autres, TDD et agile essaient d'éviter (échouer tôt et clairement, faire des progrès incrémentiels sûrs, yada).

D'après mon expérience récente avec des équipes multi-scrum sur un seul projet, les `` bugs '' sont généralement des problèmes de fusion / intégration qui n'apparaissent qu'à la fin d'une version lorsque les branches de fonctionnalités sont promues stables. Ce sont les pires, car les conflits nécessitent souvent un soutien inter-équipes alors que les équipes sont pressées de terminer leurs propres objectifs, mais je ne sais pas qu'ils sont plus chers que les autres bugs, car ils surviennent lorsqu'ils se produisent: tard dans la la libération, mais le plus tôt possible. C'est ce qui les rend les pires.