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.
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.
A noi piace scrivere, dai un’occhiata alle nostre guide e approfondimenti
Library di Innovazione Digitale.--. .---. .---|__| .-. |~~~| .--|===|--|_ |_| |~~~|--. | |===| |'\ .---!~| .--| |--| |%%| | |.'\ |===| |--|%%| | | |%%| | |\.'\ | | |__| | | | | | | | \ \ |===| |==| | | | | | |__| \.'\ | |_|__| |~~~|__| | |===|--| \.'\|===|~|--|%%|~~~|--| ^--^---'--^ `-'`---^-^--^--^---'--'
“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.
Ancora una volta, con le parole di Martin:
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.
,---------------------------------------.---------. | | | | ,-----------------------------. | . | | | | | | | | | ,-------------------. | | | | | | | | | | | | | | `---- ,---- | | | | | | | | @ | | | | | | | ,---------"---------: | `----' | | | | | | | | `----: ,---------. | `---------. | | | | | | | | | . | | . | | ---------' | | | | | | | | | :----' | | | | | ,--------------: | | | | | | | | | . | `----' | | | ----. | | | | | | | | | | `----"--------- | | `---------' | | | | | `------------------------' `-------------------'