On Friday, August 10, 2012 8:32:36 AM UTC+1, Paweł Kierski wrote:
> W dniu 2012-08-09 19:34, Andrzej Jarzabek pisze:
>
> > On 09/08/2012 12:23, Roman W wrote:
>
> >>
>
> >> Procesem nie podniesie sie umiejetnosci deweloperow, ale moze da sie
>
> >> uniknac tego:
>
> >>
>
> >> http://www.nanex.net/aqck2/3525.html
>
> >>
>
> >> "We believe Knight accidentally released the test software they used
>
> >> to verify that their new market making software functioned properly,
>
> >> into NYSE's live system."
>
> >
>
> > Teoretycznie tak, ale równie dużą masz szansę na to, że sama procedura
>
> > "urzędowego testowania" spowoduje w pewnym momencie błąd polegający na
>
> > wpuszczeniu testowych programów lub danych do produkcji.
>
>
>
> Jeszcze jeden możliwy scenariusz - "urzędowe testowanie" zmniejszy
>
> ciśnienie na testowanie własne. Skoro celem będzie nie bezbłędne
>
> oprogramowanie, a oprogramowanie zgodne z urzędowymi testami, to takie
>
> będzie produkowane.

Bezbledne oprogramowanie nigdy nie bylo celem, wiec ten scenariusz mozemy spokojnie
wykluczyc.

RW

do góry

W dniu 2012-08-10 09:42, Roman W pisze:
> On Friday, August 10, 2012 8:32:36 AM UTC+1, Paweł Kierski wrote:
>> W dniu 2012-08-09 19:34, Andrzej Jarzabek pisze:
>>
>>> On 09/08/2012 12:23, Roman W wrote:
>>
>>>>
>>
>>>> Procesem nie podniesie sie umiejetnosci deweloperow, ale moze da sie
>>
>>>> uniknac tego:
>>
>>>>
>>
>>>> http://www.nanex.net/aqck2/3525.html
>>
>>>>
>>
>>>> "We believe Knight accidentally released the test software they used
>>
>>>> to verify that their new market making software functioned properly,
>>
>>>> into NYSE's live system."
>>
>>>
>>
>>> Teoretycznie tak, ale równie dużą masz szansę na to, że sama procedura
>>
>>> "urzędowego testowania" spowoduje w pewnym momencie błąd polegający na
>>
>>> wpuszczeniu testowych programów lub danych do produkcji.
>>
>>
>>
>> Jeszcze jeden możliwy scenariusz - "urzędowe testowanie" zmniejszy
>>
>> ciśnienie na testowanie własne. Skoro celem będzie nie bezbłędne
>>
>> oprogramowanie, a oprogramowanie zgodne z urzędowymi testami, to takie
>>
>> będzie produkowane.
>
> Bezbledne oprogramowanie nigdy nie bylo celem, wiec ten scenariusz mozemy spokojnie
wykluczyc.

Nie o to mi chodziło. Jeśli tworzę oprogramowanie, to staram się je
testować w tych kierunkach, w których spodziewam się problemów. Jeśli
dokładam nowy ficzer, to mniej więcej wiem, co się może stać, jakie nowe
przypadki wygeneruje. I na tym się skupiam. Jeśli mam narzucone z góry
testy "urzędowe", to spełnieniem tych testów głównie się zajmę. Jeśli
zabraknie mi czasu (a zawsze brakuje), to wiadomo, z czego będę
rezygnował.

--
Paweł Kierski
n...@p...net

do góry

On Fri, 10 Aug 2012 09:32:36 +0200, Paweł Kierski <n...@p...net>
wrote:

>W dniu 2012-08-09 19:34, Andrzej Jarzabek pisze:
>> On 09/08/2012 12:23, Roman W wrote:
>>>
>>> Procesem nie podniesie sie umiejetnosci deweloperow, ale moze da sie
>>> uniknac tego:
>>>
>>> http://www.nanex.net/aqck2/3525.html
>>>
>>> "We believe Knight accidentally released the test software they used
>>> to verify that their new market making software functioned properly,
>>> into NYSE's live system."
>>
>> Teoretycznie tak, ale równie dużą masz szansę na to, że sama procedura
>> "urzędowego testowania" spowoduje w pewnym momencie błąd polegający na
>> wpuszczeniu testowych programów lub danych do produkcji.
>
>Jeszcze jeden możliwy scenariusz - "urzędowe testowanie" zmniejszy
>ciśnienie na testowanie własne. Skoro celem będzie nie bezbłędne
>oprogramowanie, a

