W dniu 2012-03-13 04:17, A.L. pisze:

> 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)
No to przynajmniej uratowało życie jakimś osobom
'po drugiej stronie' :)

do góry

W dniu 2012-03-15 16:09, Wojciech Jaczewski pisze:
> 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.

I tu jest większy temat. Imo programista może nawet nie za bardzo
ogarniać wyobraźnią skutki swojej pracy, zagrożenia.

Wyobraźmy sobie hipotetycznie, że np. na skutek błędu
wszystkie transakcje kartowe z jednego dnia zaksięgowały się
u jednego człowieka zamiast u rzeczywistych właścicieli kart.
Pechowy właściciel spojrzał na konto, zdążył tylko krzyknąć
'okradli mnie !' i zmarł na zawał :)

To już była pewna skrajność, ale imo podstawa to jednak
organizacja pracy i odpowiedzialność ustawiona 'wysoko'.
Scenariusze testowe, ryzyka - powinni wymyślać ludzie
bliżsi biznesu i rzeczywistości :) niż programiści,
którzy np. jadą procedury wg. specyfikacji i tyle.
Jeśli dopuścimy, że główny ciężar odpowiedzialności
ponoszą specjaliści niskiego szczebla, to będziemy mieć
wybuch za wybuchem, tyle wybuchów, ile fal wchodzenia
na rynek młodych, niedoświadczonych ludzi lub fal imigrantów
z innych rejonów świata.

do góry

On Mar 16, 4:20 pm, zażółcony <r...@c...pl> wrote:
> W dniu 2012-03-15 16:09, Wojciech Jaczewski pisze:
>
> > 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.
>
> I tu jest większy temat. Imo programista może nawet nie za bardzo
> ogarniać wyobraźnią skutki swojej pracy, zagrożenia.
>
> Wyobraźmy sobie hipotetycznie, że np. na skutek błędu
> wszystkie transakcje kartowe z jednego dnia zaksięgowały się
> u jednego człowieka zamiast u rzeczywistych właścicieli kart.
> Pechowy właściciel spojrzał na konto, zdążył tylko krzyknąć
> 'okradli mnie !' i zmarł na zawał :)
>
> To już była pewna skrajność, ale imo podstawa to jednak
> organizacja pracy i odpowiedzialność ustawiona 'wysoko'.
> Scenariusze testowe, ryzyka - powinni wymyślać ludzie
> bliżsi biznesu i rzeczywistości :) niż programiści,
> którzy np. jadą procedury wg. specyfikacji i tyle.

Zgadza się, ale odpowiedzialność programisty polega na tym, żeby
porządnie napisać kod. Jak program będzie miał choćby i najlepiej
wyspecyfikowane wymagania, ale napisany będzie źle, to jego jakość
będzie problematyczna.

Z drugiej strony nie można raczej oczekiwać, że biznes menedżer
sprawdzi, czy w programie nie ma data races albo czy podział na klasy
jest dobry.

> Jeśli dopuścimy, że główny ciężar odpowiedzialności
> ponoszą specjaliści niskiego szczebla, to będziemy mieć
> wybuch za wybuchem, tyle wybuchów, ile fal wchodzenia
> na rynek młodych, niedoświadczonych ludzi lub fal imigrantów
> z innych rejonów świata.

Gdyby jednocześnie z tym dopuszczeniem weszła w życie certyfiacja
zawodowa, to buć może nie będziemy.

do góry

On Fri, 16 Mar 2012 17:07:23 +0100, zażółcony <r...@c...pl>
wrote:

>W dniu 2012-03-13 04:17, A.L. pisze:
>
>> 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)
>No to przynajmniej uratowało życie jakimś osobom
>'po drugiej stronie' :)

Jebnelo cie?...

A.L.

do góry

On 16/03/2012 16:07, zażółcony wrote:
> W dniu 2012-03-13 04:17, A.L. pisze:
>
>> 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)
> No to przynajmniej uratowało życie jakimś osobom
> 'po drugiej stronie' :)

niby że na tej rakiecie która nie została zestrzelona, ktoś sobie
urządził przejażdżkę? Wile E Coyote????



B.

do góry

