On 28/03/2015 18:22, Maciej Sobczak wrote:
>
>>> To skąd wiedzą, że dobrze wyspecyfikowały? Mają przeczucie?
>>
>> Stąd, że się na tym znają.
>
> Ale znają się na tym, co sami z tego rozumieją. A specyfikacja jest
> po to, żeby to ich rozumienie przekazać innym (np. programistom). I
> teraz jest problem: skąd taka osoba wie, że dobrze coś
> wyspecyfikowała, skoro jej rozumienie tematu jest niejawnie
> uzupełnione posiadaną wiedzą, której nie wyspecyfikowała, ale tego
> nie zauważyła? To jest powszechne zjawisko.

Zazwyczaj tak, że specyfikuje się w języku naturalnym i różnych innych
nieformalnych notacjach i klaruje się to np. na przykładach, przez
rozmowy, odpowiedzi na pytania, przekazanie szerszego kontekstu - nie
tylko "jak to ma działać" ale i "czemu to ma służyć" i "dlaczego powinno
działać właśnie tak".

>> W praktyce funkcję sort pisze się bardzo rzadko.
>
> W praktyce każdą rzecz pisze się jeszcze rzadziej. Tym bardziej nie
> ma pewności, czy wszyscy wszystko tak samo dobrze rozumieją.

Jest pewność w sensie wystarczająco dużego prawdopodobieństwa.

>> Wtedy da się w praktyce testować - przez co rozumiem osiągnięcie
>> akceptowalnej niezawodności przy akceptowalnych kosztach.
>
> Czyli biznes typu "wicie rozumicie". Jedna wielka szara strefa.

Nie rozumiem o co ci chodzi. Każdy biznes wiąże się z ryzykiem i
praktycznie często tak jest, że jakby się chciało wyeliminować wszelkie
ryzyko (choćby przez ubezpieczanie się od wszystkiego), to koszty tej
eliminacji przewyższą przychody z biznesu.

> Na budowie desek ma być tyle, żeby się nie zawaliło. Czy może być jedna
> mniej, niż ostatnio? Nie wiemy, bo w praktyce niczego nie mierzymy i
> nie wiemy, gdzie jesteśmy z parametrami.

Przecież mierzymy - to właśnie testy są pomiarami.

>> Ale jak najbardziej się nadają, bo testowane programy działają
>> wystarczająco często i per saldo zarabiają.
>
> Tak. Ale skoro już zarabiają, to nie poprzestajmy na tym, tylko
> optymalizujmy. Może mogłyby zarabiać więcej? Problem w tym, że bez
> dokładnej wiedzy o tym co uzyskaliśmy, nie wiadomo, co i jak
> zmienić.

Akurat takie rzeczy się mierzy.

Ale też, żeby np. mieć sposób na zarabianie więcej, czasem musisz
skorzystać z wiedzy kogoś, kto wie, co trzeba zrobić, żeby zarabiać
więcej, ale nie wyrazi ci tego językiem formalnym.

>> Noo chyba że masz matematyczny dowód na to, że metody formalne są
>> opłacalne?
>
> To oczywiście będzie zależało od wielu parametrów, w szczególności od
> tego, jaki jest koszt fakapu. Zwykle jest bardzo mały, więc jedyna
> rzecz, która jest faktycznie opłacalna, to klepanie kodu.

Nie wiem, co rozumiesz przez "bardzo mały". Fakapy na kilka miionów
dolarów nie są niczym niezwykłym, znany jest przypadek Knight Capital,
gdzie błąd techniczny spowodował wysłanie błednych zleceń na giełdę i
stratę około 400 milionów dolarów jeśli dobrze pamiętam.

>> Instytucje finansowe zajmują się zarabianiem pieniędzy
>
> Wszyscy sie tym zajmują. Nie napinajmy się, że instytucje finansowe
> niby mają jedną nóżkę bardziej.