Nie ma bezblednego oprogramowania ani metod pozwalajacych stwierdzic
ze oprogramowanie jest bezbledne (pomijajakc oczywiscie PROSTE
programy 5 linijkowe)

A.L.

do góry

On Friday, August 10, 2012 9:07:18 AM UTC+1, Paweł Kierski wrote:
> W dniu 2012-08-10 09:42, Roman W pisze:
>
> > On Friday, August 10, 2012 8:32:36 AM UTC+1, Paweł Kierski wrote:
>
> >> W dniu 2012-08-09 19:34, Andrzej Jarzabek pisze:
>
> >>
>
> >>> On 09/08/2012 12:23, Roman W wrote:
>
> >>
>
> >>>>
>
> >>
>
> >>>> Procesem nie podniesie sie umiejetnosci deweloperow, ale moze da sie
>
> >>
>
> >>>> uniknac tego:
>
> >>
>
> >>>>
>
> >>
>
> >>>> http://www.nanex.net/aqck2/3525.html
>
> >>
>
> >>>>
>
> >>
>
> >>>> "We believe Knight accidentally released the test software they used
>
> >>
>
> >>>> to verify that their new market making software functioned properly,
>
> >>
>
> >>>> into NYSE's live system."
>
> >>
>
> >>>
>
> >>
>
> >>> Teoretycznie tak, ale równie dużą masz szansę na to, że sama procedura
>
> >>
>
> >>> "urzędowego testowania" spowoduje w pewnym momencie błąd polegający na
>
> >>
>
> >>> wpuszczeniu testowych programów lub danych do produkcji.
>
> >>
>
> >>
>
> >>
>
> >> Jeszcze jeden możliwy scenariusz - "urzędowe testowanie" zmniejszy
>
> >>
>
> >> ciśnienie na testowanie własne. Skoro celem będzie nie bezbłędne
>
> >>
>
> >> oprogramowanie, a oprogramowanie zgodne z urzędowymi testami, to takie
>
> >>
>
> >> będzie produkowane.
>
> >
>
> > Bezbledne oprogramowanie nigdy nie bylo celem, wiec ten scenariusz mozemy
spokojnie wykluczyc.
>
>
>
> Nie o to mi chodziło. Jeśli tworzę oprogramowanie, to staram się je
>
> testować w tych kierunkach, w których spodziewam się problemów. Jeśli
>
> dokładam nowy ficzer, to mniej więcej wiem, co się może stać, jakie nowe
>
> przypadki wygeneruje. I na tym się skupiam.

No i tu jest pierwsze bledne zalozenie. Doswiadczenie pokazalo, ze ludzie budujacy
systemy do handlu na gieldzie czesto nie przewidywali, albo lekcewazyli mozliwosc
zajscia problemow ktore maja niskie prawdopodobienstwo zajscia, ale jak juz zajda, to
sa drastyczne w skutkach. Niekoniecznie dlatego ze sa glupi, ale dlatego, ze korzysci
krotkoterminowe przeslaniaja im dlugoterminowe zagrozenia.

Inaczej mowiac: postaw sobie kolesia, ktory pisze taki system dla firmy Knight.
Jezeli system zadziala, koles dostanie duzego tlustego bonusa. Jezeli system nie
zadziala, kara nie bedzie symetryczna do nagrody -- worst case, koles straci prace i
bedzie mial "ciekawa historie" do opowiedzenia. Nawet jezeli straty beda siegaly w
setki milionow dolarow. Zewnetrzne regulacje musza poprawic asymetrie motywacji.

> Jeśli mam narzucone z góry
>
> testy "urzędowe", to spełnieniem tych testów głównie się zajmę. Jeśli
>
> zabraknie mi czasu (a zawsze brakuje), to wiadomo, z czego będę
>
> rezygnował.

Jezeli korzysci z systemu nie sa dostatecznie duze, zeby Ciebie zmotywowac do
wlozenia dodatkowego wysilku w zrobienie i testow, i funkcjonalnosci, to widac nowa
funkcjonalnosc nie byla warta ryzyka.

Ja bm sie bal czego innego, ze testy "urzedowe" zastapia wewnetrzne, zamiast je
uzupelniac. "Jestemy kryci, spelniamy wymagania Basel III" -- LOL :)

RW

do góry

