Best Practice,

Il software di qualità costa meno, sulle orme di Martin Fowler

Prendere il tempo necessario per sviluppare software di qualità o, invece, consegnare il maggior numero di funzionalità possibili nel minor tempo? Un dibattito mai banale e sempre attuale, che vede spesso vincere la quantità a scapito della qualità. Martin Fowler ha affrontato il tema con una nuova prospettiva.

“This trade-off does not apply to software: in that high quality software is actually cheaper to produce”. Ci si potrebbe fermare qui, e presentarsi con questa frase alla prossima riunione: ipse dixit! Ma questa volta Martin si spende per spiegare le sue ragioni ad un pubblico più ampio che i soli sviluppatori, vale quindi la pena di prendere qualche appunto.

Cos’è la qualità del software

Prima di tutto ci viene fatto notare che la qualità del software non è un indice unico, ma comprende più cose: l’efficacia dell’interfaccia utente, una buona organizzazione del codice, l’affidabilità dell’architettura. Tipicamente un responsabile marketing non si accorge di quanto un software sia “ben organizzato”, mentre guarda sicuramente l’interfaccia utente. È nel momento in cui si troverà a chiedere una modifica abbastanza consistente che una scarsa qualità del software gli si mostrerà nella terribile forma di tempi di lavorazione più lunghi e risultati spesso instabili. Martin ci propone una appropriata distinzione tra gli attributi esterni del software (ad esempio la UI) e gli attributi interni (relativi a codice e architettura). Questi ultimi non sembrano essere importanti per il cliente, finché non si manifestano come un problema incomprensibile, la cui origine gli resta altrettanto oscura.

Il (vero) time-to-market

“Here we see a clue of why internal quality does matter to users and customers. Better internal quality makes adding new features easier, therefore quicker and cheaper.”. Il ruolo fondamentale della qualità interna è che abbatte i costi di miglioramento e aggiornamento del software: qualsiasi nuova funzionalità, che venga da un’idea geniale di un marketer, da un bisogno degli utenti o da un’analisi dei competitor, potrà essere sviluppata in tempi molto brevi e competitivi. Sacrificando la qualità interna si ottiene un illusorio beneficio nel time-to-market, approdando presto sul mercato con le funzionalità che si erano pensate necessarie in un primo momento. Ma quando il mercato mostrerà attenzione per il software e gli chiederà di adattarsi alle sue (indiscutibili) esigenze, i fragili attributi interni non reggeranno all’accelerazione, con conseguente picco di costo e fatica per rimanere al passo: non c’è team, per quanto preparato e performante, che sotto stress non mostri una curva decrescente di qualità, ovvero produca sempre più errori e imperfezioni (“cruft”), scatenando quindi un circolo vizioso. Chiunque voi siate, qualsiasi ruolo abbiate, ricordate che la fatica è una quantità oggettiva e non può essere ignorata oltre un certo limite.

4 semplici osservazioni

Ancora una volta, con le parole di Martin:

  • Neglecting internal quality leads to rapid build up of cruft
  • This cruft slows down feature development
  • Even a great team produces cruft, but by keeping internal quality high, is able to keep it under control
  • High internal quality keeps cruft to a minimum, allowing a team to add features with less effort, time, and cost.

L’articolo originale è interessante e più completo di questa nostra introduzione al tema, e puì aiutarvi a ottenere un software migliore, qualsiasi sia il vostro ruolo nell’impresa.