Warum wird Software immer noch mit bekannten Fehlern veröffentlicht? [geschlossen]

Es scheint, dass in großen Projekten die Software immer noch mit dem Bug-Tracker voller Fehler veröffentlicht wird. Jetzt kann ich Feature-Anfragen nachvollziehen, aber ich habe mehrere Male gesehen, dass eine große Anzahl von Bugs immer noch ungelöst, nicht überprüft oder nicht abgeschlossen ist, aber eine Veröffentlichung wird immer noch herausgebracht.

Warum? Warum sollte ein Open Source-Projekt oder ein Projekt im Allgemeinen mit bekannten Fehlern veröffentlicht werden? Warum sollten sie nicht warten, bis der Bug-Tracker 0 geöffnete Bugs hatte?

Beliebig viele Gründe, darunter:

1. Das Unternehmen hatte sich verpflichtet, die Benutzer zu einem bestimmten Zeitpunkt freizugeben
2. Bugs waren nicht geschäftskritisch oder sogar schwerwiegend
3. Die Entwicklung neuer Funktionen wurde als wichtiger angesehen (ob korrekt oder nicht)

In gewissem Maße ist dies wie die Frage, warum Sie als Programmierer arbeiten, obwohl Ihre Programmierkenntnisse nicht "vollständig" sind. In den meisten komplexen Projekten wird es viele, viele Fehler geben. Der Umgang mit ihnen beim Hinzufügen neuer Funktionen ist eine schwierige und komplexe Aufgabe.

Denn eine Software mit einem Bug ist besser als gar keine Software.
Aus dem gleichen Grunde:

• Transportunternehmen machen sich die Mühe, Zeitpläne zu erstellen, obwohl es immer zu Verzögerungen kommt.
• Pharmaunternehmen verkaufen Medikamente mit bekannten (und meist dokumentierten) Nebenwirkungen.
• Schulen auf der ganzen Welt unterrichten Newtonsche Physik, obwohl es Einschränkungen gibt.

Eine Lösung mit bekannten Mängeln ist viel besser als keine Lösung oder eine Lösung mit unbekannten Mängeln.
Meine Lieblings-IDE hat viele neue Funktionen, die alles andere als stabil sind. Sagen wir einfach: Ich bevorzuge es, jedes zwanzigste Mal etwas von Hand tun zu müssen, weil die Funktion fehlschlägt, anstatt alles von Hand tun zu müssen.

Oder um es mit den Worten von Voltaire zu sagen: "Le mieux est l'ennemi du bien."

Letztendlich ist es eine Geschäftsentscheidung, auch für freie und Open-Source-Software. Es gibt einen Punkt, an dem die vorhandenen Fehler nur geringe Auswirkungen haben. Es ist besser, sie freizugeben, Ihre Software in die Hände des Benutzers zu legen und Feedback zu erhalten (einschließlich, aber nicht beschränkt auf Funktionsanfragen und neue Fehlerberichte über nicht gefundene Fehler im Test). Diese Entscheidung wird von der Notwendigkeit getrieben, bei Wettbewerbern auf dem Markt für die Software Fuß zu fassen. Wenn Sie möchten, dass Ihre Software Wirkung zeigt, müssen Sie Ihre Konkurrenten schlagen, um mit neuen Funktionen oder Konzepten auf den Markt zu kommen.

Alles läuft auf eine Kosten-Nutzen-Analyse hinaus. Mit jeder Fehlerbehebung sind einige Kosten verbunden (zu behebende Arbeitsstunden, Risiko, X Tage vor der Veröffentlichung weitere Codeänderungen vorzunehmen ...). Gleichzeitig bringt jede Fehlerbehebung einen deutlichen Mehrwert in Bezug auf mehr Funktionen, Benutzerfreundlichkeit usw.

Dies ist also die Frage, mit der sich jedes Entwicklungsteam bei der Veröffentlichung eines Releases konfrontiert sieht: 1) Ist der Fehler # i angesichts der Kosten und des zusätzlichen Werts zu beheben? 2) Wiederholen Sie dies für alle offenen Fehler von i = 0 bis N.