W dniu 2012-08-12 21:22, Roman W pisze:
> On Friday, August 10, 2012 9:07:18 AM UTC+1, Paweł Kierski wrote:
>> W dniu 2012-08-10 09:42, Roman W pisze:
>>
>>> On Friday, August 10, 2012 8:32:36 AM UTC+1, Paweł Kierski wrote:
>>
>>>> W dniu 2012-08-09 19:34, Andrzej Jarzabek pisze:
>>
>>>>
>>
>>>>> On 09/08/2012 12:23, Roman W wrote:
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>> Procesem nie podniesie sie umiejetnosci deweloperow, ale moze da sie
>>
>>>>
>>
>>>>>> uniknac tego:
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>> http://www.nanex.net/aqck2/3525.html
>>
>>>>
>>
>>>>>>
>>
>>>>
>>
>>>>>> "We believe Knight accidentally released the test software they used
>>
>>>>
>>
>>>>>> to verify that their new market making software functioned properly,
>>
>>>>
>>
>>>>>> into NYSE's live system."
>>
>>>>
>>
>>>>>
>>
>>>>
>>
>>>>> Teoretycznie tak, ale równie dużą masz szansę na to, że sama procedura
>>
>>>>
>>
>>>>> "urzędowego testowania" spowoduje w pewnym momencie błąd polegający na
>>
>>>>
>>
>>>>> wpuszczeniu testowych programów lub danych do produkcji.
>>
>>>>
>>
>>>>
>>
>>>>
>>
>>>> Jeszcze jeden możliwy scenariusz - "urzędowe testowanie" zmniejszy
>>
>>>>
>>
>>>> ciśnienie na testowanie własne. Skoro celem będzie nie bezbłędne
>>
>>>>
>>
>>>> oprogramowanie, a oprogramowanie zgodne z urzędowymi testami, to takie
>>
>>>>
>>
>>>> będzie produkowane.
>>
>>>
>>
>>> Bezbledne oprogramowanie nigdy nie bylo celem, wiec ten scenariusz mozemy
spokojnie wykluczyc.
>>
>>
>>
>> Nie o to mi chodziło. Jeśli tworzę oprogramowanie, to staram się je
>>
>> testować w tych kierunkach, w których spodziewam się problemów. Jeśli
>>
>> dokładam nowy ficzer, to mniej więcej wiem, co się może stać, jakie nowe
>>
>> przypadki wygeneruje. I na tym się skupiam.
>
> No i tu jest pierwsze bledne zalozenie. Doswiadczenie pokazalo, ze ludzie budujacy
systemy do handlu na gieldzie czesto nie przewidywali, albo lekcewazyli mozliwosc
zajscia problemow ktore maja niskie prawdopodobienstwo zajscia, ale jak juz zajda, to
sa drastyczne w skutkach. Niekoniecznie dlatego ze sa glupi, ale dlatego, ze korzysci
krotkoterminowe przeslaniaja im dlugoterminowe zagrozenia.
>
> Inaczej mowiac: postaw sobie kolesia, ktory pisze taki system dla firmy Knight.
Jezeli system zadziala, koles dostanie duzego tlustego bonusa. Jezeli system nie
zadziala, kara nie bedzie symetryczna do nagrody -- worst case, koles straci prace i
bedzie mial "ciekawa historie" do opowiedzenia. Nawet jezeli straty beda siegaly w
setki milionow dolarow. Zewnetrzne regulacje musza poprawic asymetrie motywacji.

Jest tu jedno milczące założenie - testy "urzędowe" są dobre, a może
i lepsze w pewnych zakresach od "zwykłych". Owszem, mogą być czasem,
ale umówmy się - gdyby kolesie piszący testy dla "urzędu" byli naprawdę
tak dobrzy, to raczej by w tym "urzędzie" nie pracowali. W Polsce to
w tej chwili pewnik, może A.L. wypowie się USA, ale podejrzewam, że też
to w taką stronę idzie.

>> Jeśli mam narzucone z góry
>>
>> testy "urzędowe", to spełnieniem tych testów głównie się zajmę. Jeśli
>>
>> zabraknie mi czasu (a zawsze brakuje), to wiadomo, z czego będę
>>
>> rezygnował.
>
> Jezeli korzysci z systemu nie sa dostatecznie duze, zeby Ciebie zmotywowac do
wlozenia dodatkowego wysilku w zrobienie i testow, i funkcjonalnosci, to widac nowa
funkcjonalnosc nie byla warta ryzyka.
>
> Ja bm sie bal czego innego, ze testy "urzedowe" zastapia wewnetrzne, zamiast je
uzupelniac. "Jestemy kryci, spelniamy wymagania Basel III" -- LOL :)

