L'entropie logicielle expliquée : causes, effets et remèdes

Cet article s'adresse au développeur de logiciels ou au chef de projet qui est curieux de savoir ce qu'est l'entropie logicielle, les effets pratiques sur leur travail et les facteurs sous-jacents contribuant à sa croissance.

L'objectif principal est de créer une prise de conscience de l'entropie logicielle car c'est un facteur dans toutes les formes de développement logiciel. De plus, nous explorons un moyen par lequel l'entropie logicielle peut se voir attribuer une valeur concrète. Ce n'est qu'en quantifiant l'entropie logicielle et en observant sa croissance au fil des versions successives que nous pourrons vraiment comprendre le risque qu'elle représente pour nos objectifs actuels et nos plans futurs.

Qu'est-ce que l'entropie logicielle ?

L' entropie logicielle tire son nom de la principale caractéristique de l'entropie dans le monde réel : c'est une mesure du chaos qui soit reste la même, soit augmente avec le temps . En d'autres termes, il s'agit d'une mesure de l'instabilité inhérente intégrée à un système logiciel par rapport à sa modification.

Malheureusement, on accorde rarement à l'entropie logicielle l'importance qu'elle mérite.

Il n'est pas pris en compte lors du retrait d'une personne d'une équipe de développement, du démarrage prématuré d'un cycle de développement ou de la mise en œuvre de «solutions rapides» - moments où, en fait, il est le plus susceptible de se développer.

Le développement de logiciels est un art et un métier dont les éléments de base sont mal définis. Alors que les constructeurs travaillent avec du ciment et des clous, le développeur de logiciels travaille avec des assertions logiques et un ensemble d'hypothèses. Ceux-ci ne peuvent pas être tenus dans la main et examinés, ni ordonnés au huitième de pouce. Bien que l'observateur occasionnel puisse être tenté de comparer le développement logiciel à la construction, au-delà de quelques similitudes superficielles, il est contre-productif de le faire.

Malgré ces difficultés, nous pouvons néanmoins énoncer les lignes directrices qui nous permettront de comprendre les sources d'entropie logicielle, de mesurer l'étendue du risque qu'elle fait peser sur nos objectifs et (si nécessaire) quelles mesures peuvent être prises pour limiter sa croissance.

La définition proposée de l'entropie logicielle est la suivante :

où I est dérivé du nombre de problèmes inattendus introduits lors de la dernière itération de développement, C est la probabilité perçue que la mise en œuvre des modifications apportées au système entraîne maintenant un nouveau I > 0, et S est la portée de la prochaine itération de développement. En général, les valeurs de E inférieures à 0,1 sont considérées comme bonnes. Un E de 0,5 est considéré comme élevé et les valeurs supérieures à 1,0 sont accablantes.

Le concept d' itération de développement fait partie intégrante de notre compréhension de l'entropie logicielle. Ce sont des cycles d'activité qui conduisent d'un comportement du système à un autre. Les objectifs que nous nous fixons lors de l'itération du logiciel s'appellent sa portée . Dans le développement de logiciels, ces cycles impliquent de modifier ou d'étendre le code sous-jacent du logiciel.

Toutes les modifications apportées au code se produisent dans une itération de développement même si ceux qui les réalisent ne les pensent pas de cette façon. Autrement dit, les petites organisations qui se targuent de construire leurs systèmes à l'aide d'une méthodologie "rapide et sale" - avec peu ou pas de collecte d'exigences ou d'analyses - utilisent toujours des itérations de développement pour atteindre leurs objectifs. Ils ne les planifient tout simplement pas. De même, même si le comportement d'un système modifié s'écarte d'une certaine manière de nos intentions, il a tout de même été réalisé au moyen d'une itération de développement.

En fait, le risque que cela se produise est exactement ce que notre conscience de l'entropie logicielle vise à expliquer et notre désir de la mesurer vise à limiter. En termes pratiques, nous pouvons donc définir l'entropie logicielle comme suit.

Tout système donné a un ensemble fini de problèmes ouverts connus I ₀ . À la fin de la prochaine itération de développement, il y aura un ensemble fini de problèmes connus et ouverts I ₁ . L'entropie inhérente du système spécifie dans quelle mesure notre attente de I ₁ est susceptible de différer de sa valeur réelle et dans quelle mesure la différence est susceptible de croître au cours des itérations suivantes.

