W dniu 2011-05-17 23:20, Andrzej Jarzabek pisze:
[...]
> Nie wiem, może pracujesz w jakiejś specyficznej branży, albo
> specyficznej kulturze, w której waterfall się sprawdza, ale consensus
> jest jednak taki, że nie sprawdza się prawie nigdy.
>
> Ja też pracowałem z analitykami, wydaje mi się, że dość dobrymi, ale
> zawsze było tak, że dokumenty, które wyprodukowali trzeba było mocno
> modyfikować w trakcie developmentu. I komunikacja, a nie dokumentacja,
> była kluczowa dla skuteczności realizacji _rzeczywistych_ wymagań.

Dorzucę swoje trzy grosze - gdyby analiza była tak dobra, że dokumenty
nie musiałyby się zmieniać, to znaczyłoby, że na ich podstawie kod może
tworzyć przysłowiowy student za 1200.

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

do góry

On May 18, 7:02 am, Zenek1234 <z...@1...pl> wrote:
> W dniu 2011-05-18 01:58, R. P. pisze:
>
> > Dodam, że duża część ludzi zatrudnionych w Google to właśnie lauraci
> > takich konkursów algorytmicznych jak "Potyczki" itp. A jak wiemy google
> > jest nielichą firmą i tworzy nieliche rzeczy. To tak na popracie mojej
> > tezy.
>
> Jaka jest średnia wieku ludzi zatrudnianych przez G. ?

Nie wiem.

> Podobno b. niska, nie przekraczająca 30 lat.
> I co się dalej z nimi dzieje?

Co to znaczy "dalej"? Jakoś nie słyszałem, żeby Google zwalniało ludzi
z powodu wieku, myślę też, że jak ktoś pracował w Google jako
programista, to nie będzie miał po odejściu problemów ze znalezieniem
pracy.

> Jaka w ogóle jest średnia wieku programisty?

Kto to wie?

Kolejne pytanie byłoby takie, co to oznacza, że średnia wieku jest x
lat. A oznacza tylko tyle, że jak dodamy do siebie wiek wszystkich
programistów i podzielimy przez liczbę programistów, to wyjdzie x. Na
pewno idiotyzmem byłoby wyciąganie wniosku, że powyżej iluś tam lat
nie da się pracować lub ciężko znaleźć pracę jako programista.

> I jak się kształtuje najczęściej ścieżka kariery takiego
> programisty po 50-tce?

Zgadywałbym, że najczęściej kosi grubą kasę jako jeden z nielicznych
specjalistów od jakiejś egzotycznej technologii czy produktu,
ewentualnie kieruje zespołem, ewentualnie odłożył kasę i założył swoją
firmę.

> Czy zastanawialiście się, co będziecie robić w tym wieku?

W jakim celu?

do góry

On May 18, 9:57 am, Paweł Kierski <n...@p...net> wrote:
> W dniu 2011-05-17 23:20, Andrzej Jarzabek pisze:

>
> Dorzucę swoje trzy grosze - gdyby analiza była tak dobra, że dokumenty
> nie musiałyby się zmieniać, to znaczyłoby, że na ich podstawie kod może
> tworzyć przysłowiowy student za 1200.

Ja się nie zgodzę. Znaczy, niby oczywiście może, ale żadna analiza nie
zapobiegnie błędom w kodie, niskiej czytelności, słabej wydajnosci,
kiepskiemu maintainability i tak dalej.

Problem polega na tym, że taka analiza czy dokumentacja wymagań to
taka sama fikcja, jak by powiedzieć, że jak się zatrudni bardzo
dobrych programistów za grube pieniądze, to nie trzeba testowac
oprogramowania, bo dobrzy programiści nie robią błędów.

do góry

Paweł Kierski wrote:

> W dniu 2011-05-17 13:40, R. P. pisze:
>>
>> Agile, scrum, te wszystkie nowe "wynalazki" powodują tylko to, że
>> aplikacje stają się coraz mniej używalne, coraz więcej w nich błędów.
>> Dołóż do tego jeszcze XP, a masz murowaną katastrofę.
>
> Bzdury. Agile mówi z grubsza tylko tyle - proces ma być w minimalnym
> stopniu obciążony elementami, które nie prowadzą do działającego
> produktu. Na dodatek proces może (i powinien) być cały czas poprawiany.
>
> Jeśli projekt i dokumentacja jest niezbędna do stworzenia działającego
> produktu, to powstanie. Ale np. nie musi być sformalizowana, jeśli
> zdjęcie tablicy z rysunkiem + 5 zdań objaśnienia jest wystarczające.
> Jeśli zespół nie jest w stanie zapanować nad złożonością i ciągle się
> wszystko sypie, to raczej dojdzie do wniosku, że formalna dokumentacja
> musi powstać. I pewnie powstanie. To jest element uczenia się
> i poprawiania procesu wytwarzania.
>

Z tego by wynikalo, ze "Agile" w ogole nic nie mowi na temat tego jak robic
oprogramowanie oprocz garsci banalow w stylu "rob tylko rzeczy niezbedne" i
"poprawiaj proces".

> Tak - to cały czas jest balansowanie na linie i ryzykowanie. Przy silnym
> założeniu, że ludzie się uczą na błędach (i nie są za nie karani*) to
> wystarcza.
>
> *) Największą karą i motywacją bywa świadomość, że coś się spieprzyło
> w sposób absolutnie oczywisty.
>

Jasne - programista przezyje niewyslowione katusze przezywajac porazke
belkoczac po kolejnym glebszym.
Inwestor natomiast zapozna sie z komornikiem.

Moim zdaniem cale to "Agile" jest bardzo dobrym sposobem na wyludzanie przez
programistow pieniedzy bez ponoszenia najmniejszych konsekwencji swoich
dzialan. Ewentualnie (w lepszym przypadku) - usprawiedliwieniem dla
niekompetencji kierownictwa.
To, ze (top) management w organizacjach kupuje tego rodzaju pomysly jest dla
mnie troche niepojete. Jest kilka mozliwosci:
1) najbardziej prawdopodobne jest to, ze XP/Agile stosuje sie w projektach o
tak malym znaczeniu i koszcie, ze tak naprawde wszystko jedno jak sie to
robi, zas zarzadzanie mozna powierzyc jakiemus matolowi bo nawet jak
spieprzy to nic nie nie stanie
2) management to byli programisci, ktorzy nie maja pojecia o liczeniu
pieniedzy/ROI itp. Nie moga oni awansowac zbyt wysoko i zajmowac sie czyms
wazniejszym, bo firma poszlaby z torbami placac za oprogramowanie, ktore
nigdy nie jest skonczone, dlatego patrz p. 1)
3) biznes jest taki dobry, ze przychody sa nieporownywalnie wieksze niz
koszt ciaglego placenia za oprogramowanie i nie ma najmniejszej motywacji,
zeby cokolwiek w tej dzialce zmieniac

--
Michal

do góry

Michal Kleczek wrote:

> Paweł Kierski wrote:
>
>> W dniu 2011-05-17 13:40, R. P. pisze:
>>>
>>> Agile, scrum, te wszystkie nowe "wynalazki" powodują tylko to, że
>>> aplikacje stają się coraz mniej używalne, coraz więcej w nich błędów.
>>> Dołóż do tego jeszcze XP, a masz murowaną katastrofę.
>>
>> Bzdury. Agile mówi z grubsza tylko tyle - proces ma być w minimalnym
>> stopniu obciążony elementami, które nie prowadzą do działającego
>> produktu. Na dodatek proces może (i powinien) być cały czas poprawiany.
>>
>> Jeśli projekt i dokumentacja jest niezbędna do stworzenia działającego
>> produktu, to powstanie. Ale np. nie musi być sformalizowana, jeśli
>> zdjęcie tablicy z rysunkiem + 5 zdań objaśnienia jest wystarczające.
>> Jeśli zespół nie jest w stanie zapanować nad złożonością i ciągle się
>> wszystko sypie, to raczej dojdzie do wniosku, że formalna dokumentacja
>> musi powstać. I pewnie powstanie. To jest element uczenia się
>> i poprawiania procesu wytwarzania.
>>
>
> Z tego by wynikalo, ze "Agile" w ogole nic nie mowi na temat tego jak
> robic oprogramowanie oprocz garsci banalow w stylu "rob tylko rzeczy
> niezbedne" i "poprawiaj proces".
>
>> Tak - to cały czas jest balansowanie na linie i ryzykowanie. Przy silnym
>> założeniu, że ludzie się uczą na błędach (i nie są za nie karani*) to
>> wystarcza.
>>
>> *) Największą karą i motywacją bywa świadomość, że coś się spieprzyło
>> w sposób absolutnie oczywisty.
>>
>
> Jasne - programista przezyje niewyslowione katusze przezywajac porazke
> belkoczac po kolejnym glebszym.
> Inwestor natomiast zapozna sie z komornikiem.
>
> Moim zdaniem cale to "Agile" jest bardzo dobrym sposobem na wyludzanie
> przez programistow pieniedzy bez ponoszenia najmniejszych konsekwencji
> swoich dzialan. Ewentualnie (w lepszym przypadku) - usprawiedliwieniem dla
> niekompetencji kierownictwa.
> To, ze (top) management w organizacjach kupuje tego rodzaju pomysly jest
> dla mnie troche niepojete. Jest kilka mozliwosci:
> 1) najbardziej prawdopodobne jest to, ze XP/Agile stosuje sie w projektach
> o tak malym znaczeniu i koszcie, ze tak naprawde wszystko jedno jak sie to
> robi, zas zarzadzanie mozna powierzyc jakiemus matolowi bo nawet jak
> spieprzy to nic nie nie stanie
> 2) management to byli programisci, ktorzy nie maja pojecia o liczeniu
> pieniedzy/ROI itp. Nie moga oni awansowac zbyt wysoko i zajmowac sie czyms
> wazniejszym, bo firma poszlaby z torbami placac za oprogramowanie, ktore
> nigdy nie jest skonczone, dlatego patrz p. 1)
> 3) biznes jest taki dobry, ze przychody sa nieporownywalnie wieksze niz
> koszt ciaglego placenia za oprogramowanie i nie ma najmniejszej motywacji,
> zeby cokolwiek w tej dzialce zmieniac
>

Aha - oczywiscie:
4) Firma zajmuje sie wytwarzaniem oprogramowania, postanowila zalapac sie na
"buzzwordy" i znalazla klientow, ktorzy sa sklonni placic jej na zasadzie
"time and material" i wierza (na jakiej podstawie?), ze to sie oplaci.
Klienci ci to albo ci z p. 3) albo zatrudniaja management z p 1) i 2).

--
Michal

do góry

W dniu 2011-05-18 12:06, Michal Kleczek pisze:
[...]
> Z tego by wynikalo, ze "Agile" w ogole nic nie mowi na temat tego jak robic
> oprogramowanie oprocz garsci banalow w stylu "rob tylko rzeczy niezbedne" i
> "poprawiaj proces".

Owszem. Ponieważ historycznie te banały zaczęły być stosowane
w praktyce akurat dość daleko od produkcji oprogramowania.

[...]
> Moim zdaniem cale to "Agile" jest bardzo dobrym sposobem na wyludzanie przez
> programistow pieniedzy bez ponoszenia najmniejszych konsekwencji swoich
> dzialan. Ewentualnie (w lepszym przypadku) - usprawiedliwieniem dla
> niekompetencji kierownictwa.

Czy widziałeś "na żywo" działający zespół Agile? Choć przez tydzień?