Innymi słowy, ale właśnie to miałem na myśli. Stopniowo "urzędowe"
będzie zastępować zdrowy rozsądek. Stopień pokrycia testami w sumie
raczej spadnie niż wzrośnie.

--
Paweł Kierski
n...@p...net

do góry

W dniu 2012-08-10 14:39, A.L. pisze:
> On Fri, 10 Aug 2012 09:32:36 +0200, Paweł Kierski<n...@p...net>
> wrote:
>
>> W dniu 2012-08-09 19:34, Andrzej Jarzabek pisze:
>>> On 09/08/2012 12:23, Roman W wrote:
>>>>
>>>> Procesem nie podniesie sie umiejetnosci deweloperow, ale moze da sie
>>>> uniknac tego:
>>>>
>>>> http://www.nanex.net/aqck2/3525.html
>>>>
>>>> "We believe Knight accidentally released the test software they used
>>>> to verify that their new market making software functioned properly,
>>>> into NYSE's live system."
>>>
>>> Teoretycznie tak, ale równie dużą masz szansę na to, że sama procedura
>>> "urzędowego testowania" spowoduje w pewnym momencie błąd polegający na
>>> wpuszczeniu testowych programów lub danych do produkcji.
>>
>> Jeszcze jeden możliwy scenariusz - "urzędowe testowanie" zmniejszy
>> ciśnienie na testowanie własne. Skoro celem będzie nie bezbłędne
>> oprogramowanie, a
>
> Nie ma bezblednego oprogramowania ani metod pozwalajacych stwierdzic
> ze oprogramowanie jest bezbledne (pomijajakc oczywiscie PROSTE
> programy 5 linijkowe)

No i pytanie - w czym "urzędowe" testy będą lepsze? Czy zwiększą
pokrycie - zmniejszą liczbę błędów? Z chęcią zobaczyłbym argument
inny niż "bo będzie ich w sumie więcej", albo "urząd/państwo lepiej
się zna".

--
Paweł Kierski
n...@p...net

do góry

On Monday, August 13, 2012 7:20:11 AM UTC+1, Paweł Kierski wrote:

> Jest tu jedno milcz�ce za�o�enie - testy "urz�dowe" s� dobre, a mo�e
>
> i lepsze w pewnych zakresach od "zwyk�ych". Owszem, mog� by� czasem,
>
> ale um�wmy si� - gdyby kolesie pisz�cy testy dla "urz�du" byli naprawd�
>
> tak dobrzy, to raczej by w tym "urz�dzie" nie pracowali.

Pattern czesto jest taki: koles przez 10-20 lat pracuje 10-14h dziennie w
bankach/hedge fundach i zarabia duzo ???, nastepnie postanawia zmienic lifestyle na
bardziej zrelaksowany i zatrudnia sie u regulatora, gdzie pracuje stricte 8h
dziennie, ma duzo wiecej dni urlopowych i zarabia wyraznie mniej ??. It takes a thief
to catch a thief ;-)

Poza tym, oni wcale nie musza byc lepsi od gosci ktorych nadzoruja. Wystarczy, ze
maja inna perspektywe i inne motywacje.

> W Polsce to
>
> w tej chwili pewnik,

Amber Gold ;-)

> mo�e A.L. wypowie si� USA, ale podejrzewam, �e te�
>
> to w takďż˝ stronďż˝ idzie.

W londynskim City oczywiscie wszyscy bankowcy uwazaja ze FSA to "muppets", ale sie
ich boja.

RW

do góry

On 13/08/2012 07:20, Paweł Kierski wrote:
>
> Jest tu jedno milczące założenie - testy "urzędowe" są dobre, a może
> i lepsze w pewnych zakresach od "zwykłych". Owszem, mogą być czasem,
> ale umówmy się - gdyby kolesie piszący testy dla "urzędu" byli naprawdę
> tak dobrzy, to raczej by w tym "urzędzie" nie pracowali. W Polsce to
> w tej chwili pewnik, może A.L. wypowie się USA, ale podejrzewam, że też
> to w taką stronę idzie.

Ja myślę jednak, że w praktyce byłoby to relizowane tak, że samo
tworzenie testów i testowanie byłoby wykonywane przez prywatną firmę,
wyłonioną w jakimś przetargu.