W dniu 2012-03-02 13:14, Edek Pienkowski pisze:
>>> KISS? Nie wygłupiajmy się. Może właśnie ten kawałek kodu był pisany
>>> >> zgodnie z regułą KISS i w swojej prostocie nie uwzględnił jakiegoś
>>> >> przypadku, bo KISS. Wbrew nazwie KISS jest właśnie dla ludzi głupich.
>> >
>> > KISS oznacza że coś powinno być tak proste, jak to możliwe, ale nie
>> > prostsze. KISS nie oznacza nie uwzględniania tego, co jest niezbędne do
>> > uwzględnienia.
>> > To że system jest prosty nie oznacza że nie został przemyślany.
> W tym przypadku istotniejsze od "proste" jest "bezbłędne".
Dlaczego tylko w tym przypadku? Dlaczego nie w każdym przypadku?

> Brak
> błędów osiąga się często bardzo skomplikowanymi metodami, a nie
> Keep It Simple bo skomplikowanych rzeczy nie rozumiemy. Ok,
> czasami zachowuje się prostotę w jednym miejscu, a wymaga to
> ukrycia skomplikowanej podstawy gdzie indziej.
Coś na siłę ta argumentacja - mam rozumieć, że jak coś jest proste, to
zostało wymyślone przez prostaka (prostego człowieka) - ergo jest
bezwzględnie gorsze i pewnie błędne?
Jak dla mnie to bełkot... Tak samo jak twierdzenie, iż "KISS jest
właśnie dla ludzi głupich".

--
wloochacz

do góry

Dnia Sat, 17 Mar 2012 11:17:57 +0100, wloochacz napisal:

> W dniu 2012-03-02 13:14, Edek Pienkowski pisze:
>>>> KISS? Nie wygłupiajmy się. Może właśnie ten kawałek kodu był pisany
>>>> >> zgodnie z regułą KISS i w swojej prostocie nie uwzględnił
>>>> >> jakiegoś przypadku, bo KISS. Wbrew nazwie KISS jest właśnie dla
>>>> >> ludzi głupich.
>>> >
>>> > KISS oznacza że coś powinno być tak proste, jak to możliwe, ale nie
>>> > prostsze. KISS nie oznacza nie uwzględniania tego, co jest
>>> > niezbędne do uwzględnienia.
>>> > To że system jest prosty nie oznacza że nie został przemyślany.
>> W tym przypadku istotniejsze od "proste" jest "bezbłędne".
> Dlaczego tylko w tym przypadku? Dlaczego nie w każdym przypadku?

Gdy mowa o konsekwencjach błędów w rodzaju ludzkiego zdrowia i życia,
to bezbłędność jest najważniejsza. Czasem ważniejszy jest czas i ilość
ficzerów, np. oprogramowania do blogowania czy CRM, wtedy prostota
pomaga uzyskać szybciej dobre wyniki. Bezbłędność i czas wykonania
to tradeoff, czy to się akceptuje czy nie. Jak chce się sprzedać
system z SLA 99,999% to nagle okazuje się, że nie wszystkie
organizacje są w stanie coś takiego stworzyć, bo to nie takie proste.

>
>> Brak błędów osiąga się często bardzo skomplikowanymi metodami, a nie
>> Keep It Simple bo skomplikowanych rzeczy nie rozumiemy. Ok,
>> czasami zachowuje się prostotę w jednym miejscu, a wymaga to ukrycia
>> skomplikowanej podstawy gdzie indziej.
> Coś na siłę ta argumentacja - mam rozumieć, że jak coś jest proste, to
> zostało wymyślone przez prostaka (prostego człowieka) - ergo jest
> bezwzględnie gorsze i pewnie błędne?

Na siłę to Ty obracasz kota ogonem. Nie wiem, czy chciałbyś -
odpukać, nikomu nie życzę nic złego -
być pod respiratorem z następującym certyfikatem:
"Certyfikat normy EU-53246732: 10 naszych programistów przez 10
dni patrzyło się na nasz kod napisany zgodnie z zasadą KISS i nie
zauważyło błędu.". Bo do tego sprowadza się KISS.

Ja jedynie argumentuję, że proste nie zawsze jest lepsze, odwrotny
argument to już Ty stworzyłeś - nie chciałem nikogo urazić. Mnie
po prostu wpienia to, jak większość programistów stosuje KISS,
gubiąc połowę szczegółów najczęściej i potem nie chce działać.
No, ale jest proste.