Effets de l'entropie logicielle

Notre expérience pratique des effets de l'entropie logicielle dépend de la façon dont nous interagissons avec le système en question.

Les utilisateurs ont une vue statique du logiciel ; ils sont préoccupés par la façon dont il se comporte maintenant et ne se soucient pas des composants internes d'un système. En exécutant une action prédéfinie, les utilisateurs supposent que le logiciel répondra avec un comportement prédéfini correspondant. Cependant, les utilisateurs sont les moins préparés à déduire le niveau d'entropie du logiciel qu'ils utilisent.

L'entropie logicielle est liée à la notion de changement et n'a pas de sens dans un système statique. S'il n'y a aucune intention de modifier le système, nous ne pouvons pas parler de son entropie. De même, un système qui n'existe pas encore (c'est-à-dire que la prochaine itération est en fait la première de son existence) n'a pas d'entropie.

Un logiciel peut être perçu comme « bogué » du point de vue d'un utilisateur, mais si lors des itérations suivantes, les développeurs et gestionnaires de logiciels atteignent leurs objectifs comme prévu, nous devons conclure que l'entropie dans le système est en fait assez faible ! L'expérience des utilisateurs nous dit donc très peu, voire rien, sur l'entropie logicielle :

• Les développeurs de logiciels ont une vision fluide des logiciels. Ils ne s'intéressent au fonctionnement actuel d'un système que dans la mesure où il doit être modifié, et ils s'intéressent aux détails de son fonctionnement pour concevoir une stratégie appropriée.

• Les managers ont peut-être la vision la plus compliquée des logiciels, à la fois statique et fluide. Ils doivent équilibrer les exigences du court terme avec les exigences d'un plan d'affaires qui s'étend plus loin dans l'avenir.

Les personnes dans ces deux rôles ont des attentes. L'entropie logicielle se manifeste chaque fois que ces attentes sont gâchées. Autrement dit, les développeurs et les gestionnaires de logiciels font de leur mieux pour évaluer les risques et les planifier, mais - hors perturbations externes - si leurs attentes sont néanmoins déçues, alors seulement peut-on parler d'entropie logicielle. C'est la main invisible qui interrompt les interactions des composants qui n'étaient pas dans le champ d'application, provoque un plantage inexplicable des serveurs de production et retient un correctif rapide et rentable.

De nombreux systèmes avec des niveaux élevés d'entropie reposent sur des individus spécifiques, en particulier s'il y a des membres juniors de l'équipe de développement. Cette personne possède des connaissances telles que les autres ne peuvent accomplir leurs tâches sans son apport « précieux ». Il ne peut pas être capturé dans les diagrammes UML standard ou les spécifications techniques car il consiste en un amalgame d'exceptions, d'intuitions et de conseils. Cette connaissance ne dépend pas d'un cadre logiquement cohérent et il est donc difficile, voire impossible, de la transférer à quelqu'un d'autre.

Supposons qu'avec beaucoup de détermination et d'efforts, une telle organisation soit capable de se redresser et de stabiliser son service informatique. La situation semble s'être améliorée car, lorsque le développement de logiciels est à l'arrêt, tout progrès, quel qu'il soit, est encourageant. Cependant, en réalité, les attentes satisfaites sont faibles et les réalisations inintéressantes par rapport aux objectifs ambitieux qui étaient à portée de main alors que l'entropie était encore faible.

Lorsque l'entropie logicielle submerge un projet, le projet se fige.

Il ne peut plus y avoir d'itérations de développement. Heureusement, cette situation ne survient pas instantanément. La marche lente mais précipitée vers le bord d'une falaise est quelque chose que tout système subit. Aussi bien organisée et efficace que soit la première version, au fil des itérations de développement successives, son entropie - et donc le risque que les choses tournent mal de manière inattendue - augmentera à moins que des mesures spécifiques ne soient prises pour l'empêcher.

L'entropie logicielle ne peut pas être réduite. Tout comme l'entropie dans le monde réel, elle ne fait que croître ou reste la même. Au début, ses effets sont négligeables. Lorsqu'ils commencent à se manifester, les symptômes sont légers et peuvent être masqués ou ignorés. Mais si une organisation ne tente de lutter contre l'entropie logicielle qu'une fois qu'elle est devenue le risque dominant d'un projet, elle constatera malheureusement que ses efforts sont vains. La connaissance de l'entropie logicielle est donc plus utile lorsque son étendue est faible et les effets indésirables minimes.

