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

18

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?

TheLQ
quelle
3
Riecht wie ein Betrogener.
Job
41
Zeigen Sie uns einige brauchbare Software ohne Fehler.
Joel Etherton
13
Denn während die Zeit unendlich ist, sind es die Menschen nicht?
Joe
7
Vielen Dank für diesen Beitrag, der mich zum Lachen gebracht hat ... Ich war nicht überrascht zu sehen, dass Sie 18 in Ihrem Profil sind. : D Sie haben offensichtlich noch nicht mit Software-Team-Managern zusammengearbeitet .
Yam Marcovic
7
Einer der häufigsten Gründe: Das Release behebt kritische Fehler oder Fehler, die Kunden in der realen Welt betreffen, und fügt, zumindest soweit bekannt, wahrscheinlich keine neuen Fehler hinzu.
David Schwartz

Antworten:

41

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.

eykanal
quelle
24
+1, aber ich möchte hinzufügen: 4) Bizarre unwiederholbare scheinbar einmalige Fehler, die von der Qualitätssicherung protokolliert werden. Diese Art von Dingen sollte nachverfolgt werden, kann jedoch das Ergebnis eines unerklärlichen Netzwerkausfalls, ungeplanter Ausfallzeiten in der Umgebung sein oder die Qualitätssicherung hat einfach nicht genug Informationen geliefert, um möglicherweise ein Debugging durchzuführen. 5) Kleinere Fehler, deren Behebung einen unverhältnismäßigen Aufwand erfordert, z. Kompletter Refactor eines bestimmten Moduls.
maple_shaft
4
Guter Kommentar, die kleinen Bugs, die gigantische Umgestaltungsbemühungen erfordern, um sie zu beseitigen, bleiben unberücksichtigt.
eykanal
5
Könnte auch sein, dass Bugs vom Unternehmen nicht als missionskritisch oder schwerwiegend eingestuft wurden. Kunden sagen vielleicht etwas anderes, aber Sie wissen nur, wann Ihre Kunden es Ihnen sagen.
Joshin4colours
37

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."

back2dos
quelle
22

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.

Thomas Owens
quelle
1
Ich würde bemerken, dass offensichtlich, wenn Ihre Software voll von Fehlern ist, die Auswirkungen nicht vorteilhaft sein können;)
Matthieu M.
7

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.

DXM
quelle
6

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.

ddyer
quelle
Dies hängt damit zusammen, dass jede Fehlerkorrektur die Möglichkeit bietet, neue Fehler in das Produkt aufzunehmen, die schwerwiegender sein können als der ursprüngliche Fehler.
Malachi
4

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.

FrustratedWithFormsDesigner
quelle
2

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.

DeadMG
quelle
2

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.
John Fisher
quelle
2

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.

Darren Nolan
quelle
1

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.

Jeff Ferland
quelle