Perché il software viene ancora rilasciato con bug noti? [chiuso]

Sembra che spesso in grandi progetti il ​​software sia ancora rilasciato con il bug tracker pieno di bug. Ora riesco a capire le richieste di funzionalità, ma più volte ho visto un gran numero di bug ancora irrisolti, non rivisti o non finiti, ma una versione è ancora distribuita.

Perché? Perché un progetto open source o un progetto in generale dovrebbe essere rilasciato con bug noti ? Perché non dovrebbero aspettare fino a quando il tracker dei bug non ha aperto 0 bug?

Qualsiasi numero di motivi, tra cui:

1. La società si era impegnata a rilasciare una base di utenti in un determinato momento
2. I bug non erano mission-critical, o addirittura importanti
3. Lo sviluppo di nuove funzionalità è stato considerato più importante (correttamente o meno)

In piccola parte, è come chiedersi perché lavori come programmatore anche se le tue conoscenze di programmazione non sono "complete". Nei progetti più complessi, ci saranno molti, molti bug. Trattare con loro mentre si aggiungono nuove funzionalità è un compito difficile e complesso.

Perché un software con un bug è meglio di nessun software.
Per la stessa ragione:

• Le compagnie di trasporto si preoccupano di programmare, anche se c'è sempre un ritardo.
• Le aziende farmaceutiche vendono farmaci con effetti collaterali noti (e per lo più documentati).
• Le scuole di tutto il mondo insegnano la fisica newtoniana, sebbene abbia dei limiti noti.

Avere una soluzione con carenze note è molto meglio che non avere una soluzione o avere una soluzione con carenze sconosciute.
Il mio IDE preferito ha molte nuove funzionalità, tutt'altro che stabili. Diciamo solo: preferisco fare qualcosa a mano ogni ventesimo volta, perché la funzione fallisce, piuttosto che dover fare tutto a mano.

O per dirlo con le parole di Voltaire: "Le mieux est l'ennemi du bien".

In definitiva, è una decisione aziendale, anche per software gratuito e open source. C'è un punto in cui i difetti esistenti hanno un basso impatto che è meglio rilasciare, mettere il software nelle mani dell'utente e ottenere feedback (incluse, a titolo esemplificativo ma non esaustivo, richieste di funzionalità e nuove segnalazioni di bug di difetti non trovati in fase di test). Questa decisione è guidata dalla necessità di ottenere una trazione sul mercato del software tra i concorrenti. Se vuoi che il tuo software abbia un impatto, devi battere i tuoi concorrenti sul mercato con nuove funzionalità o concetti.

tutto si riduce all'analisi costi / benefici. A ogni correzione di bug è associato un certo valore di costo (ore uomo da correggere, rischio di apportare ulteriori modifiche al codice X giorni prima del rilascio ...). Allo stesso tempo, ogni correzione di bug porta chiaramente un valore aggiunto in termini di più funzionalità, usabilità, ecc.

Quindi questa è la domanda che ogni team di sviluppo deve affrontare quando rilascia una release: 1) è Bug #i che vale la pena correggere dato il costo e il valore aggiuntivo e 2) ripeti per tutti i bug aperti da i = 0 a N.

Tieni presente che un prodotto software che non viene rilasciato NON ha valore per nessuno. Il prodotto software che ha 200 bug eccezionali ma ha il 90% delle sue funzionalità funzionanti, ha valore per tutte le persone che sono contente di ciò che funziona al momento del rilascio.

Non ho mai avuto alcuna azienda su alcun prodotto che è stato rilasciato con 0 bug e penso che sia perfettamente normale. Ad un certo punto, hai appena tagliato le perdite e capitalizzato su ciò che funziona. Altrimenti, non rilascerai mai nulla.

In un grande progetto, non smetti mai di trovare bug. Se dovessi aspettare fino a quando tutti i bug non sono stati corretti e la regressione delle correzioni testata, non verrai mai rilasciato.

Inoltre, tieni presente che non tutti i bug sono interni. Ogni programma fa parte di una complessa rete di altri software e i cambiamenti altrove possono manifestarsi come "bug" nel tuo software. Non puoi fermare il mondo.

Oltre alle molte buone risposte, a volte c'è una corsa al mercato con un nuovo prodotto. Se ritieni di poter ottenere la maggior parte della quota di mercato anche con il 15% (o qualche altro numero) di difetti non critici aperti, potrebbe valere la pena rilasciare il prodotto per ottenere un vantaggio sui concorrenti.

Questi bug possono essere piuttosto minori. Ricorda che il software commerciale deve essere spedito e stampato su dischi e simili. Il rispetto di tali date di rilascio ha serie implicazioni finanziarie e il ritardo per alcune questioni minori non ha senso finanziario, per non parlare della necessità di arrivare sul mercato per altri motivi.

Potenziali risposte:

• È altamente improbabile che qualcuno incontri il bug.
• Esistono soluzioni alternative per i bug.
• Il software deve essere rilasciato qualche volta ed è improbabile che si raggiunga la perfezione.

Sono sicuro che idealmente la maggior parte degli sviluppatori vorrebbe vedere zero bug nelle loro applicazioni, purtroppo le condizioni potrebbero non consentire un tale stato di utopia.

Vorrei credere che sia perché la base di utenti richiede nuove funzionalità e è disposta a inserire gli stessi o più bug per funzionalità aggiuntive.

Se è coinvolta la gestione, le scadenze devono essere rispettate per una serie di motivi: programmi pubblicitari, ulteriori problemi di disponibilità del personale, la mentalità "dobbiamo essere i primi con questa funzionalità".

Meno ottimista nella mia mente, forse perché gli sviluppatori sono pigri?

Ricorda anche che nelle comunità open-source è in genere "chi" vuole accettare quali richieste di bug / funzionalità / problema - forse nessuno desidera affrontare i problemi che sono presenti a causa di problemi più grandi dietro di loro.

Nel test programmatico più semplice:

if (management->perceived_cost_to_fix > management->perceived_benefit_release_now) {
    release;
}

Tutto è sempre un compromesso, che si tratti di correggere bug, tempo / spazio / memoria o sicurezza / usabilità. Pensa al calcolo del compromesso che è stato fatto. Potresti non essere d'accordo, ma sei nei guai se non lo capisci.

Inoltre, pensa a quei calcoli in una curva a campana ... alcune persone ne faranno davvero cattivi su entrambi i lati. Vedi Duke Nukem per sempre per un'estremità della curva.