Il ne s'ensuit pas que chaque organisation doive consacrer des ressources à limiter la croissance de l'entropie dans ses produits. Une grande partie des logiciels développés aujourd'hui, en particulier les logiciels orientés client, ont une durée de vie prévue relativement courte, peut-être quelques années. Dans ce cas, ses parties prenantes n'ont pas besoin de prendre en compte les effets de l'entropie logicielle, car elle deviendra rarement un obstacle sérieux avant que l'ensemble du système ne soit abandonné. Il existe cependant des raisons moins évidentes de considérer les effets de l'entropie logicielle.

Considérez le logiciel qui gère l'infrastructure de routage d'Internet ou transfère de l'argent d'un compte bancaire à un autre. À tout moment, il existe une ou plusieurs versions de ce logiciel en production, et leurs comportements collectifs peuvent être documentés avec une précision raisonnablement élevée.

La tolérance au risque d'un système est une mesure de la quantité et du type de comportement inattendu que nous pouvons confortablement autoriser d'une itération de développement à la suivante. Pour les types de systèmes que nous venons de mentionner, la tolérance au risque est bien inférieure à celle, par exemple, du logiciel qui achemine les appels téléphoniques. Ce logiciel, à son tour, a une tolérance au risque inférieure à celle du logiciel qui pilote le panier de nombreux sites Web commerciaux.

La tolérance au risque et l'entropie logicielle sont liées en ce sens que l'entropie logicielle doit être minimale pour être certain que nous resterons dans la tolérance au risque d'un système lors de la prochaine itération de développement.

Sources d'entropie logicielle

L'entropie logicielle provient d' un manque de connaissances . Il résulte de la divergence entre nos hypothèses communes et le comportement réel d'un système existant. Ce fait explique pourquoi l'entropie logicielle n'a de sens que dans le cadre de la modification d'un système existant ; c'est la seule fois où notre incompréhension aura un effet pratique. L'entropie logicielle trouve le terrain le plus fertile dans un système dont les détails ne peuvent être compris par une seule personne mais sont plutôt répartis autour d'une équipe de développement. Le temps, lui aussi, est un puissant effaceur de connaissances.

Le code est l'expression d'une série d'assertions logiques. Lorsque le comportement du logiciel (et donc son code) ne correspond pas à la logique qu'il est censé exprimer, on peut parler de son entropie inhérente. Cette situation peut se présenter de trois manières : la logique est bien connue et diverge de son expression, il existe plusieurs compréhensions de la logique que le code est censé exprimer, ou la logique n'est pas bien connue.

• La première situation – la logique est bien connue et s'écarte de son expression actuelle – est la plus facile à aborder mais aussi la moins fréquente. Seuls les très petits systèmes entretenus par peut-être deux participants, un développeur et un responsable du plan d'affaires, entreront dans cette catégorie.

• La deuxième situation — dont la logique n'est pas bien connue — est rare. À toutes fins utiles, l'itération de développement ne peut même pas commencer. Si, à un moment donné, toutes les parties prenantes peuvent être d'accord, elles sont alors susceptibles de faire face à la première situation.

L'esprit humain interprète ses expériences, les filtre et les modifie efficacement pour tenter de les intégrer dans un cadre personnel. En l'absence d'habitudes de développement efficaces, basées sur un libre échange d'idées, le respect mutuel et des attentes claires, il peut y avoir autant d'interprétations du fonctionnement actuel d'un système qu'il y a de membres d'équipe. Les objectifs de l'équipe pour l'itération de développement actuelle peuvent eux-mêmes être contestés.

De nombreux développeurs se protègent de cette situation en renforçant leur propre compréhension unique de ce qui est attendu d'eux et de la manière dont le système « devrait » être organisé. Les gestionnaires et autres parties prenantes, d'autre part, pourraient involontairement chercher à modifier les hypothèses des autres membres de l'équipe dans une tentative malavisée de se faciliter la vie.

Nous sommes maintenant arrivés à la source la plus courante d'entropie logicielle : il existe de multiples interprétations incomplètes de la logique que le système est censé exprimer. Puisqu'il n'y a jamais qu'une seule manifestation de cette logique, la situation est par définition problématique.