> Jak dla mnie to bełkot... Tak samo jak twierdzenie, iż "KISS jest
> właśnie dla ludzi głupich".

KISS to bełkot. Niestety masa programistów postępuje mniej więcej tak,
że wątki są skomplikowane, boost jest skomplikowany, w ogóle
po co skomplikowane rozwiązania, nie musżę się uczyć i powiem,
że KISS! Alleluja i do przodu.

Edek

do góry

Edek Pienkowski wrote:

> jak większość programistów stosuje KISS,
> gubiąc połowę szczegółów najczęściej i potem nie chce działać.
> No, ale jest proste.

Wg mnie, szczegóły to gubią właśnie ci, którzy stosują rozwiązania
skomplikowane. Nawymyślają sobie jakiś przerost formy nad treścią (czy to
przez nadużywanie technik obiektowych, czy przez nadużywanie szablonów),
przez co na szczegóły zabraknie już czasu.

> KISS to bełkot. Niestety masa programistów postępuje mniej więcej tak,
> że wątki są skomplikowane, boost jest skomplikowany, w ogóle
> po co skomplikowane rozwiązania, nie musżę się uczyć i powiem,
> że KISS! Alleluja i do przodu.

Prostych rozwiązań należy używać tam, gdzie są. Skomplikowanych - wyłącznie
tam, gdzie nie ma prostych.
Wymienione wyżej wątki: jeśli ktoś ich używa tam, gdzie spokojnie poradziłby
sobie program jednowątkowy, to szuka sobie (a często i nie sobie, tylko
pozostałym współpracownikom) kłopotów. Nie chodzi o to, żeby tych rozwiązań
się nie uczyć, tylko aby jedynym powodem ich używania nie było to, że akurat
poświęciłem ileś czasu na ich naukę - i koniecznie tę wiedzę muszę
natychmiast wykorzystać.

do góry

On Saturday, March 17, 2012 3:12:00 PM UTC, Wojciech Jaczewski wrote:

> Prostych rozwiązań należy używać tam, gdzie są. Skomplikowanych - wyłącznie
> tam, gdzie nie ma prostych.
> Wymienione wyżej wątki: jeśli ktoś ich używa tam, gdzie spokojnie poradziłby
> sobie program jednowątkowy, to szuka sobie (a często i nie sobie, tylko
> pozostałym współpracownikom) kłopotów. Nie chodzi o to, żeby tych rozwiązań
> się nie uczyć, tylko aby jedynym powodem ich używania nie było to, że akurat
> poświęciłem ileś czasu na ich naukę - i koniecznie tę wiedzę muszę
> natychmiast wykorzystać.

O to to. Pracuje nad biblioteka C++ ktorej oryginalni autorzy (ktorzy juz odeszli z
firmy) nawsadzali szablony gdzie tylko sie dalo. Kod budowal sie niemilosiernie
dlugo, debugowanie go trwalo wiecznosci bo debugger musial sie przebic przez stosy
roznych wersji szablonow, a kod wcale nie byl znaczaco szybszy od wersji ktora go
zastapilismy - uzywajacej zwyklego polimorfizmu na funkcjach wirtualnych.

RW

do góry

Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał w
wiadomości
news:f2db5697-6646-4eff-a45c-ac6004221d77@hv2g2000vb
b.googlegroups.com...
On Mar 16, 4:20 pm, zażółcony <r...@c...pl> wrote:
> W dniu 2012-03-15 16:09, Wojciech Jaczewski pisze:
>
> > > Andrzej Jarzabek wrote:
> >
> > [...]
>
> > Jeśli dopuścimy, że główny ciężar odpowiedzialności
> > ponoszą specjaliści niskiego szczebla, to będziemy mieć
> > wybuch za wybuchem, tyle wybuchów, ile fal wchodzenia
> > na rynek młodych, niedoświadczonych ludzi lub fal imigrantów
> > z innych rejonów świata.
>
> Gdyby jednocześnie z tym dopuszczeniem weszła w życie certyfiacja
> zawodowa, to buć może nie będziemy.

Certyfikacja zawodowa?


tx.

do góry