Por que o software ainda é lançado com bugs conhecidos? [fechadas]

Parece que frequentemente em grandes projetos o software ainda é lançado com o rastreador de bugs cheio de bugs. Agora eu posso entender as solicitações de recursos, mas várias vezes vi um grande número de bugs ainda não resolvidos, não revisados ​​ou concluídos, mas uma versão ainda é enviada.

Por quê? Por que um projeto de código aberto ou um projeto em geral seria lançado com erros conhecidos ? Por que eles não esperaram até que o rastreador de bugs tivesse 0 bugs abertos?

Qualquer número de razões, incluindo:

1. A empresa havia se comprometido com a base de usuários a liberar em um determinado momento
2. Os bugs não eram de missão crítica, nem mesmo importantes
3. O desenvolvimento de novos recursos foi visto como mais importante (corretamente ou não)

Em certa medida, é como perguntar por que você trabalha como programador, mesmo que seu conhecimento de programação não esteja "completo". Nos projetos mais complexos, haverá muitos, muitos bugs. Lidar com eles enquanto adiciona novos recursos é uma tarefa difícil e complexa.

Porque um software com um bug é melhor do que nenhum software.
Pela mesma razão:

• As empresas de transporte se preocupam em fazer horários, mesmo que sempre haja atraso.
• As empresas farmacêuticas vendem medicamentos com efeitos colaterais conhecidos (e principalmente documentados).
• Escolas de todo o mundo ensinam física newtoniana, embora ela tenha limitações conhecidas.

Ter uma solução com deficiências conhecidas é muito melhor do que não ter solução ou ter uma solução com deficiências desconhecidas.
Meu IDE favorito tem muitos recursos novos, que estão longe de ser estáveis. Digamos: eu prefiro ter que fazer algo manualmente a cada vigésima vez, porque o recurso falha, em vez de ter que fazer tudo manualmente.

Ou então, com as palavras de Voltaire: "Le mieux est l'ennemi du bien".

Por fim, é uma decisão de negócios, mesmo para software livre e de código aberto. Há um ponto em que os defeitos existentes são de baixo impacto, é melhor liberar, colocar o software nas mãos do usuário e obter feedback (incluindo, entre outros, solicitações de recursos e novos relatórios de erros não encontrados) em testes). Essa decisão é motivada pela necessidade de obter tração no mercado para o software entre os concorrentes. Se você deseja que seu software cause impacto, você precisa vencer seus concorrentes no mercado com novos recursos ou conceitos.

tudo se resume a análise de custo versus benefício. Cada correção de bug possui algum valor de custo associado (horas de trabalho para correção, risco de fazer mais alterações de código X dias antes do lançamento ...). Ao mesmo tempo, cada correção de bug traz claramente um valor adicional em termos de mais recursos, usabilidade, etc.

Portanto, esta é a pergunta que toda equipe de desenvolvimento enfrenta ao fazer um lançamento: 1) vale a pena corrigir o bug #i, considerando o custo e o valor adicional e 2) repetir para todos os erros abertos de i = 0 a N.

Lembre-se de que um produto de software que não foi lançado não tem valor para ninguém. O produto de software que possui 200 erros pendentes, mas possui 90% de sua funcionalidade funcionando, tem valor para todas as pessoas que estão felizes com o que funciona no momento do lançamento.

Nunca estive em nenhuma empresa em nenhum produto lançado com 0 erros e acho perfeitamente normal. Em algum momento, você apenas reduz suas perdas e capitaliza sobre o que funciona. Caso contrário, você nunca liberará nada.

Em um projeto grande, você nunca para de encontrar erros. Se você tivesse que esperar até que todos os bugs fossem corrigidos e a regressão das correções testada, você nunca iria liberar.

Além disso, observe que nem todos os erros são internos. Todo programa faz parte de uma rede complexa de outro software, e as alterações em outros lugares podem se manifestar como "bugs" no seu software. Você não pode parar o mundo.

Além das muitas boas respostas, às vezes há uma corrida ao mercado com um novo produto. Se você acha que pode ganhar a maior parte do mercado, mesmo com 15% (ou outro número) de defeitos não críticos em aberto, pode valer a pena liberar o produto para obter uma vantagem sobre os concorrentes.

Esses erros podem ser bem menores. Lembre-se de que o software comercial precisa ser enviado e pressionado em discos e coisas assim. O cumprimento dessas datas de lançamento tem sérias implicações financeiras, e o atraso para alguns problemas menores não é financeiro - sem mencionar a necessidade de chegar ao mercado por outros motivos.

Respostas potenciais:

• É altamente improvável que alguém encontre o bug.
• Existem soluções alternativas para os erros.
• O software precisa ser lançado em algum momento, e é improvável que a perfeição seja alcançada.

Tenho certeza de que, idealmente, a maioria dos desenvolvedores gostaria de ver zero bugs em seus aplicativos. Infelizmente, as condições podem não permitir esse estado de utopia.

Gostaria de acreditar que é porque a base de usuários exige novos recursos e está disposta a incorporar os mesmos ou mais bugs para aumentar a funcionalidade.

Se houver gerenciamento envolvido, os prazos precisam ser cumpridos por uma série de razões - agendas de publicidade, problemas adicionais de disponibilidade da equipe, a mentalidade de "devemos ser o primeiro com essa funcionalidade".

Menos otimista em minha mente, possivelmente porque os desenvolvedores são preguiçosos?

Lembre-se também de que, nas comunidades de código aberto, é tipicamente "quem" deseja aceitar quais solicitações de bug / recurso / problema - talvez ninguém queira lidar com os problemas que estão presentes devido a problemas maiores por trás deles.

No teste programático mais simples:

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

Tudo é sempre uma troca, seja consertando bugs, tempo / espaço / memória ou segurança / usabilidade. Pense no cálculo da troca que foi feito. Você pode discordar, mas estará com problemas se não entender.

Além disso, pense nesses cálculos em uma curva em sino ... algumas pessoas fazem cálculos realmente ruins para os dois lados. Veja Duke Nukem Forever para uma extremidade da curva.