Tidy First?

Capitolo 30. Equivalenza di Costantino

Questo lavoro è stato tradotto utilizzando l'AI. Siamo lieti di ricevere il tuo feedback e i tuoi commenti: [e-mail]

Ricordo che da giovane programmatore sentivo dire che il 70% dei costi di sviluppo del software era destinato alla manutenzione. Il 70%! Quanto dobbiamo fare un pessimo lavoro per creare una cosa e poi dover spendere il doppio per farla funzionare?

Si scopre che il modello mentale del software di , come una cosa che viene creata e che poi dovrebbe funzionare per sempre senza variazioni, come una sorta di macchina del moto perpetuo, è l'opposto di ciò che accade realmente, e anche di ciò che dovrebbe accadere. Il valore futuro di un sistema si rivela nella realtà di oggi, non nelle speculazioni di ieri.

Avendo ben chiaro il modo in cui l'accoppiamento influisce sullo sviluppo del software , siamo pronti a capire il significato dell'accoppiamento. Nell'opera originale sull'accoppiamento e la coesione, Structured Design, Ed Yourdon e Larry Constantine hanno affermato che l'obiettivo della progettazione del software è minimizzare il costo del software (ma anche massimizzare il valore, ma ci arriveremo). Ma quali sono questi costi?

La stima del 70% si è rivelata troppo bassa. Se applichiamo la nostra creatività, possiamo rilasciare un software che crea valore a pochi centesimi dal suo costo di sviluppo finale. È nell'interesse di tutti farlo. Prima otteniamo un feedback dall'utilizzo reale, meno tempo/denaro/opportunità ...