D'où vient ce manque de connaissance ? L'incompétence est un moyen. Et comme nous l'avons déjà vu, le manque d'accord sur les objectifs de la prochaine itération de développement en est un autre. Mais il y a d'autres facteurs à considérer. Une organisation peut prétendre employer une méthodologie de développement, mais abandonner au hasard certains ou tous ses aspects sur le terrain. Les développeurs de logiciels sont ensuite chargés de remplir des missions vagues, souvent sujettes à interprétation. Les organisations mettant en œuvre des changements dans leur méthodologie de développement sont particulièrement vulnérables à ce phénomène, bien qu'elles ne soient pas les seules. Les conflits personnels dont la direction n'est pas consciente ou autrement incapable de résoudre peuvent également conduire à une divergence dangereuse entre les attentes et les résultats.

Il existe une deuxième manière, plus importante, de perdre des connaissances techniques sur un produit : le transfert. Capturer des connaissances techniques sur papier est un défi, même pour les rédacteurs les plus compétents. La raison en est que quoi transcrire est tout aussi important que comment . Sans la discipline appropriée, un rédacteur technique peut enregistrer trop d'informations. Alternativement, ils peuvent faire des hypothèses qui les amènent à omettre des points essentiels. Après sa production, la documentation technique doit ensuite être méticuleusement tenue à jour, une proposition difficile pour de nombreuses organisations qui perdent la trace des documents presque aussitôt qu'ils sont rédigés. En raison de ces difficultés, les connaissances techniques sont rarement transférées dans des documents seuls, mais aussi dans des appariements ou d'autres formes d'interaction étroite, d'humain à humain.

L'entropie logicielle fait des pas de géant chaque fois qu'un participant actif quitte une équipe de développement. Ils emportent avec eux un précieux savoir-faire. Répliquer ce savoir-faire est impossible et le rapprocher demande des efforts considérables. Avec suffisamment d'attention et de ressources, cependant, suffisamment de connaissances peuvent être préservées pour que la croissance de l'entropie du système puisse être minimisée.

Il existe d'autres sources d'entropie, mais celles-ci sont relativement mineures. Par exemple, la pourriture logicielle est le processus par lequel un système est affecté de manière inattendue par des modifications de son environnement. Nous pouvons penser aux logiciels tiers sur lesquels il repose (comme les bibliothèques), mais il existe d'autres causes plus insidieuses de pourriture logicielle, résultant généralement de modifications des hypothèses sur lesquelles le système était basé. Par exemple, si un système a été conçu avec certaines hypothèses sur la disponibilité de la mémoire, il peut commencer à mal fonctionner à des moments inattendus si la mémoire dont il dispose est réduite.

Comment calculer l'entropie : attribuer des valeurs à C, S et I

I est le nombre de problèmes de comportement non résolus dans un système logiciel, y compris l'absence de fonctionnalités promises. Il s'agit d'une quantité connue qui est souvent suivie dans un système comme JIRA. La valeur de I en découle directement. I est le nombre d'"unités de travail" qui ont été abandonnées ou laissées incomplètes lors de la dernière itération de développement en plus du nombre d'unités de travail résultant de problèmes de comportement nouvellement introduits et inattendus. Étant donné que I est compté comme un nombre d'unités de travail, nous pouvons le relier à la valeur de S, qui est la portée de la prochaine itération de développement dans les mêmes unités de travail. Ce qui constitue exactement une « unité de travail » dépend de la méthodologie de développement.

C est la probabilité perçue que, lorsque les unités de travail dans la portée ont été mises en œuvre, le nombre de problèmes ouverts réels I1 dans la prochaine itération sera supérieur à son estimation maintenant. Cette valeur vit dans le domaine 0 <= C <= 1.

On pourrait soutenir que la probabilité C est précisément ce que l'entropie logicielle prétend mesurer. Cependant, il existe des différences fondamentales entre cette valeur et notre mesure de l'entropie logicielle. La probabilité perçue que quelque chose se passe mal est exactement celle-ci : ce n'est pas une valeur réelle. Cependant, il est utile dans la mesure où les sentiments des personnes qui participent à un projet sont une source précieuse d'informations sur sa stabilité.