Nic takiego nie mówię, jedynie, że w tym kontekście piszę o realności
strat. Jeśli błędne wysłanie zleceń na giełdę spowoduje np. 2 miliony
dolarów strat, to jest to dwa milony mniej na bilansie firmy i strata
jest jak najbardziej realna. Podobnie, jeśli firma dostanie karę od
regulatora.

>> A straty z błędów są jak najbardziej realne,
>
> Nie będę wybiegał poza tematykę grupy zagłębiając się w tą część
> wątku, bo na pewno bym wybiegł za daleko.

Może jednak? Na dzień dobry, może wyjaśnisz, jeśli firma przez błąd w
swoim oprogramowaniu wyśle na giełdę zleceniaa i straci na tym kasę, to
do kogo może zgłosić reklamację żeby odzyskać te pieniądze?

>> Program jest, coś robi, został napisany w warunkach jakiejś
>> potrzeby i był modyfikowane w warunkach zmieniających się potrzeb.
>> Moje pytanie jaką byś zaproponował metodę działania zamiast tej,
>> która faktycznie została zastosowana i doprowacziła do powstania
>> programu takiego, jaki jest.
>
> W systemie finansowym? Zrobiłbym go dokładnie takimi metodami, jakie
> opisałeś. Byłoby to w zgodzie z:
>
> 1. potencjalnymi kosekwencjami dla mnie w przypadku fakapu 2.
> potencjalnymi korzyściami, np. w postaci wysokich premii 3. mojej
> osobistej opinii nt. realności strat w tym systemie
>
> Serio. Ja też umiem liczyć.

No to policz taki wariant:

Jeśli zrobisz tak, jak opisałem, to dostaniesz normalną pensję, której
co nikt nie zabierze. Jeśli program zarobi pieniądze, dostaniesz jakąś
premię, ale bez szału. Jeśli bugi spowodują, że program straci dużo
kasy, nie dostaniesz premii, a może nawet wylecisz z pracy.

Jeśli wprowadzisz użyjesz metod formalnych i się nie powiedzie, to
również dostaniesz pensję i być może stracisz pracę. Jeśli się powiedzie
wyjątkowo dobrze (gdzie normą jest nie stosowanie metod formalnych), i
co więcej, będziesz potrafił wykazać, że w wielu wypadkach

> A teraz porozmawiajmy o pociągach. Albo windach. Albo sprzęcie
> medycznym. Albo o samochodach, to teraz dosyć popularny temat. Albo o
> czymkolwiek innym, gdzie, jak to mówi przysłowie, programista wiesza
> się razem ze swoim programem, zwłaszcza gdy sam staje się jego
> użytkownikiem.

No i co? Jak sprzęt medyczny czy samochód kogoś zabije, to programista,
etatowy pracownik producenta idzie siedzieć? Koleś od Therac-25 chyba
nie był nawet oskarżony?

>>> Skoro te testy mają mieć efektywność probabilistyczną, to być
>>> może bardziej opłaca się wykupienie polisy ubezpieczeniowej? To
>>> wcale nie jest śmieszne pytanie.
>>
>> Myślę, że nikt ci nie sprzeda takiej polisy.
>
> A ja myślę, że takie polisy będą. Razem z całym systemem wyliczania
> ich wysokości.

OIMW na razie nie ma niczego takiego. Więc nie ma takiej opcji.

Nie wyobrażam sobie zresztą, jak firma ubezpieczniowa miałaby szacować
ryzyko dla takiego programu - z wyjątkiem założenia, że wszystko się
spieprzy w najgorszy możliwy sposób?

>> To jest ryzyko, bo może się okazać, że zanim skończysz dowodzić,
>> skończą się pieniądze albo program przestanie być potrzebny w
>> takiej postaci.
>
> Widziałem też przypadek, kiedy skończyły się pieniądze na testy.

No właśnie o to chodzi, że jeśli po zrobieniu np. 75% testów, które się
zakładało zrobić, skończą się pieniądze, to te 75% testów nadal coś daje.