On 12/03/2012 09:45, j...@...com wrote:
> Z kilku informacji medialnych, ktore do mnie dotarly o Airbusie
> Brazylia-Paryż, wynika ze rowniez oprogramowanei zawiodlo, jakby nie
> dalo sie obejsc awarii (oblodzenia) czujnika Pito inaczej jak
> resetujac komputer. Gdyby tak bylo, to fatalny blad projektowy.

w tamtym przypadku piloci mogli uratować samolot, gdyby tylko potrafili
rozpoznać przeciągnięcie samolotu (stall), do tego czujnik prędkości nie
jest niezbędny :(


B.

do góry

> Z kilku informacji medialnych, ktore do mnie dotarly o Airbusie
> Brazylia-Paryż, wynika ze rowniez oprogramowanei zawiodlo, jakby nie

transkrypcja z kokpitu:

http://www.popularmechanics.com/technology/aviation/
crashes/what-really-happened-aboard-air-france-447-6
611877

PL

do góry

On Mon, 12 Mar 2012 02:45:01 -0700 (PDT), "j...@...com"
<j...@g...com> wrote:

>On 5 Mar, 11:14, " M.M." <m...@g...SKASUJ-TO.pl> wrote:
>> Roman W <b...@g...pl> napisał(a):
>>
>> Przy systemach zwiazanych bezposrednio z ludzkim zyciem pracowalem, ale
>> nie jako programista, ani nawet informatyk i wiem co sie dzialo... Jako
>> informatyk pracowalem przy systemach ktore zabic nie mogly, ale wybic
>> zeby albo zlamac reke jak najbardziej tak. Nikt sie tym nie przejmowal.
>> Termin sie zbliza, trzeba zainstalowac, co z tego ze jeszcze jest
>> niedokonczone. Czyli byla instalacja czegos o czym z gory wiedziano ze
>> moze byc niebezpieczne.
>>
>
>Z kilku informacji medialnych, ktore do mnie dotarly o Airbusie
>Brazylia-Paryż, wynika ze rowniez oprogramowanei zawiodlo, jakby nie
>dalo sie obejsc awarii (oblodzenia) czujnika Pito inaczej jak
>resetujac komputer. Gdyby tak bylo, to fatalny blad projektowy.
>Zastrzegam, oczywiscie nie wiem wszystkiego a nawet bardzo niewiele.


To jest informacja o tym jak francuska rakieta Ariane 5 wybuchla
wkrotce po starcie na skutek bledu oprogramowania

http://www.di.unito.it/~damiani/ariane5rep.html
http://www.around.com/ariane.html

A tu jest informacja o uzradzenie medycnym Therac-25 ktore zabilo
kilka osob

http://courses.cs.vt.edu/cs3604/lib/Therac_25/Therac
_1.html

Oba przypadk isa "kalsyczne" i byla szeroka dyskusja na ich temat,
wiecej mozna znalezc w googlu

A.L.

do góry

On Mon, 12 Mar 2012 02:45:01 -0700 (PDT), "j...@...com"
<j...@g...com> wrote:

>On 5 Mar, 11:14, " M.M." <m...@g...SKASUJ-TO.pl> wrote:
>> Roman W <b...@g...pl> napisał(a):
>>
>> Przy systemach zwiazanych bezposrednio z ludzkim zyciem pracowalem, ale
>> nie jako programista, ani nawet informatyk i wiem co sie dzialo... Jako
>> informatyk pracowalem przy systemach ktore zabic nie mogly, ale wybic
>> zeby albo zlamac reke jak najbardziej tak. Nikt sie tym nie przejmowal.
>> Termin sie zbliza, trzeba zainstalowac, co z tego ze jeszcze jest
>> niedokonczone. Czyli byla instalacja czegos o czym z gory wiedziano ze
>> moze byc niebezpieczne.
>>
>
>Z kilku informacji medialnych, ktore do mnie dotarly o Airbusie
>Brazylia-Paryż, wynika ze rowniez oprogramowanei zawiodlo, jakby nie
>dalo sie obejsc awarii (oblodzenia) czujnika Pito inaczej jak
>resetujac komputer. Gdyby tak bylo, to fatalny blad projektowy.
>Zastrzegam, oczywiscie nie wiem wszystkiego a nawet bardzo niewiele.


Tak ejszcze kontynuujac, blad w oprogramowaniu spowodowal ze
amerykanskie pociski antyrakietowe Patriot w 98% przypadkow chybialy
celu, co bylo bezposrednim powodem smeirci 30 zolnierzy amerykanskich
podczas pierwszej wojny perskiej (okolo 100 bylo rannych)

http://sydney.edu.au/engineering/it/~alum/patriot_bu
g.html
http://www.cs.utexas.edu/~downing/papers/PatriotB199
2.pdf

Zle postawiony znak w programie napisanym w Fortranie IV byl powodem
utraty Marinera-1, pierwszej amerykanskiej soncy wyslanej na Wenus

http://en.wikipedia.org/wiki/Mariner_1

NASA stracila sonde wyslana na Marsa na skutek bledu w tlumaczeniu
amerykanskich jednostek miar na metryczne

http://sunnyday.mit.edu/accidents/mco-oberg.htm

Pierwszy marsjanski lazik ("rover") prawie zostal starcony na skutek
bledu w programowaniu wielowatkowym - biedacy programisci nei
wiedzieli co to jest "priority inversion"

http://research.microsoft.com/en-us/um/people/mbj/ma
rs_pathfinder/mars_pathfinder.html

Lista "software horrors" jest tutaj

http://www.cs.tau.ac.il/~nachumd/horror.html

Jest dosyc ciekawa ksiazka na temat "ciezkich w skutkach" bledow
oprogramowania: Fatal Defect: Chasing Killer Computer Bugs, Ivars
Peterson, 1996

A.L.

do góry

M.M. wrote:

> a za niezawodnosc powinien reczyc ten ktory bedzie potem
> czerpal zyski z produktu.

Zdecydowanie nie!
Ten, który będzie czerpał zyski z produktu, ma pełne prawo nie rozumieć
szczegółów działania sprzedawanych przez jego firmę produktów. Powinien być
człowiek odpowiedzialny za produkt - ktokolwiek by nim nie był - czy ten
czerpiący większość zysków, czy jakiś główny inżynier - i to on powinien być
odpowiedzialny (i ewentualnie drabinka podległych mu ludzi - w danym
przypadku sąd mógłby orzec, że tu czy tu, to akurat oczywista wina
podległego mu pracownika, a nie głównego inżyniera).

To także pracownicy mający pojęcie o tym, co firma produkuje, są
odpowiedzialni za jakość: gdyby wszyscy się zwolnili, bo management nie
pozwala robić bezpiecznych produktów, to dość szybko firma by musiała zostać
zlikwidowana.

A tak, to niestety jest powszechna akceptacja współudziału w tworzeniu
chłamu. Usprawiedliwia się ludzi: "nie ma na to wpływu", "taką ma pracę",...

do góry

On 13 Mar, 12:44, Wojciech Jaczewski <w...@o...pl> wrote:

> gdyby wszyscy się zwolnili, bo management nie
> pozwala robić bezpiecznych produktów,

I gdzie by poszli? Do innej firmy, która *też* nie pozwala? To jest
właśnie powód, dla którego nie odejdą.

> Usprawiedliwia się ludzi: "nie ma na to wpływu",

A ma wpływ?

Jaki masz wpływ na procedury zapewniania jakości u siebie w pracy?

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

Maciej Sobczak wrote:

> On 13 Mar, 12:44, Wojciech Jaczewski <w...@o...pl> wrote:
>
>> gdyby wszyscy się zwolnili, bo management nie
>> pozwala robić bezpiecznych produktów,
>
> I gdzie by poszli? Do innej firmy, która *też* nie pozwala? To jest
> właśnie powód, dla którego nie odejdą.

Nie odejdą, bo boją się zmian. Albo nie odejdą, bo za bardzo cenią sobie
pieniądze, których po odejściu prawdopodobnie zarobią mniej.

>> Usprawiedliwia się ludzi: "nie ma na to wpływu",
>
> A ma wpływ?

To jest obojętne, czy ma wpływ czy go nie ma. Skoro wie jak firma
funkcjonuje, nie próbuje tego zmienić, a po ewentualnym ocenieniu że nie ma
wpływu - nie zwalnia się - to znaczy, że akceptuje ten model funkcjonowania.
I to, że nie miał wpływu, nie jest żadnym usprawiedliwieniem.

W sumie może niepotrzebnie w ogóle na ten temat napisałem, bo jest to poza
tematyką tej grupy... Kwestia priorytetów, którymi kierujemy się w życiu.
Dla jednego zasady będą ważniejsze niż własne życie, dla drugiego nie ma
żadnych zasad, byle tylko żyło się jak najprzyjemniej, dla większości -
różne punkty pomiędzy tymi dwoma skrajnościami.

do góry

On 14/03/2012 16:26, Wojciech Jaczewski wrote:
>>
>>> gdyby wszyscy się zwolnili, bo management nie
>>> pozwala robić bezpiecznych produktów,
>>
>> I gdzie by poszli? Do innej firmy, która *też* nie pozwala? To jest
>> właśnie powód, dla którego nie odejdą.
>
> Nie odejdą, bo boją się zmian. Albo nie odejdą, bo za bardzo cenią sobie
> pieniądze, których po odejściu prawdopodobnie zarobią mniej.

Niekoniecznie przecież. Ja bym się raczej spodziewał, że wielu ludzi nie
odchodzi, bo nie mają odpowiednich umiejętności lub po prostu nie zdają
sobie sprawy na czym polega inne podejście.

Na dzień dobry przecież nie ma w tym nic nieracjonalnego: jeśli
popełniasz błędy, przez te błędy produkt, który wytwarzasz ma defekty,
ale pracodawca jest "wyrozumiały" i nie szykanuje cię na ogół żadnymi
konsekwencjami z tego powodu, to dlaczego chciałbyś zmienić pracę na
taką, gdzie wiesz, że kładą duży nacisk na to, żeby defektów nie było?

No i oczywiście przy decyzji o wyborze czy zmiany pracy mają znaczenie
też czynniki powiedzmy pozamerytoryczne: lokalizacja, godziny, względy
towarzyskie i tak dalej.

Oczywiście można też podejść do sprawy pryncypialnie, zgodnie z radą
Martina Fowlera "if you can't change your organisation, change your
organisation". Możliwości, wydaje się, istnieją, i też wydaje mi się, że
ludzie, którzy tak działają, często wychodzą na tym dobrze - kwestia czy
się jest ewentualnie skłonnym do pewnych poświęceń żeby to osiągnąć.

>>> Usprawiedliwia się ludzi: "nie ma na to wpływu",
>>
>> A ma wpływ?
>
> To jest obojętne, czy ma wpływ czy go nie ma. Skoro wie jak firma
> funkcjonuje, nie próbuje tego zmienić, a po ewentualnym ocenieniu że nie ma
> wpływu - nie zwalnia się - to znaczy, że akceptuje ten model funkcjonowania.
> I to, że nie miał wpływu, nie jest żadnym usprawiedliwieniem.

W takim modelu, gdzie za jakość produktu odpowiada wyłącznie
przedsiębiorca, nie ma się nawet z czego usprawiedliwiać.

Oczywiście z drugiej strony prawda jest taka, że programista ma zawsze
jakiśtam wpływ na jakość prroduktu - nawet jeśli ten wpływ jest
niewielki, to z punktu widzenia powiedzmy etyki zawodowej jest OK jeśli
produkujesz dobry kod i poprawiasz błędy w napotkanym złym kodzie, jeśli
tylko tyle możesz zrobić. Nawet jeśli twój wpływ na ostateczną jakość
produktu jest niewielki, to ostatecznie lepiej zrobić tyle, ile można
zrobić, niż nie zrobić nic.

Dodatkowo łatwo nie docenić swojego faktycznego wpływu na organizację:
nawet jeśli się nie ma możliwości zarządzania zmian, to nie znaczy, że
inni nie widzą co robisz i nie ma to na nich wpływu - czasem przecież
będzie tak, że wielu osobom faktycznie przeszkadza to, że odwalają
kaszanę, ale wpadają w groupthink "nie ma czasu zrobić porządnie, bo
termin" - w takim przypadku nawet jedna osoba, która się wyłamie, może
dać przykład innym.

> W sumie może niepotrzebnie w ogóle na ten temat napisałem, bo jest to poza
> tematyką tej grupy... Kwestia priorytetów, którymi kierujemy się w życiu.
> Dla jednego zasady będą ważniejsze niż własne życie, dla drugiego nie ma
> żadnych zasad, byle tylko żyło się jak najprzyjemniej, dla większości -
> różne punkty pomiędzy tymi dwoma skrajnościami.

Według mnie jak najbardziej w tematyce grupy.
Filmik do obejrzenia i przemyślenia w tym temacie:
http://www.infoq.com/presentations/Robert-C.-Martin-
Bad-Code

do góry

Andrzej Jarzabek wrote:

> Oczywiście z drugiej strony prawda jest taka, że programista ma zawsze
> jakiśtam wpływ na jakość prroduktu

W przypadku produktów czysto programistycznych jest chyba trochę łatwiej
mieć wpływ.
Jeśli ktoś postanowił zaoszczędzić np. nie montując w urządzeniu jakiegoś
potrzebnego w szczególnych przypadkach czujnika, to choćby programista się
nie wiem jak wykazywał, to programowo problemu sprzętowego nie rozwiąże.

Niemniej uważam, że i w tym przypadku programista jest współodpowiedzialny,
jeśli rozumie konsekwencje tych decyzji i nie reaguje.

do góry

On Mar 15, 3:09 pm, Wojciech Jaczewski <w...@o...pl> wrote:
> Andrzej Jarzabek wrote:
> > Oczywiście z drugiej strony prawda jest taka, że programista ma zawsze
> > jakiśtam wpływ na jakość prroduktu
>
> W przypadku produktów czysto programistycznych jest chyba trochę łatwiej
> mieć wpływ.
> Jeśli ktoś postanowił zaoszczędzić np. nie montując w urządzeniu jakiegoś
> potrzebnego w szczególnych przypadkach czujnika, to choćby programista się
> nie wiem jak wykazywał, to programowo problemu sprzętowego nie rozwiąże.

Oj, nie chodiło przecież o to, że programista może skontrolować
wszystko i poprawić wszystko, co jest źle - w przypadku większych
produktów czysto programistycznych jest to też praktycznie niemożliwe.
Chodziło o to, że programista może zrobić swoją robotę dobrze, albo
może ją zrobić niedobrze, a jako bonus być może jeszcze może podczas
robioenia swojej roboty zauważyć zły kod i go poprawić - robiąc to ma
wpływ na jakość produktu, bo jak zrobi niedobrze, to albo bezpośrednio
obniży jakość (wprowadzi buga), albo przynajmniej ułatwi obniżenie
jakości (napisze kod, do którego łatwo będzie wprowadzić buga) lub
utrudni jej podniesienie (napisze kod, do którego trudno będzie dodać
nowe ficzery).

Ostatecznie chodziło mi o to, że defetyzm na zasadzie "co za różnica,
czy zrobię dobrze czy niedobrze, skoro i tak wszystcy inni robią
niedobrze" jest nieuzasadniony - prkatycznie każdy programista, który
robi dobrze lub niedobrze ma jakiśtam wpływ (nawet jeśli ten wpływ nie
jest zbyt wielki) na ostateczną jakość produktu. To, czy dobrym
pomysłem jest pozostawanie w organizacji wytwarzającej produkty
niskiej jakości, jest osobną kwestią, ale jeśli z jakiegokolwiek
powodu postanawia się w takiej organizacji pozostawać, to etycznie
jest przynajmniej robić dobrze na swoim odcinku.

do góry