Dlaczego oprogramowanie jest nadal wydawane ze znanymi błędami? [Zamknięte]

Wygląda na to, że często w dużych projektach oprogramowanie jest nadal wydawane z funkcją śledzenia błędów pełną błędów. Teraz rozumiem prośby o nowe funkcje, ale kilka razy widziałem wiele nierozwiązanych błędów, które nie zostały sprawdzone lub nie zostały ukończone, ale wydanie jest nadal wypychane.

Dlaczego? Dlaczego projekt o otwartym kodzie źródłowym lub projekt miałby zostać wydany ze znanymi błędami? Dlaczego nie mieliby czekać, aż moduł śledzenia błędów otworzy 0 błędów?

Dowolna liczba powodów, w tym:

1. Firma zobowiązała się do udostępnienia bazy użytkowników w określonym czasie
2. Błędy nie były krytyczne ani nawet poważne
3. Rozwój nowych funkcji uznano za ważniejszy (poprawny czy nie)

W pewnym stopniu przypomina to pytanie, dlaczego pracujesz jako programista, mimo że Twoja wiedza programistyczna nie jest „kompletna”. W najbardziej złożonych projektach będzie wiele błędów. Radzenie sobie z nimi podczas dodawania nowych funkcji jest trudnym, złożonym zadaniem.

Ponieważ oprogramowanie z błędem jest lepsze niż żadne oprogramowanie.
Z tego samego powodu:

• Firmy transportowe mają problem z ustalaniem harmonogramów, mimo że zawsze występuje opóźnienie.
• Firmy farmaceutyczne sprzedają leki o znanych (i najczęściej udokumentowanych) skutkach ubocznych.
• Szkoły na całym świecie uczą fizyki newtonowskiej, choć ma ona ograniczenia.

Posiadanie rozwiązania ze znanymi brakami jest znacznie lepsze niż brak rozwiązania lub posiadanie rozwiązania z nieznanymi brakami.
Moje ulubione IDE ma wiele świeżych funkcji, które wcale nie są stabilne. Powiedzmy po prostu: wolę robić coś ręcznie co 20 razy, ponieważ ta funkcja zawodzi, niż robić to wszystko ręcznie.

Lub powiedzieć to słowami Voltaire: „Le mieux est l'ennemi du bien”.

Ostatecznie jest to decyzja biznesowa, nawet dla darmowego i otwartego oprogramowania. Istnieje punkt, w którym istniejące wady mają niewielki wpływ, dlatego lepiej je zwolnić, oddać oprogramowanie w ręce użytkownika i uzyskać informacje zwrotne (w tym między innymi prośby o funkcje i nowe raporty o błędach nie znaleziono wad w testach). Decyzja ta wynika z potrzeby uzyskania trakcji na rynku oprogramowania wśród konkurentów. Jeśli chcesz, aby twoje oprogramowanie wywarło wpływ, musisz pokonać konkurencję, wprowadzając nowe funkcje lub koncepcje.

wszystko sprowadza się do analizy kosztów i korzyści. Każda poprawka błędu wiąże się z pewną wartością kosztu (naprawa godzin pracy, ryzyko wprowadzenia większej liczby zmian kodu X dni przed wydaniem ...). Jednocześnie każda poprawka błędu w oczywisty sposób wnosi dodatkową wartość pod względem większej liczby funkcji, użyteczności itp.

Tak więc pytanie, przed którym staje każdy zespół programistów podczas wydawania wydania: 1) czy Bug #i jest wart naprawienia, biorąc pod uwagę koszt i dodatkową wartość oraz 2) powtórz dla wszystkich otwartych błędów od i = 0 do N.

Należy pamiętać, że oprogramowanie, które nie zostało wydane, nie ma żadnej wartości dla nikogo. Oprogramowanie, które ma 200 zaległych błędów, ale działa 90% jego funkcjonalności, ma wartość dla wszystkich osób, które są zadowolone z tego, co działa w momencie wydania.

Nigdy nie miałem w żadnej firmie żadnego produktu, który zostałby wydany z 0 błędami i myślę, że to zupełnie normalne. W pewnym momencie po prostu ograniczasz straty i korzystasz z tego, co działa. W przeciwnym razie nigdy niczego nie wydasz.

W dużym projekcie nigdy nie przestajesz znajdować błędów. Gdybyś musiał poczekać, aż wszystkie błędy zostaną naprawione, a regresja poprawek przetestowana, nigdy nie zwolnisz.

Pamiętaj też, że nie wszystkie błędy są wewnętrzne. Każdy program jest częścią złożonej sieci innego oprogramowania, a zmiany gdzie indziej mogą objawiać się jako „błędy” w twoim oprogramowaniu. Nie możesz zatrzymać świata.

Oprócz wielu dobrych odpowiedzi, czasami pojawia się wyścig na rynek z nowym produktem. Jeśli uważasz, że możesz uzyskać większość udziału w rynku, nawet przy 15% (lub innej liczbie) niekrytycznych wad, może warto wypuścić produkt, aby uzyskać przewagę nad konkurencją.

Te błędy mogą być dość niewielkie. Pamiętaj, że oprogramowanie komercyjne musi być wysyłane i prasowane na dyskach i tym podobne. Dotrzymanie tych terminów wydania ma poważne konsekwencje finansowe, a opóźnienie w przypadku niektórych drobnych problemów nie ma sensu finansowego - nie wspominając już o potrzebie wejścia na rynek z innych powodów.

Potencjalne odpowiedzi:

• Jest bardzo mało prawdopodobne, aby ktokolwiek napotkał błąd.
• Istnieją obejścia błędów.
• Oprogramowanie trzeba kiedyś wydać, a perfekcji jest mało prawdopodobne.

Jestem pewien, że idealnie większość programistów chciałaby zobaczyć zero błędów w swoich aplikacjach, niestety warunki mogą nie pozwolić na taki stan utopii.

Chciałbym wierzyć, że to dlatego, że baza użytkowników wymaga nowych funkcji i jest gotowa wziąć na pokład te same lub więcej błędów w celu zwiększenia funkcjonalności.

Jeśli zaangażowane jest kierownictwo, terminy muszą zostać dotrzymane z wielu powodów - harmonogramów reklamowych, dodatkowych problemów z dostępnością personelu, sposobu myślenia „musimy być pierwszymi z tą funkcjonalnością”.

Moim zdaniem mniej optymistyczny, może dlatego, że programiści są leniwi?

Pamiętaj także, że w społecznościach typu open source zazwyczaj „kto” chce wziąć pod uwagę żądania błędów / funkcji / problemów - być może nikt nie chce zajmować się problemami, które występują z powodu większych problemów za nimi.

W najprostszym teście programowym:

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

Wszystko jest zawsze kompromisem, czy to naprawianie błędów, czas / przestrzeń / pamięć, czy bezpieczeństwo / użyteczność. Pomyśl o dokonanym obliczeniu kompromisu. Możesz się z tym nie zgodzić, ale masz kłopoty, jeśli go nie rozumiesz.

Pomyśl też o tych obliczeniach w krzywej dzwonowej ... niektórzy ludzie zrobią naprawdę złe po obu stronach. Zobacz Duke Nukem Forever dla jednego końca krzywej.