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

Qualsiasi numero di motivi, tra cui:

1. L'azienda si era impegnata a utilizzare la base utenti per il rilascio in un momento specifico
2. I bug non erano mission-critical, o anche importanti
3. Lo sviluppo di nuove funzionalità è stato considerato più importante (sia correttamente che non)

In piccola parte, è come chiedere 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 complesso e difficile.

Perché un software con un bug è migliore di nessun software.
Per lo stesso motivo:

• Le società di trasporti si preoccupano di fare programmi, anche se c'è sempre un ritardo.
• Le case farmaceutiche vendono farmaci con effetti collaterali noti (e per lo più documentati)
• Le scuole di tutto il mondo insegnano la fisica newtoniana, sebbene abbia conosciuto limitazioni.

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

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

In definitiva, è una decisione commerciale, anche per software gratuito e open source. C'è un punto in cui i difetti esistenti sono di basso impatto che è meglio rilasciare, portare il software nelle mani dell'utente e ottenere feedback (incluse, ma non limitate a, richieste di funzionalità e nuove segnalazioni di difetti non rilevati in fase di test). Questa decisione è guidata dalla necessità di ottenere una trazione nel 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. Ogni correzione di bug ha un certo valore di costo associato (man ore di correzione, rischio di apportare più 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 un rilascio: 1) il bug #i vale la pena di essere risolto dato il costo e il valore aggiuntivo e 2) ripetere per tutti i bug aperti da i = 0 a N.

Tieni presente che un prodotto software non rilasciato non ha alcun valore per nessuno. Il prodotto software che ha 200 bug in sospeso ma ha funzionato al 90% delle sue funzionalità, ha valore per tutte le persone che sono felici di ciò che funziona al momento del rilascio.

Non ho mai partecipato a nessuna compagnia su nessun prodotto che è stato rilasciato con 0 bug e penso che sia perfettamente normale. Ad un certo punto, hai appena tagliato le tue 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 fossero stati corretti e la regressione delle correzioni fosse stata testata, non avresti mai rilasciato.

Inoltre, nota che non tutti i bug sono interni. Ogni programma fa parte di una complessa rete di altri software, e cambia altrove può manifestarsi come "bug" nel software. Non puoi fermare il mondo.

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

Questi bug potrebbero essere piuttosto secondari. Ricorda che il software commerciale deve essere spedito e premuto su dischi e cose simili. L'incontro con le date di rilascio ha gravi implicazioni finanziarie e il ritardo di alcune questioni minori non ha senso finanziario, per non parlare della necessità di entrare sul mercato per altri motivi.

Risposte potenziali:

• È altamente improbabile che qualcuno incontri il bug.
• Esistono soluzioni alternative per i bug.
• Il software deve essere rilasciato a volte e la perfezione è improbabile che possa essere raggiunta.

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.

Mi piacerebbe credere che sia perché la base di utenti richiede nuove funzionalità e sono disposti a prendere lo stesso o più bug per funzionalità aggiuntive.

Se il management è coinvolto, le scadenze devono essere soddisfatte per una serie di motivi: programmi pubblicitari, problemi di disponibilità dello staff aggiuntivi, mentalità "dobbiamo essere-prima-con-questa-funzionalità".

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

Ricorda inoltre che nelle comunità open-source è in genere "chi" vuole accettare le richieste di bug / funzionalità / problema - forse nessuno desidera occuparsi dei problemi che sono presenti a causa di problemi più ampi alle spalle.