Spiegazione dell'entropia del software: cause, effetti e rimedi

Questo articolo è rivolto allo sviluppatore di software o al project manager che è curioso di sapere cos'è l'entropia del software, gli effetti pratici sul proprio lavoro e i fattori sottostanti che contribuiscono alla sua crescita.

L'obiettivo principale è creare una consapevolezza dell'entropia del software perché è un fattore in tutte le forme di sviluppo del software. Inoltre, esploriamo un mezzo attraverso il quale all'entropia del software può essere assegnato un valore concreto. Solo quantificando l'entropia del software e osservando la sua crescita nelle versioni successive possiamo veramente comprendere il rischio che rappresenta per i nostri obiettivi attuali e piani futuri.

Che cos'è l'entropia del software?

L' entropia del software prende il nome dalla caratteristica principale dell'entropia nel mondo reale: è una misura del caos che rimane la stessa o aumenta nel tempo . Detto in altro modo, è una misura dell'instabilità intrinseca incorporata in un sistema software rispetto alla sua alterazione.

Sfortunatamente, all'entropia del software raramente viene attribuita l'importanza che merita.

Non viene presa in considerazione quando si estrae qualcuno da un team di sviluppo, si avvia prematuramente un ciclo di sviluppo o si implementano "soluzioni rapide", momenti in cui, in effetti, è più probabile che cresca.

Lo sviluppo del software è un'arte e un mestiere i cui elementi fondamentali sono mal definiti. Mentre i costruttori lavorano con cemento e chiodi, lo sviluppatore di software lavora con asserzioni logiche e una serie di ipotesi. Questi non possono essere tenuti in mano ed esaminati, né possono essere ordinati per l'ottavo di pollice. Sebbene l'osservatore casuale possa essere tentato di confrontare lo sviluppo del software con la costruzione, al di là di alcune somiglianze superficiali è controproducente farlo.

Nonostante queste difficoltà, possiamo comunque definire le linee guida che ci consentiranno di comprendere le fonti dell'entropia del software, misurare l'entità del rischio che rappresenta per i nostri obiettivi e (se necessario) quali misure possono essere adottate per limitarne la crescita.

La definizione proposta di entropia software è la seguente:

dove I è derivato dal numero di problemi imprevisti introdotti durante l'ultima iterazione di sviluppo, C è la probabilità percepita che l'implementazione di modifiche al sistema si traduca ora in un nuovo I > 0 e S è l'ambito della successiva iterazione di sviluppo. In generale, i valori di E inferiori a 0,1 sono considerati buoni. Un E di 0,5 è considerato alto e i valori superiori a 1,0 sono schiaccianti.

Il concetto di un'iterazione di sviluppo è parte integrante della nostra comprensione dell'entropia del software. Questi sono cicli di attività che portano da un comportamento del sistema a un altro. Gli obiettivi che ci siamo prefissati durante l'iterazione del software sono chiamati ambito . Nello sviluppo del software, tali cicli implicano la modifica o l'espansione del codice sottostante del software.

Tutte le modifiche al codice si verificano in un'iterazione di sviluppo anche se chi le esegue non le pensa in quel modo. Cioè, le organizzazioni più piccole che sono orgogliose di costruire i propri sistemi utilizzando una metodologia "rapida e sporca", con poca o nessuna raccolta di requisiti o analisi, utilizzano ancora iterazioni di sviluppo per raggiungere i propri obiettivi. Semplicemente non li pianificano. Allo stesso modo, anche se il comportamento di un sistema modificato diverge in qualche modo dalle nostre intenzioni, è stato comunque ottenuto mediante un'iterazione di sviluppo.

In effetti, il rischio che ciò accada è esattamente ciò che la nostra consapevolezza dell'entropia del software intende spiegare e il nostro desiderio di misurarla intende limitarla. In termini pratici, quindi, possiamo definire l'entropia del software come segue.

Ogni dato sistema ha un insieme finito di problemi noti e aperti I ₀ . Alla fine della prossima iterazione di sviluppo, ci sarà un insieme finito di problemi noti e aperti I ₁ . L'entropia intrinseca del sistema specifica quanto è probabile che la nostra aspettativa di I ₁ differisca dal suo valore effettivo e quanto è probabile che la differenza cresca nelle iterazioni successive.

Effetti dell'entropia del software

La nostra esperienza pratica degli effetti dell'entropia del software dipende da come interagiamo con il sistema in questione.