La portée S tient compte de l'ampleur des modifications proposées et doit être exprimée dans les mêmes unités que I. Une valeur plus élevée de S diminue l'entropie car nous augmentons la portée des modifications proposées. Bien que cela puisse sembler contre-intuitif, nous devons garder à l'esprit que l'entropie est une mesure de la façon dont le développement du système peut ne pas répondre à nos attentes. Il ne suffit pas de dire que l'entropie est une mesure de la probabilité d'introduire des problèmes. Nous essayons naturellement d'anticiper les risques et d'en tenir compte dans notre planification (et donc dans notre estimation de I1, qui peut très bien dépasser ₀ ). De toute évidence, plus nous sommes sûrs d'entreprendre une grande portée de changement, moins on peut dire qu'il y a d'entropie dans le système, à moins que ceux qui planifient les changements et/ou les mettent en œuvre soient incompétents. Cette possibilité, cependant, se reflète probablement dans la valeur actuelle de I .

Notez que nous n'avons pas besoin d'essayer de spécifier l'ampleur de la différence entre la valeur réelle de I ₁ et sa valeur attendue. Si nous supposons que nos plans sont corrects lorsque nous les élaborons, il n'est pas non plus raisonnable de supposer que nous pouvons prédire dans quelle mesure le résultat ne répondra pas à nos attentes ; nous ne pouvons spécifier qu'une chance perçue C qu'il ne le sera pas. Cependant, le degré auquel la valeur réelle I ₁ diffère de sa valeur attendue est une entrée importante dans le calcul de l'entropie dans l'itération suivante sous la forme de la valeur dérivée I .

Théoriquement, il est possible que I ait une valeur négative. En pratique, cependant, cette situation ne se produira jamais; nous ne résolvons généralement pas les problèmes accidentellement. Les valeurs négatives pour I ne sont pas un signe réconfortant. Ils impliquent que les moyens par lesquels l'entropie est calculée sont défectueux. La croissance de l'entropie logicielle peut, bien sûr, être réduite en prenant des mesures spécifiques, comme décrit ci-dessous. Cependant, dans de tels cas, je ne devrais pas supposer des valeurs négatives, car nous intégrons toujours nos attentes dans nos conceptions.

C est une valeur subjective. Il existe dans l'esprit des participants à une itération de développement et peut être déduit en les interrogeant et en faisant la moyenne des résultats. La question doit être posée de manière positive. Par exemple : "Sur une échelle de 0 à 10 avec 10 le plus probable, comment estimeriez-vous les chances de l'équipe d'atteindre tous ses objectifs cette itération de développement ?"

Notez que la question est posée sur les objectifs de l'équipe dans son ensemble, pas un sous-ensemble. Une réponse de 10 indiquerait une valeur de 0 pour C, tandis qu'une réponse de 7 indiquerait une valeur de 0,3. Dans les grandes équipes, chaque réponse peut être pondérée en fonction de facteurs pertinents, tels que la durée d'implication d'un individu dans le projet et le temps qu'il y consacre réellement. Toutefois, la compétence ne devrait pas être un facteur dans la pondération des réponses. D'ici peu, même un membre junior de l'équipe aura une idée de son efficacité à atteindre ses objectifs. Les équipes suffisamment grandes peuvent souhaiter écarter les valeurs les plus élevées et les plus basses signalées avant de faire la moyenne du reste.

Demander aux professionnels quelle est la probabilité d'échec de leur équipe est une proposition sensible et provocatrice. Cependant, c'est exactement la question que toute organisation souhaitant quantifier l'entropie doit se poser. Pour garantir des réponses honnêtes, les participants doivent donner leur estimation de C de manière anonyme et sans crainte de répercussions, même s'ils signalent une valeur extrêmement élevée.

S doit se voir attribuer une valeur dans les mêmes «unités de travail» que I et dépend donc fortement de la méthodologie de développement. Pour les équipes qui utilisent des aspects d'une méthodologie Agile, les histoires semblent l'« unité de travail » la plus évidente pour S et I . Dans ce cas, l'étendue d'une itération de développement s'étend sur chaque version régulièrement planifiée en production, qu'elle soit mineure ou majeure. I devrait être quantifié comme la somme du nombre d'histoires qui n'ont pas été terminées avec succès au cours de chaque sprint menant à la publication et le nombre d'histoires générées pour être incluses dans les futurs sprints à la suite de problèmes inattendus se manifestant après la publication.

Notez que nous ne considérons pas les correctifs ou autres mises en production non planifiées comme définissant l'étendue d'une itération de développement, et nous ne devons pas non plus soustraire les histoires associées de I .