Gdyby tak było zawsze, to każda firma stosująca Agile by upadła. Bo
programiści robiliby cokolwiek bez konsekwencji lub projekty
prowadziłoby niekompetentne kierownictwo. A są firmy, które tego używają
i działają. Być może nieoptymalnie - ale jak to sprawdzisz?

> To, ze (top) management w organizacjach kupuje tego rodzaju pomysly jest dla
> mnie troche niepojete. Jest kilka mozliwosci:
> 1) najbardziej prawdopodobne jest to, ze XP/Agile stosuje sie w projektach o
> tak malym znaczeniu i koszcie, ze tak naprawde wszystko jedno jak sie to
> robi, zas zarzadzanie mozna powierzyc jakiemus matolowi bo nawet jak
> spieprzy to nic nie nie stanie

Podstaw cokolwiek za "XP/Agile" i będziesz miał prawdziwe zdanie.

> 2) management to byli programisci, ktorzy nie maja pojecia o liczeniu
> pieniedzy/ROI itp. Nie moga oni awansowac zbyt wysoko i zajmowac sie czyms
> wazniejszym, bo firma poszlaby z torbami placac za oprogramowanie, ktore
> nigdy nie jest skonczone, dlatego patrz p. 1)

Weźmy taki Scrum. Każda iteracja to umowa na wykonanie konkretnych
funkcjonalności w konkretnym czasie. Selekcja funkcjonalności
do kolejnej iteracji opiera się - niespodzianka! - na liczeniu ROI.
Sortujemy po stosunku spodziewanego przyrostu wartości produktu do
kosztu (z góry ustalonego) czasu pracy zespołu (+ ewentualne dodatkowe
koszty).

> 3) biznes jest taki dobry, ze przychody sa nieporownywalnie wieksze niz
> koszt ciaglego placenia za oprogramowanie i nie ma najmniejszej motywacji,
> zeby cokolwiek w tej dzialce zmieniac

Patrz odpowiedź do pkt. 1. A na marginesie przypominam, że Agile zakłada
ciągłe doskonalenie procesu, czyli - niespodzianka! - zmiany.

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

do góry

On May 18, 11:06 am, Michal Kleczek <k...@g...com> wrote:
>
> Z tego by wynikalo, ze "Agile" w ogole nic nie mowi na temat tego jak robic
> oprogramowanie oprocz garsci banalow w stylu "rob tylko rzeczy niezbedne" i
> "poprawiaj proces".

Zacząć by należało od tego, że "Agile" to nie jest jakiś konkretna
receptura, proces czy metodologia, tylko zbiór ogólnych pomysłów. W
ramach tych pomysłów istnieją mniej lub bardziej konkretne metodologie
i procesyy realizujące te metodologie, które są "agile" (przymiotnik,
nie rzeczownik).

Dalej, jeśli chodzi o samą koncepcję Agile, to jej banalność jest w
oku patrzącego, natomiast prawda jest taka, że często się tych
pomysłów nie stosuje.

Te pomysły to przede wszystkim położenie nacisku na bezpośrednią
komunikację, np. że raczej warto włozyć wysiłek w to, żeby z zespołem
siedział ktoś dobrze rozumiejący dziedzinę, niż żeby ktoś taki
przygotował szczegółową dokumentację. Że lepiej poświęcić czas na
napisanie prototypu, niż na stworzenie dokumentu projektowego. Żeby
nie bać się poprawiać śmierdzącego kodu na zasadzie "działa, więc
lepiej nie ruszać", że w bardzo wielu przypadkach nie da się dokładnie
ustalić z góry wymagań itd.


> > *) Największą karą i motywacją bywa świadomość, że coś się spieprzyło
> > w sposób absolutnie oczywisty.
>
> Jasne - programista przezyje niewyslowione katusze przezywajac porazke
> belkoczac po kolejnym glebszym.
> Inwestor natomiast zapozna sie z komornikiem.
>
> Moim zdaniem cale to "Agile" jest bardzo dobrym sposobem na wyludzanie przez
> programistow pieniedzy bez ponoszenia najmniejszych konsekwencji swoich
> dzialan.