W każdym razie to, czy ci testerzy są czy nie są tacy dobrzy jak kolesie
piszący oryginalny soft nie ma znaczenia: w końcu problemem nie jest to,
że ci od oryginalnego softu celowo wstawiają trudne do wykrycia bugi
żeby zbankrutować swojego pracodawcę, i im lepsi są, tym sprytniej je
ukryją. Problem polega na tym, że niektórym graczom statystycznie rzecz
biorąc nie opłaca się zabezpieczać przed pewnymi scenariuszami, bo w
razie czego koszty są przenoszone na kogoś innego.

I nie dotyczy to tylko etatowych pracowników, którzy pracują na premię,
ale też całych firm - z powodu instytucji ograniczonej odpowiedzialności
właściciele mogą być finansowo zabezpieczeni nawet jeśli firma spowoduje
straty na wielokrotność swojego kapitału i zbankrutuje.

>> Ja bm sie bal czego innego, ze testy "urzedowe" zastapia wewnetrzne,
>> zamiast je uzupelniac. "Jestemy kryci, spelniamy wymagania Basel III"
>> -- LOL :)
>
> Innymi słowy, ale właśnie to miałem na myśli. Stopniowo "urzędowe"
> będzie zastępować zdrowy rozsądek. Stopień pokrycia testami w sumie
> raczej spadnie niż wzrośnie.

Ale przynajmniej część szkodników się wykosi.

do góry

On Monday, August 13, 2012 10:32:08 AM UTC+1, Andrzej Jarzabek wrote:

> Problem polega na tym, �e niekt�rym graczom statystycznie rzecz
bior�c nie op�aca si� zabezpiecza� przed pewnymi scenariuszami, bo w
razie czego koszty sďż˝ przenoszone na kogoďż˝ innego.

Jak to mowia "privatize the gains, socialise the losses".

RW

do góry

W dniu 2012-08-13 11:32, Andrzej Jarzabek pisze:
> On 13/08/2012 07:20, Paweł Kierski wrote:
>>
>> Jest tu jedno milczące założenie - testy "urzędowe" są dobre, a może
>> i lepsze w pewnych zakresach od "zwykłych". Owszem, mogą być czasem,
>> ale umówmy się - gdyby kolesie piszący testy dla "urzędu" byli naprawdę
>> tak dobrzy, to raczej by w tym "urzędzie" nie pracowali. W Polsce to
>> w tej chwili pewnik, może A.L. wypowie się USA, ale podejrzewam, że też
>> to w taką stronę idzie.
>
> Ja myślę jednak, że w praktyce byłoby to relizowane tak, że samo
> tworzenie testów i testowanie byłoby wykonywane przez prywatną firmę,
> wyłonioną w jakimś przetargu.

Czyli jeszcze jedno miejsce styku, gdzie możemy zapodziać istotną
informację dotyczącą faktycznej natury i celu testów.

> W każdym razie to, czy ci testerzy są czy nie są tacy dobrzy jak kolesie
> piszący oryginalny soft nie ma znaczenia: w końcu problemem nie jest to,
> że ci od oryginalnego softu celowo wstawiają trudne do wykrycia bugi
> żeby zbankrutować swojego pracodawcę, i im lepsi są, tym sprytniej je
> ukryją. Problem polega na tym, że niektórym graczom statystycznie rzecz
> biorąc nie opłaca się zabezpieczać przed pewnymi scenariuszami, bo w
> razie czego koszty są przenoszone na kogoś innego.
>
> I nie dotyczy to tylko etatowych pracowników, którzy pracują na premię,
> ale też całych firm - z powodu instytucji ograniczonej odpowiedzialności
> właściciele mogą być finansowo zabezpieczeni nawet jeśli firma spowoduje
> straty na wielokrotność swojego kapitału i zbankrutuje.
[...]
> Ale przynajmniej część szkodników się wykosi.

Teoretycznie to powinno zadziałać i być lepiej. Boję się, że praktyka
może przynieść (przy sporych dodatkowych kosztach) wyniki słabe, albo
wręcz odwrotne.

Chyba faktycznie ostatecznym rozwiązaniem byłoby zwiększenie
odpowiedzialności za błędy, które i tak wystąpią. Ktoś może zaoponować,
że to zwiększy próg wejścia z pewnymi rozwiązaniami, bo firmy będą się
bały konsekwencji oznaczających de facto bankructwo firmy oraz zarządów
(jeśli dołożymy odpowiedzialność na majątku decydentów). Cóż - nie ma
obowiązku ryzykować i wdrażać skomplikowanych systemów, w których
zawsze będzie jeszcze jeden błąd...

--
Paweł Kierski
n...@p...net

do góry