La difficulté avec cette approche est qu'une période de découverte et d'analyse doit se produire avant que les bogues puissent ensuite être décomposés en histoires. La vraie valeur de I ne peut donc être définie qu'après un certain délai. De plus, l'interrogation de C se produit naturellement au début de chaque sprint. Les résultats obtenus doivent donc à nouveau être moyennés sur l'ensemble de la version. Malgré ces difficultés, toute équipe employant des aspects d'une méthodologie Agile est susceptible de trouver que les histoires sont l'unité la plus précise pour quantifier S (et donc I ).

Il existe d'autres méthodologies de développement en usage aujourd'hui. Quelle que soit la méthodologie employée, les principes de mesure de l'entropie logicielle restent les mêmes : l'entropie logicielle doit être mesurée entre les mises en production, S et I doivent être mesurés dans les mêmes "unités de travail", et les estimations de C doivent être obtenues auprès des participants directs à la production. manière non menaçante et de préférence anonyme.

Réduire la croissance de E

Une fois que la connaissance d'un système est perdue, elle ne peut jamais être récupérée. Pour cette raison, l'entropie logicielle ne peut pas être réduite. Tout ce que nous pouvons espérer, c'est freiner sa croissance.

La croissance de l'entropie peut être limitée en adoptant des mesures appropriées lors du développement du logiciel. L'aspect programmation en binôme du développement Agile est particulièrement utile à cet égard. Parce que plus d'un développeur est impliqué au moment où le code est écrit, la connaissance des détails essentiels est distribuée et les effets du départ des membres de l'équipe sont atténués.

Une autre pratique utile est la production d'une documentation bien structurée et facilement utilisable, en particulier au sein des organisations utilisant une méthodologie en cascade. Cette documentation doit s'appuyer sur des principes stricts et bien définis compris de tous. Les organisations qui s'appuient sur la documentation comme principal moyen de communication et de sauvegarde des connaissances techniques sont bien adaptées à cette approche. Ce n'est que lorsqu'il n'y a pas de directives ou de formation sur la façon d'écrire et de consommer des documents écrits en interne - comme c'est souvent le cas dans les jeunes organisations utilisant des méthodologies RAD ou Agile - que leur valeur devient suspecte.

Il existe deux manières de réduire la croissance de l'entropie dans un système : exécuter des modifications destinées à réduire I ou exécuter des modifications destinées à réduire C.

La première consiste à refactoriser. Les actions destinées à réduire I ont tendance à être de nature technique et sont probablement déjà familières au lecteur. Une itération de développement doit avoir lieu. La partie de cette itération qui vise à réduire la croissance de l'entropie n'apportera aucun avantage commercial tangible alors qu'elle consommera du temps et des ressources. Ce fait fait souvent de la réduction de la croissance de l'entropie une vente difficile au sein de toute organisation.

Réduire la valeur de C est une stratégie plus puissante car l'effet est à plus long terme. De plus, C agit comme un contrôle important sur la croissance du rapport de I à S. Les actions visant à réduire C ont tendance à être axées sur le comportement et la pensée humains. Bien que ces actions ne nécessitent pas d'itération de développement en soi, elles ralentiront les itérations suivantes à mesure que les participants acceptent et s'adaptent aux nouvelles procédures. L'acte apparemment simple de se mettre d'accord sur les améliorations à apporter est un chemin semé d'embûches, car les objectifs disparates des participants et des parties prenantes du projet apparaissent soudainement.

Emballer

L'entropie logicielle est le risque que la modification d'un logiciel existant entraîne des problèmes inattendus, des objectifs non atteints, ou les deux.

Bien que négligeable lors de la création du logiciel, l'entropie du logiciel augmente à chaque itération de développement. Si elle est autorisée à continuer sans contrôle, l'entropie logicielle finira par arrêter le développement.

Cependant, tous les projets ne doivent pas tenir compte des effets de l'entropie logicielle. De nombreux systèmes seront retirés de la production avant que l'entropie n'exerce des effets notables et délétères. Pour ceux dont la durée de vie est suffisamment longue pour que l'entropie pose un risque crédible, en faire prendre conscience et mesurer son étendue, bien qu'encore faible, fournit un moyen de s'assurer que le développement n'est pas interrompu prématurément.

Une fois qu'un système a été complètement submergé par les effets de l'entropie logicielle, plus aucun changement ne peut être apporté et le développement est pratiquement terminé.