A w nie-Agile jakie ponoszą konsekwencje? Mogą zostać wyrzuceni z
pracy? No to w Aglie tak samo mogą.

> Ewentualnie (w lepszym przypadku) - usprawiedliwieniem dla
> niekompetencji kierownictwa.
> To, ze (top) management w organizacjach kupuje tego rodzaju pomysly jest dla
> mnie troche niepojete. Jest kilka mozliwosci:
> 1) najbardziej prawdopodobne jest to, ze XP/Agile stosuje sie w projektach o
> tak malym znaczeniu i koszcie, ze tak naprawde wszystko jedno jak sie to
> robi, zas zarzadzanie mozna powierzyc jakiemus matolowi bo nawet jak
> spieprzy to nic nie nie stanie

Znam firmę żyjącą ze sprzedawania algorithmic trading platforms
produkowanych w ten sposób.

> 2) management to byli programisci, ktorzy nie maja pojecia o liczeniu
> pieniedzy/ROI itp. Nie moga oni awansowac zbyt wysoko i zajmowac sie czyms
> wazniejszym, bo firma poszlaby z torbami placac za oprogramowanie, ktore
> nigdy nie jest skonczone, dlatego patrz p. 1)
> 3) biznes jest taki dobry, ze przychody sa nieporownywalnie wieksze niz
> koszt ciaglego placenia za oprogramowanie i nie ma najmniejszej motywacji,
> zeby cokolwiek w tej dzialce zmieniac

W bardzo wielu przypadkach realia i tak są takie, że jak się chce
prowadzić biznes, to trzeba ciągle zmieniać oprogramowanie i w związku
z tym ciągle za to płacić. Bo nowa funkcjonalność, bo konkurencja, bo
systemy, z którym się łączymy zmieniają format danych, bo przepisy
itd. W rzeczywistości prawie wszystkie firmy produkujące
oprogramowanie, czy stosują agile czy nie, właśnie z tego żyją.

Jeśli natomiast mówimy o "skończeniu" w sensie dostarczenia pierwszej
wersji produkcyjnej dla klienta, to właśnie przecież jedną z koncepcji
około-agile jest to, żeby "skończyć" jak najszybciej: zamiast w
pierwszym kroku identyfikować wszystko, co klient chce mieć i wpisać
to do wymagań i dalej planować development tak, żeby w miarę
możliwości wszystkie wymagania dostarczyć w wersji 1.0, to starać się
zidentyfikować minimalny zestaw funkcjonalności, przy której produkt
jest w ogóle użyteczny dla klienta, i starać się zrobić wersję 1.0 z
taką funkcjonalnością, ale za to w dwa miesiące.

do góry

Andrzej Jarzabek wrote:
> On 18/05/2011 00:55, R. P. wrote:
>> Andrzej Jarzabek wrote:
>>>
>>>> Dlatego świetni matematycy prawie zawsze są świetnymi programistami.
>>>
>>> Ciekawa teza, jakieś przykłady? Bo mnie wydaje się równie sensowna, co
>>> "świetni matematycy prawie zawsze są świetnymi muzykami". Ale uczciwie
>>> przyznam, że nie śledzę tematu kto jest świetnym matematykiem i co za
>>> programy pisze.
>>
>> A sam jesteś dobrym algorytmikiem? :)
>
> Co to ma do rzeczy? Brakuje argumentów i schodzimy na ad hominem?

Ja nie potrzebuje nikogo przekonywać, wiem że implikacja dobry matematy
=> dobry programista jest prawdziwa, natomiast odwrotna już nie zawsze.
Informatyka to praktyczne zastosowania matematyki. A czy muzyka to
praktyczne zastosowania matematyki? Po części tak, ale tylko po części.
Dlatego twoje porównanie jest chybione.

do góry