Gli utenti hanno una vista statica del software; si preoccupano di come si comporta ora e non si preoccupano degli interni di un sistema. Eseguendo un'azione predefinita, gli utenti presumono che il software risponderà con un comportamento predefinito corrispondente. Tuttavia, gli utenti sono i meno preparati a dedurre il livello di entropia nel software che stanno utilizzando.

L'entropia del software è legata alla nozione di cambiamento e non ha significato in un sistema statico. Se non c'è intenzione di alterare il sistema, non possiamo parlare della sua entropia. Allo stesso modo, un sistema che non esiste ancora (cioè, l'iterazione successiva è in realtà la prima della sua esistenza) non ha entropia.

Il software può essere percepito come "buggy" dal punto di vista di un utente, ma se durante le successive iterazioni sviluppatori e manager di software stanno raggiungendo i loro obiettivi come pianificato, dobbiamo concludere che l'entropia nel sistema è in realtà piuttosto bassa! L'esperienza degli utenti, quindi, ci dice molto poco, se non nulla, sull'entropia del software:

• Gli sviluppatori di software hanno una visione fluida del software. Si preoccupano di come funziona attualmente un sistema solo nella misura in cui deve essere cambiato, e si occupano dei dettagli di come funziona per escogitare una strategia appropriata.

• I gestori hanno forse la visione più complicata del software, sia statico che fluido. Devono bilanciare le esigenze del breve termine con le esigenze di un business plan che si estende ulteriormente nel futuro.

Le persone in entrambi questi ruoli hanno aspettative. L'entropia del software si manifesta ogni volta che queste aspettative vengono deluse. Cioè, sviluppatori e manager di software fanno del loro meglio per valutare i rischi e pianificarli, ma, escludendo le interruzioni esterne, se le loro aspettative vengono comunque deluse, solo allora possiamo parlare di entropia del software. È la mano invisibile che interrompe le interazioni dei componenti che non erano nell'ambito, causa l'arresto anomalo inspiegabile dei server di produzione e trattiene un hotfix tempestivo e conveniente.

Molti sistemi con alti livelli di entropia si basano su individui specifici, in particolare se ci sono membri junior del team di sviluppo. Questa persona possiede una conoscenza tale che gli altri non possono svolgere i loro compiti senza il suo "prezioso" input. Non può essere catturato nei diagrammi UML standard o nelle specifiche tecniche perché consiste in un amalgama di eccezioni, intuizioni e suggerimenti. Questa conoscenza non dipende da un quadro logicamente coerente ed è quindi difficile, se non impossibile, trasferirla a qualcun altro.

Supponiamo che, con grande determinazione e impegno, un'organizzazione del genere sia in grado di dare una svolta e stabilizzare il proprio reparto IT. La situazione sembra essere migliorata perché, quando lo sviluppo del software si è fermato, qualsiasi progresso è incoraggiante. Tuttavia, in realtà, le aspettative soddisfatte sono basse ei risultati poco interessanti rispetto agli alti obiettivi che erano a portata di mano mentre l'entropia era ancora bassa.

Quando l'entropia del software travolge un progetto, il progetto si blocca.

Non possono esserci più iterazioni di sviluppo. Fortunatamente, questa situazione non si presenta istantaneamente. La marcia lenta ma precipitosa verso il bordo di una scogliera è qualcosa a cui ogni sistema è sottoposto. Non importa quanto ben organizzata ed efficiente possa essere la prima versione, nel corso delle successive iterazioni di sviluppo la sua entropia - e quindi il rischio che le cose vadano storte inaspettatamente - aumenterà a meno che non vengano presi provvedimenti specifici per prevenirlo.

L'entropia del software non può essere ridotta. Proprio come l'entropia nel mondo reale, cresce o rimane la stessa. All'inizio i suoi effetti sono trascurabili. Quando iniziano a manifestarsi, i sintomi sono lievi e possono essere mascherati o ignorati. Ma se un'organizzazione tenta di combattere l'entropia del software solo una volta che è diventato il rischio dominante in un progetto, scoprirà purtroppo che i suoi sforzi sono vani. La consapevolezza dell'entropia del software è quindi più utile quando la sua estensione è bassa e gli effetti negativi minimi.

Non ne consegue che ogni organizzazione debba dedicare risorse a limitare la crescita dell'entropia nei suoi prodotti. Gran parte del software in fase di sviluppo oggi, in particolare il software orientato al consumatore, ha una durata prevista relativamente breve, forse alcuni anni. In questo caso, le parti interessate non devono considerare gli effetti dell'entropia del software, poiché raramente diventerà un serio ostacolo prima che l'intero sistema venga scartato. Ci sono, tuttavia, ragioni meno ovvie per considerare gli effetti dell'entropia del software.

Si consideri il software che esegue l'infrastruttura di routing di Internet o trasferisce denaro da un conto bancario all'altro. In qualsiasi momento, ci sono una o più versioni di questo software in produzione e i loro comportamenti collettivi possono essere documentati con una precisione ragionevolmente elevata.

La tolleranza al rischio di un sistema è una misura di quanto e quale tipo di comportamento imprevisto possiamo consentire comodamente da un'iterazione di sviluppo all'altra. Per i tipi di sistemi appena menzionati, la tolleranza al rischio è di gran lunga inferiore rispetto, ad esempio, al software che instrada le telefonate. Questo software, a sua volta, ha una tolleranza al rischio inferiore rispetto al software che guida il carrello degli acquisti di molti siti Web commerciali.

La tolleranza al rischio e l'entropia del software sono correlate in quanto l'entropia del software deve essere minima per essere certi di rimanere all'interno della tolleranza al rischio di un sistema durante la successiva iterazione di sviluppo.

Fonti dell'entropia del software

L'entropia del software nasce da una mancanza di conoscenza . Risulta dalla divergenza tra i nostri presupposti comuni e il comportamento effettivo di un sistema esistente. Questo fatto spiega perché l'entropia del software ha significato solo nel contesto della modifica di un sistema esistente; è l'unico momento in cui la nostra mancanza di comprensione avrà un effetto pratico. L'entropia del software trova il terreno più fertile in un sistema i cui dettagli non possono essere compresi da una sola persona ma sono invece diffusi attorno a un team di sviluppo. Anche il tempo è un potente cancellatore di conoscenza.

Il codice è l'espressione di una serie di asserzioni logiche. Quando il comportamento del software (e quindi il suo codice) non corrisponde alla logica che intende esprimere, si può parlare della sua intrinseca entropia. Questa situazione può presentarsi in tre modi: la logica è ben nota e diverge dalla sua espressione, ci sono molteplici comprensioni della logica che il codice intende esprimere o la logica non è ben nota.

• La prima situazione - la logica è ben nota e diverge dalla sua espressione attuale - è la più facile da affrontare ma anche la meno comune. Solo i sistemi molto piccoli gestiti da forse due partecipanti, uno sviluppatore e qualcuno responsabile del business plan, rientreranno in questa categoria.

• La seconda situazione - la logica non è ben nota - è rara. A tutti gli effetti, l'iterazione di sviluppo non può nemmeno iniziare. Se a un certo punto tutte le parti interessate possono essere d'accordo, è probabile che si trovino ad affrontare la prima situazione.

La mente umana interpreta le sue esperienze, filtrandole e modificandole efficacemente nel tentativo di inserirle in una cornice personale. In assenza di abitudini di sviluppo efficaci, basate su un libero scambio di idee, sul rispetto reciproco e su aspettative chiare, possono esserci tante interpretazioni del funzionamento di un sistema attuale quanti sono i membri del team. Gli obiettivi del team per l'attuale iterazione di sviluppo potrebbero essere in discussione.

Molti sviluppatori si proteggono da questa situazione rafforzando la propria comprensione unica di ciò che è loro richiesto e di come "dovrebbe" essere organizzato il sistema. I manager e le altre parti interessate, d'altra parte, potrebbero inconsapevolmente cercare di cambiare i presupposti degli altri membri del team nel tentativo fuorviante di semplificarsi la vita.

Siamo ora arrivati ​​alla fonte più comune di entropia del software: ci sono interpretazioni multiple e incomplete della logica che il sistema intende esprimere. Poiché c'è sempre una sola manifestazione di questa logica, la situazione è per definizione problematica.

Come nasce questa mancanza di conoscenza? L'incompetenza è un modo. E come abbiamo già visto, un'altra è la mancanza di accordo sugli obiettivi della prossima iterazione di sviluppo. Ma ci sono altri fattori da considerare. Un'organizzazione può pretendere di impiegare una metodologia di sviluppo ma poi abbandonare a casaccio alcuni o tutti i suoi aspetti sul pavimento. Gli sviluppatori di software hanno quindi il compito di completare incarichi vaghi, spesso aperti all'interpretazione. Le organizzazioni che implementano modifiche alla loro metodologia di sviluppo sono particolarmente vulnerabili a questo fenomeno, sebbene non siano affatto le uniche. Conflitti personali di cui il management non è a conoscenza o comunque non è in grado di risolvere possono portare anche a pericolose divergenze tra aspettative e risultati.

C'è un secondo, più importante modo in cui perdiamo le conoscenze tecniche su un prodotto: nel trasferimento. Acquisire conoscenze tecniche su carta è una sfida anche per gli scrittori più esperti. Il motivo è che cosa trascrivere è importante quanto come . Senza la disciplina adeguata, uno scrittore tecnico può registrare troppe informazioni. In alternativa, possono fare ipotesi che li inducano a omettere punti essenziali. Dopo che è stata prodotta, la documentazione tecnica deve essere meticolosamente aggiornata, una proposta difficile per molte organizzazioni che perdono le tracce dei documenti non appena vengono scritti. A causa di queste difficoltà, le conoscenze tecniche vengono raramente trasferite in documenti da soli, ma anche in abbinamento o altre forme di stretta interazione uomo-uomo.

L'entropia del software fa passi da gigante ogni volta che un partecipante attivo lascia un team di sviluppo. Stanno portando con sé un prezioso pezzo di know-how. Replicare quel know-how è impossibile e approssimarlo richiede uno sforzo considerevole. Con sufficiente attenzione e risorse, tuttavia, è possibile preservare una conoscenza sufficiente per ridurre al minimo la crescita dell'entropia del sistema.

Ci sono altre fonti di entropia, ma queste sono relativamente minori. Ad esempio, il software rot è il processo mediante il quale un sistema è inaspettatamente influenzato da modifiche al suo ambiente. Possiamo pensare a software di terze parti su cui si basa (come le librerie), ma ci sono altre cause più insidiose della putrefazione del software, di solito derivanti da modifiche ai presupposti su cui si basava il sistema. Ad esempio, se un sistema è stato progettato con determinati presupposti sulla disponibilità della memoria, potrebbe iniziare a non funzionare correttamente in momenti imprevisti se la memoria a sua disposizione è ridotta.

Come calcolare l'entropia: assegnare valori a C, S e I

I è il numero di problemi comportamentali irrisolti in un sistema software, inclusa l'assenza delle funzionalità promesse. Questa è una quantità nota che viene spesso monitorata in un sistema come JIRA. Il valore di I è derivato direttamente da esso. I è il numero di "unità di lavoro" che sono state abbandonate o lasciate incomplete durante l'ultima iterazione di sviluppo oltre al numero di unità di lavoro risultanti da problemi comportamentali di nuova introduzione e imprevisti. Poiché I viene contato come un numero di unità di lavoro, possiamo metterlo in relazione con il valore di S, che è l'ambito dell'iterazione di sviluppo successiva nelle stesse unità di lavoro. Ciò che comprende esattamente una "unità di lavoro" dipende dalla metodologia di sviluppo.

C è la probabilità percepita che, quando le unità di lavoro nell'ambito di applicazione sono state implementate, il numero di problemi aperti effettivi I1 nella prossima iterazione sarà maggiore della sua stima attuale. Questo valore risiede nel dominio 0 <= C <= 1.

Si potrebbe obiettare che la probabilità C è esattamente ciò che l'entropia del software pretende di misurare. Tuttavia, ci sono differenze fondamentali tra questo valore e la nostra misura dell'entropia del software. La probabilità percepita che qualcosa vada storto è esattamente questa: non è un valore reale. Tuttavia, è utile in quanto i sentimenti delle persone che partecipano a un progetto sono una preziosa fonte di informazioni su quanto sia stabile.

L'ambito S tiene conto dell'entità delle modifiche proposte e deve essere espresso nelle stesse unità di I. Un valore maggiore di S diminuisce l'entropia perché stiamo aumentando l'ambito delle modifiche proposte. Anche se questo può sembrare controintuitivo, dobbiamo tenere a mente che l'entropia è una misura di come lo sviluppo del sistema potrebbe non soddisfare le nostre aspettative. Non basta dire che l'entropia è una misura della possibilità di introdurre problemi. Naturalmente cerchiamo di anticipare i rischi e di tenerne conto nella nostra pianificazione (e quindi nella nostra stima di I1, che potrebbe aumentare oltre lo ₀ ). Chiaramente, più siamo fiduciosi nell'assumere un ampio raggio di cambiamento, meno entropia si può dire che ci sia nel sistema, a meno che coloro che pianificano i cambiamenti e/o li eseguono non siano incompetenti. Questa possibilità, tuttavia, si riflette probabilmente nel valore attuale di I .

Si noti che non è necessario tentare di specificare l'entità della differenza tra il valore effettivo di I ₁ e il suo valore atteso. Se assumiamo che i nostri piani siano corretti quando li realizziamo, non è nemmeno ragionevole presumere di poter prevedere fino a che punto il risultato non soddisferà le nostre aspettative; possiamo solo specificare una possibilità percepita C che non lo farà. Tuttavia, il grado in cui il valore effettivo I ₁ differisce dal suo valore atteso è un input importante nel calcolo dell'entropia nell'iterazione successiva nella forma del valore derivato I .

In teoria, è possibile che io abbia un valore negativo. In pratica, però, questa situazione non si verificherà mai; di solito non risolviamo i problemi accidentalmente. I valori negativi per I non sono un segno confortante. Implicano che il mezzo con cui viene calcolata l'entropia è difettoso. La crescita dell'entropia del software può, ovviamente, essere ridotta adottando misure specifiche, come descritto di seguito. Tuttavia, in questi casi, non dovrei assumere valori negativi, poiché incorporiamo sempre le nostre aspettative nei nostri progetti.

C è un valore soggettivo. Esiste nella mente dei partecipanti a un'iterazione di sviluppo e può essere dedotto facendo un sondaggio e calcolando la media dei risultati. La domanda va posta in modo positivo. Ad esempio: "Su una scala da 0 a 10 con 10 molto probabile, come valuteresti le possibilità del team di raggiungere tutti i suoi obiettivi in ​​questa iterazione di sviluppo?"

Nota che la domanda viene posta sugli obiettivi del team nel loro insieme, non su un sottoinsieme. Una risposta di 10 indicherebbe un valore di 0 per C, mentre una risposta di 7 indicherebbe un valore di .3. Nei team più grandi, ogni risposta potrebbe essere ponderata in base a fattori rilevanti, come per quanto tempo un individuo è stato coinvolto nel progetto e quanto tempo è stato effettivamente impiegato su di esso. La competenza, tuttavia, non dovrebbe essere un fattore di ponderazione delle risposte. In poco tempo, anche un membro più giovane della squadra avrà un'idea di quanto sia efficace nel raggiungere i suoi obiettivi. Squadre sufficientemente grandi potrebbero voler scartare i valori più alti e più bassi riportati prima di calcolare la media del resto.

Chiedere ai professionisti quanto è probabile che il loro team fallisca è una proposta delicata e provocatoria. Tuttavia, questa è esattamente la domanda che qualsiasi organizzazione che desideri quantificare l'entropia deve porsi. Per garantire risposte oneste, i partecipanti dovrebbero fornire la loro stima di C in modo anonimo e senza timore di ripercussioni, anche se segnalano un valore incredibilmente alto.

A S deve essere assegnato un valore nelle stesse “unità di lavoro” di I ed è quindi fortemente dipendente dalla metodologia di sviluppo. Per i team che utilizzano aspetti di una metodologia Agile, le storie sembrano l'"unità di lavoro" più ovvia sia per S che per I. In questo caso, l'estensione di un'iterazione di sviluppo copre ogni versione regolarmente programmata in produzione, minore o maggiore. Dovrei essere quantificato come la somma del numero di storie che non sono state completate con successo durante ogni sprint che ha portato al rilascio e il numero di storie generate per essere incluse negli sprint futuri come risultato di problemi imprevisti che si sono manifestati dopo il rilascio.

Si noti che non consideriamo gli aggiornamenti rapidi o altri rilasci non pianificati per la produzione come definizioni dell'estensione di un'iterazione di sviluppo, né dovremmo sottrarre storie associate da I .

La difficoltà di questo approccio è che deve verificarsi un periodo di scoperta e analisi prima che i bug possano essere successivamente suddivisi in storie. Il vero valore di I può quindi essere definito solo dopo un ritardo. Inoltre, il polling per C avviene naturalmente all'inizio di ogni sprint. I risultati ottenuti devono quindi essere ancora una volta mediati nell'arco dell'intero rilascio. Nonostante queste difficoltà, è probabile che qualsiasi team che utilizzi aspetti di una metodologia Agile scopra che le storie sono l'unità più accurata per quantificare S (e quindi I ).

Ci sono altre metodologie di sviluppo in uso oggi. Qualunque sia la metodologia utilizzata, i principi per misurare l'entropia del software rimangono gli stessi: l'entropia del software dovrebbe essere misurata tra i rilasci alla produzione, S e I dovrebbero essere misurati nelle stesse "unità di lavoro" e le stime di C dovrebbero essere prese dai partecipanti diretti in in modo non minaccioso e preferibilmente anonimo.

Ridurre la crescita di E

Una volta che la conoscenza di un sistema è persa, non può più essere riguadagnata. Per questo motivo, l'entropia del software non può essere ridotta. Tutto ciò che possiamo sperare di fare è frenarne la crescita.

La crescita dell'entropia può essere limitata adottando misure appropriate durante lo sviluppo del software. L'aspetto della programmazione di coppia dello sviluppo Agile è particolarmente utile a questo proposito. Poiché nel momento in cui viene scritto il codice è coinvolto più di uno sviluppatore, la conoscenza dei dettagli essenziali viene distribuita e gli effetti dell'abbandono dei membri del team vengono mitigati.

Un'altra pratica utile è la produzione di documentazione ben strutturata e facilmente fruibile, soprattutto all'interno di organizzazioni che utilizzano una metodologia a cascata. Tale documentazione deve essere supportata da principi rigorosi e ben definiti, compresi da tutti. Le organizzazioni che fanno affidamento sulla documentazione come mezzo principale di comunicazione e salvaguardando le conoscenze tecniche sono adatte a questo approccio. È solo quando non ci sono linee guida o formazione su come scrivere e consumare documenti scritti internamente, come spesso accade nelle organizzazioni più giovani che utilizzano metodologie RAD o Agile, che il loro valore diventa sospetto.

Esistono due modi per ridurre la crescita dell'entropia in un sistema: eseguire modifiche intese a ridurre I o eseguire modifiche intese a ridurre C.

Il primo riguarda il refactoring. Le azioni intese a ridurre tendo ad essere di natura tecnica e probabilmente sono già familiari al lettore. Deve verificarsi un'iterazione di sviluppo. La parte di questa iterazione che ha lo scopo di ridurre la crescita dell'entropia non porterà alcun beneficio commerciale tangibile mentre consumerà tempo e risorse. Questo fatto spesso rende difficile ridurre la crescita dell'entropia all'interno di qualsiasi organizzazione.

Ridurre il valore di C è una strategia più potente perché l'effetto è a lungo termine. Inoltre, C agisce come un importante controllo sulla crescita del rapporto tra I e S. Le azioni per ridurre C tendono a concentrarsi sul comportamento e sul pensiero umani. Sebbene queste azioni potrebbero non richiedere un'iterazione di sviluppo di per sé, rallenteranno le iterazioni successive man mano che i partecipanti accettano e si adeguano alle nuove procedure. L'apparentemente semplice atto di concordare quali miglioramenti dovrebbero essere apportati è un percorso irto di pericoli di per sé, poiché gli obiettivi disparati dei partecipanti e delle parti interessate del progetto vengono improvvisamente alla luce.

Avvolgendo

L'entropia del software è il rischio che la modifica del software esistente provochi problemi imprevisti, obiettivi non raggiunti o entrambi.

Sebbene trascurabile quando il software viene creato per la prima volta, l'entropia del software cresce ad ogni iterazione di sviluppo. Se è consentito procedere senza controllo, l'entropia del software alla fine interromperà l'ulteriore sviluppo.

Tuttavia, non tutti i progetti dovrebbero fare i conti con gli effetti dell'entropia del software. Molti sistemi saranno ritirati dalla produzione prima che l'entropia possa esercitare effetti evidenti e deleteri. Per coloro la cui vita è abbastanza lunga che l'entropia rappresenta un rischio credibile, creare consapevolezza e misurarne l'estensione, sebbene ancora bassa, fornisce un mezzo per garantire che lo sviluppo non venga interrotto prematuramente.

Una volta che un sistema è stato completamente sopraffatto dagli effetti dell'entropia del software, non è più possibile apportare modifiche e lo sviluppo è sostanzialmente giunto al termine.