Pourquoi le logiciel est-il toujours publié avec des bogues connus? [fermé]

Il semble que fréquemment dans les grands projets, le logiciel soit toujours publié avec le bug tracker plein de bugs. Maintenant, je peux comprendre les demandes de fonctionnalités, mais à plusieurs reprises, j'ai vu un grand nombre de bogues non résolus, non examinés ou non terminés, mais une version est toujours repoussée.

Pourquoi? Pourquoi un projet open source ou un projet en général serait-il publié avec des bogues connus ? Pourquoi n'attendraient-ils pas que le traqueur de bogues n'ait aucun bogue ouvert?

Un certain nombre de raisons, notamment:

1. La société s'était engagée auprès de la base d'utilisateurs à publier à un moment donné
2. Les bogues n'étaient pas critiques, ni même majeurs
3. Le développement de nouvelles fonctionnalités a été jugé plus important (correctement ou non)

Dans une petite mesure, cela revient à vous demander pourquoi vous travaillez en tant que programmeur même si vos connaissances en programmation ne sont pas "complètes". Dans les projets les plus complexes, il y aura de très nombreux bugs. Les traiter tout en ajoutant de nouvelles fonctionnalités est une tâche difficile et complexe.

Parce qu'un logiciel avec un bug est mieux que pas de logiciel du tout.
Pour la même raison:

• Les entreprises de transport prennent la peine de prendre des horaires, même s'il y a toujours du retard.
• Les sociétés pharmaceutiques vendent des médicaments dont les effets secondaires sont connus (et principalement documentés).
• Les écoles du monde entier enseignent la physique newtonienne, bien qu'elle ait des limites connues.

Avoir une solution avec des carences connues est bien mieux que de ne pas avoir de solution, ou avoir une solution avec des carences inconnues.
Mon IDE préféré a beaucoup de nouvelles fonctionnalités, qui sont loin d'être stables. Disons simplement: je préfère, devoir faire quelque chose à la main tous les vingtièmes fois, parce que la fonctionnalité échoue, plutôt que de tout faire à la main.

Ou pour le dire avec les mots de Voltaire: "Le mieux est l'ennemi du bien."

En fin de compte, c'est une décision commerciale, même pour les logiciels libres et open source. Il y a un moment où les défauts existants ont un faible impact qu'il vaut mieux publier, mettre votre logiciel entre les mains de l'utilisateur et obtenir des commentaires (y compris, mais sans s'y limiter, des demandes de fonctionnalités et de nouveaux rapports de bogues de défauts non trouvés lors des tests). Cette décision est motivée par la nécessité de s'imposer sur le marché des logiciels chez les concurrents. Si vous voulez que votre logiciel ait un impact, vous devez battre vos concurrents sur le marché avec de nouvelles fonctionnalités ou de nouveaux concepts.

tout se résume à l'analyse des coûts par rapport aux avantages. Chaque correction de bogue a une certaine valeur de coût qui lui est associée (heures de travail pour corriger, risque de faire plus de changements de code X jours avant la sortie ...). Dans le même temps, chaque correction de bogue apporte clairement une valeur supplémentaire en termes de fonctionnalités, de convivialité, etc.

C'est donc la question à laquelle chaque équipe de développement est confrontée lors de la publication d'une version: 1) le bogue #i mérite d'être corrigé compte tenu du coût et de la valeur supplémentaire et 2) répéter pour tous les bogues ouverts de i = 0 à N.

Gardez à l'esprit qu'un produit logiciel qui n'est pas publié n'a aucune valeur pour personne. Un logiciel qui a 200 bogues en suspens mais dont 90% de ses fonctionnalités fonctionnent, a de la valeur pour toutes les personnes qui sont satisfaites de ce qui fonctionne au moment de la sortie.

Je n'ai jamais vu dans aucune entreprise aucun produit sorti avec 0 bogue et je pense que c'est parfaitement normal. À un moment donné, vous venez de réduire vos pertes et de capitaliser sur ce qui fonctionne. Sinon, vous ne sortirez jamais rien.

Dans un grand projet, vous n'arrêtez jamais de trouver des bugs. Si vous deviez attendre que tous les bogues soient corrigés et que la régression des correctifs soit testée, vous ne le publieriez jamais.

Notez également que tous les bogues ne sont pas internes. Chaque programme fait partie d'un réseau complexe d'autres logiciels, et les changements ailleurs peuvent se manifester comme des «bogues» dans votre logiciel. Vous ne pouvez pas arrêter le monde.

En plus des nombreuses bonnes réponses, il y a parfois une course au marché avec un nouveau produit. Si vous pensez que vous pouvez gagner la majorité des parts de marché même avec 15% (ou un autre nombre) de défauts non critiques ouverts, il pourrait être utile de libérer le produit pour obtenir un avantage sur les concurrents.

Ces bogues peuvent être assez mineurs. N'oubliez pas que les logiciels commerciaux doivent être expédiés et pressés sur des disques, etc. Le respect de ces dates de sortie a de graves implications financières, et retarder certains problèmes mineurs n'est pas un bon sens financier - sans parler de la nécessité de se lancer sur le marché pour d'autres raisons.

Réponses potentielles:

• Il est très peu probable que quiconque rencontre le bogue.
• Il existe des solutions de contournement pour les bogues.
• Le logiciel doit être publié un jour et il est peu probable que la perfection soit atteinte.

Je suis sûr qu'idéalement, la plupart des développeurs aimeraient voir zéro bogue dans leurs applications, malheureusement les conditions peuvent ne pas permettre un tel état d'utopie.

J'aimerais croire que c'est parce que la base d'utilisateurs exige de nouvelles fonctionnalités et est prête à accepter les mêmes bogues ou plus pour des fonctionnalités supplémentaires.

Si la direction est impliquée, les délais doivent être respectés pour diverses raisons - les calendriers publicitaires, les problèmes de disponibilité supplémentaires du personnel, l'état d'esprit "nous devons être les premiers avec cette fonctionnalité".

Moins optimiste dans mon esprit, peut-être parce que les développeurs sont paresseux?

Souvenez-vous également que dans les communautés open-source, c'est généralement "qui" veut prendre en charge les demandes de bogue / fonctionnalité / problème - peut-être que personne ne souhaite traiter les problèmes qui sont présents en raison de problèmes plus importants derrière eux.

Dans le test programmatique le plus simple:

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

Tout est toujours un compromis, qu'il s'agisse de corriger des bogues, de temps / espace / mémoire ou de sécurité / convivialité. Pensez au calcul de compromis qui a été fait. Vous pouvez être en désaccord avec cela, mais vous avez des problèmes si vous ne le comprenez pas.

Pensez également à ces calculs dans une courbe en cloche ... certaines personnes en feront de très mauvais de chaque côté. Voir Duke Nukem Forever pour une extrémité de la courbe.