On May 18, 11:14 am, Michal Kleczek <k...@g...com> wrote:
> Michal Kleczek wrote:
>
> Aha - oczywiscie:
> 4) Firma zajmuje sie wytwarzaniem oprogramowania, postanowila zalapac sie na
> "buzzwordy" i znalazla klientow, ktorzy sa sklonni placic jej na zasadzie
> "time and material" i wierza (na jakiej podstawie?), ze to sie oplaci.
> Klienci ci to albo ci z p. 3) albo zatrudniaja management z p 1) i 2).

A na jakiej podstawie wierzą, ze się opłaci w dowolnym innym
przypadku? Na jakiej podstawie wierzą, ze jeśli w umowie zapiszą
funkcjonalność i termin, to produkt z taką funkcjonalnością zostanie
faktycznie dostarczony w takim terminie? Na jakiej podstawie wierzą,
że produkt formalnie spełniający warunki określone w umowie będzie
miał dla nich jakąkolwiek wartość?

do góry

Andrzej Jarzabek wrote:
> On May 18, 12:58 am, "R. P." <r...@w...to.wp.pl>
> wrote:
>> Andrzej Jarzabek wrote:
>>> On 17/05/2011 23:02, R. P. wrote:
>>>> Andrzej Jarzabek wrote:
>>>>> On 17/05/2011 21:41, R. P. wrote:
>>>>>> HEhe, odpowiedzi nie dostałem. Wnioski pozostawię dla siebie...
>>>>> Jeśli chodzi o to, na czym polega programowanie, to spytam jeszcze
>>>>> raz: co to ma wspólnego z byciem Prawdziwym Programistą? Działające
>>>>> programy to każdy może napisać.
>>>> Właśnie nie każdy. Tylko solidny umysł, który zna dobrze algorytmy może
>>>> pisać programy, które działają, obsługują wszystkie, nawet najmniej
>>>> prawdopodobne przypadki. Przeciętny umysł wielu rzeczy nie zauważa.
>>> A niekumate umysły pozostaną zawsze niekumate.
>>>> Dlatego świetni matematycy prawie zawsze są świetnymi programistami.
>>> Ciekawa teza, jakieś przykłady? Bo mnie wydaje się równie sensowna, co
>>> "świetni matematycy prawie zawsze są świetnymi muzykami". Ale uczciwie
>>> przyznam, że nie śledzę tematu kto jest świetnym matematykiem i co za
>>> programy pisze.
>> Dodam, że duża część ludzi zatrudnionych w Google to właśnie lauraci
>> takich konkursów algorytmicznych jak "Potyczki" itp. A jak wiemy google
>> jest nielichą firmą i tworzy nieliche rzeczy. To tak na popracie mojej
>> tezy.
>
> To może przyłóż swój matematyczny umysł do progblemu logicznego, że
> nie ma takiego wynikania, jak napisałeś;
>
> * Z tego, że ktoś jest świetnym matematykiem, nie wynika, że wygra(ł)
> konkurs.

Nie wynika. Ale duża część świetnych matematyków zajmuje czołowe miejsca
na takich konkursach. To są fakty i bardzo łatwo je sprawdzić.

> * Z tego, że ktoś jest zatrudniony przez Google nie znaczy, że jest
> świetnym programistą.

Znów: "duża część" to świetni programiści. Nie wszyscy.

> * Jeśli ktoś, kto wygrał konkurs i został zatrudniony przez Google
> jest akurat świetnym programistą, to nie znaczy, że każdy, kto wygrywa
> konkurs jest świetnym programistą, ani że matematycy są na ogół
> świetnymi programistami.

Znów "duża część". Wyjątki zawsze się zdarzają. Nie powiesz mi, że jak
ktoś rozkminia świetnie problemy algorytmiczne, potrafi napisać program,
który przechodzi bezbłędnie 10/10 testów ułożonych przez doświadczonych
ludzi, to jest człowiekiem, który nie umie rozwiązywać problemów.

do góry