Beachten Sie, dass ein nicht veröffentlichtes Softwareprodukt für niemanden von Wert ist. Ein Softwareprodukt mit 200 ausstehenden Fehlern, bei dem 90% der Funktionen ausgeführt werden, ist für alle Menschen von Nutzen, die mit den Funktionen zum Zeitpunkt der Veröffentlichung zufrieden sind.

Ich habe noch nie in einer Firma ein Produkt getestet, das mit 0 Bugs veröffentlicht wurde, und ich denke, das ist völlig normal. Irgendwann reduzieren Sie einfach Ihre Verluste und profitieren davon, was funktioniert. Sonst wirst du nie etwas veröffentlichen.

In einem großen Projekt hört man nie auf, Fehler zu finden. Wenn Sie warten müssten, bis alle Fehler behoben und die Korrekturen einer Regression unterzogen wurden, würden Sie sie niemals veröffentlichen.

Beachten Sie außerdem, dass nicht alle Fehler intern sind. Jedes Programm ist Teil eines komplexen Netzes anderer Software, und Änderungen an anderen Stellen können sich als "Fehler" in Ihrer Software äußern. Du kannst die Welt nicht aufhalten.

Neben den vielen guten Antworten gibt es manchmal einen Wettlauf um die Vermarktung eines neuen Produkts. Wenn Sie der Meinung sind, dass Sie den größten Teil des Marktanteils erzielen können, selbst wenn 15% (oder eine andere Anzahl) der nicht kritischen Mängel offen sind, kann es sich lohnen, das Produkt freizugeben, um einen Wettbewerbsvorteil zu erzielen.

Diese Bugs können ziemlich geringfügig sein. Denken Sie daran, dass kommerzielle Software ausgeliefert und auf Discs und dergleichen gepresst werden muss. Das Einhalten dieser Veröffentlichungstermine hat schwerwiegende finanzielle Auswirkungen, und das Hinauszögern einiger kleinerer Probleme ist finanziell nicht sinnvoll - ganz zu schweigen von der Notwendigkeit, aus anderen Gründen auf den Markt zu kommen.

Mögliche Antworten:

• Es ist höchst unwahrscheinlich, dass jemand auf den Fehler stößt.
• Es gibt Workarounds für die Bugs.
• Die Software muss irgendwann veröffentlicht werden, und es ist unwahrscheinlich, dass Perfektion erreicht wird.

Ich bin sicher, im Idealfall würden die meisten Entwickler gerne null Fehler in ihren Anwendungen sehen. Leider können die Bedingungen einen solchen Utopiezustand nicht zulassen.

Ich würde gerne glauben, dass dies daran liegt, dass die Anwenderbasis neue Funktionen fordert und bereit ist, dieselben oder mehr Fehler für zusätzliche Funktionen zu berücksichtigen.

Wenn das Management involviert ist, müssen Fristen aus einer Reihe von Gründen eingehalten werden - Werbepläne, zusätzliche Mitarbeiterverfügbarkeitsprobleme, die Einstellung "Wir müssen die Ersten mit dieser Funktionalität sein".

In meinen Augen weniger optimistisch, möglicherweise weil die Entwickler faul sind?

Denken Sie auch daran, dass es in Open-Source-Communities in der Regel "wen" betrifft, welche Fehler- / Feature- / Issue-Anfragen zu bearbeiten - vielleicht möchte sich niemand mit den Problemen befassen, die aufgrund größerer dahinter stehender Probleme auftreten.

Im einfachsten programmatischen Test:

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

Alles ist immer ein Kompromiss, ob es um die Behebung von Fehlern, Zeit / Raum / Speicher oder Sicherheit / Benutzerfreundlichkeit geht. Denken Sie an die Kompromissberechnung, die durchgeführt wurde. Sie können damit nicht einverstanden sein, aber Sie sind in Schwierigkeiten, wenn Sie es nicht verstehen.

Denken Sie auch an diese Berechnungen in einer Glockenkurve ... einige Leute werden auf beiden Seiten wirklich schlechte machen. Siehe Duke Nukem Forever für ein Ende der Kurve.