A intervalli più o meno regolari, salta fuori la questione suggerita nel titolo, direi anzi che si tratta di una costante dell'industria del software, che però è bene ricordare di tanto in tanto. Ovviamente, ponendo la domanda in modo diretto, nessun responsabile ammetterà di rilasciare dei prodotti bacati. Ma tutti hanno bene in mente la legge del diminishing returns, la quale, in parole povere, stabilisce una sorta di punto di equilibrio, oltre il quale non è più vantaggioso accanirsi, pena un calo degli introiti o evidenti perdite.

Cerchiamo di chiarire le cose con un esempio astratto: supponiamo di avere un programma con 100 difetti, ognuno dei quali richieda un'unità di lavoro; immaginiamo che 40 di queste ultime siano necessarie per trovare i primi 70 errori, le altre 30 troveranno 20 bachi, e le rimanenti 30 scoveranno gli ultimi 10 errori.

Questo significa che la soluzione dei primi 70 bachi richiede 40/70=0,571 unità di lavoro, i successivi 30 1,5 unità lavorative, fino ad arrivare a un costo di 3 unità per i restanti 10. Questi ultimi richiedono quindi più di 5 volte le risorse impiegate per i primi 70.

Ci si può giustamente chiedere se sia redditizio ostinarsi su quegli ultimi dieci, tenendo anche conto che stiamo parlando di una situazione ideale: nella realtà, nessuno è in grado di dire che si è risolto l'ultimo baco, semplicemente perché nessuno sa quanti siano.

Un'ulteriore difficoltà è la seguente: come si fa a decidere quali sono i difetti gravi, sui quali vale la pena perseverare? Per risolvere il problema, Andy Boothe, nel suo blog, propone due regole d'oro, entrambe di carattere eminentemente economico: non mettere in imbarazzo la compagnia e non perdere clienti.

Naturalmente, è indispensabile sapere di quale software si tratta: se è un gioco, il ragionamento è valido, se si tratta di elaborazioni economico/finanziarie, perde la sua solidità, per non parlare degli applicativi (embedded o meno) in campo medico, che possono mettere a rischio la vita di una persona.