bartekltg <b...@g...com> napisał(a):

> W dniu 2012-02-19 20:48, M.M. pisze:
> > bartekltg<b...@g...com> napisał(a):
> >
> >> ale za Chiny Ludowe nie widzę przypadku,
> >> który odpowiadałby histroi o podnoszeniu szafki.
> >
> > Nie rozumiem czego nie rozumiesz.
> >
> > Nie zdarzylo Ci sie nigdy siedziec z kolega nad
> > wspolnym problemem?
> >
> > Czy moze zawsze w tym samym czasie znajdowales rozwiazanie
> > co kolega?
> >
> > A moze zawsze znales pierwszy rozwiazanie niz kolega?
> >
> > A moze zawsze gdy sie Ty myliles to kolega sie z Toba zgadzal
> > ze masz racje i nic nie pomagal?
>
> Ale to ma się nijak do histroi o wspolnym podnoszeniu
> mebla. To wszystko 'pokazywanie że się ominęło śmiecia'.
> Tego nie kwestionuję. Chciałem tylko zobaczyć przykład
> z programowania odpowiadający historii o wspolnym
> podnoszeniu mebla.
>
> Masz taki, czy jednak analogia była nietrafiona?
Jak nietrafiona, przeciez mowie o zwyklej rzeczy.

Podciaga sie pod to kazda sytuacja gdy trzeba szybko
cos zrobic. Jesli robia to dwie osoby, to jedna poda
szybciej rozwiazanie niz druga, a druga ma szanse
szybciej zweryfikowac slusznosc rozwiazania.

Nigdy Ci sie nie zdarzylo ze kazde 15 minut zwloki powodowalo
jakies ryzyko? Mnie sie zdarzylo ze przedwczesnie zainstalowany
system uniemozliwil normalny powrot do domu 300 ludziom (i
nie tylko). Poziom wkurwienia klienta rosl wykladniczo, klient
znal 30 innych klientow i mogl smrodu narobic. Kazde 15 minut
przy usuwaniu usterki bylo na wage zlota. Jestes pewny ze jeden
programista tak samo podola jak para przy takim stresie?

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Andrzej Jarzabek <a...@g...com> napisaďż˝(a):

> On 19/02/2012 20:11, bartekltg wrote:
> >
> > Ale to ma się nijak do histroi o wspolnym podnoszeniu
> > mebla. To wszystko 'pokazywanie że się ominęło śmiecia'.
> > Tego nie kwestionuję. Chciałem tylko zobaczyć przykład
> > z programowania odpowiadający historii o wspolnym
> > podnoszeniu mebla.
> >
> > Masz taki, czy jednak analogia była nietrafiona?
>
> Ja mam taki przykład. Przepraszam, że bez szczegółów, ale ogólnie
> sytuacja wyglądała tak, że program się zachowywał w sposób, który nie
> powinien być możliwy. Byłem w stanie prześledzić do konkretnego momentu
> i po prostu wylgądało jakby zachowanie programu było sprzeczne z kodem,
> tudzież zmieniało się wraz ze zmianą okoliczności, które na to
> zachowanie nie powinny mieć wpływu. Straciłem dwa dni na debugowaniu wtę
> i wewtę, logowaniu różnych rzeczy, podstawianiu danych itd. i nic - po
> prostu paradoks. Pokazałem koledze i w 10 minut zorientowaliśmy się,
> gdzie popełniłem błędne założenie.

Mialem podobnie. Stracilem ze dwie doby na debugowanie i bledu nie
znalazlem. Napisalem na grupe dyskusyjna i mi w 10 minut ktos powiedzial
ze mam wersje kompilatora z bledami. Nigdy by mi do glowy nie przyszlo
ze w kompilatorach moga byc bledy.

Pozdrawiam









--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 19/02/2012 21:14, A.L. wrote:
> On Sun, 19 Feb 2012 19:18:08 +0100, szyk<s...@o...pl> wrote:
>
> Natomiast zeby nei wiem co pisac o "pair programming" i podobnych
> rzeczach - koszt projektu jest sprawa najwazniejsza. Albowiem jak sie
> sklada papiery w przetargu, to tzreba napisac ile projekt bedzie
> kosztowal. Jak zorganizujemy go tak ze przy jednym komputerze bedzie
> siedzialo dwoch facetow, to albo: a) koszt projektu wzrosnie
> dwukrotnie, albo b) kazdy z facetow zadowoli sie polowa pensji. W tym

Albo c) dwóch facetów zrobi to samo zadanie 2 razy szybciej niż 1 facet.

do góry

On Sun, 19 Feb 2012 19:59:09 +0100, bartekltg <b...@g...com>
wrote:

>W dniu 2012-02-19 16:45, A.L. pisze:
>
>
>> Bajanai wszelkich "gurus" padaja na podatny grunt, bo wiekszosc
>> managementu nie ma przyslowiowego "clue", wiec lapie sie dowolnej
>> glupoty any uratowac swa d..... Wiadomo ze jak nei potrafisz nic
>> robic, to zostajesz guru. Musisz miec tylko odpowiednai ilosc Daru
>> Bozego ktory nazywa sie "hucpa"
>
>
>Ale to nikt z 'darem bożym' nie połapał sie i nie zrobił kariery
>na demaskowaniu złych metod.
>
Dlaczego nie?

Polecam ksiazke:

Extremem Programming Refactored: The Case Against XP, Matt Stephens,
Doug Rosenberg

Z notki wydawcy:

Extreme Programming Refactored: The Case Against XP (featuring Songs
of the Extremos) takes a satirical look at the increasingly-hyped
extreme programming (XP) methodology. It explores some quite
astonishing Extremo quotes that have typified the XP approach quotes
such as, "XPers are not afraid of oral documentation," "Schedule is
the customer's problem," "Dependencies between requirements are more a
matter of fear than reality" and "Concentration is the enemy."

In between the chuckles, though, there is a serious analysis of XP's
many flaws. The authors also examine C3, the first XP project, whose
team (most of whom went on to get XP book deals shortly before C3's
cancellation) described themselves as "the best team on the face of
the Earth." (In a later chapter, the authors also note that one
problem which can affect pair programmers is overconfidence--or is that
"eXcessive courage"?). The authors examine whether the problems that
led to C3's "inexplicable" cancellation could also afflict present-day
XP projects.

A tak w ogole, to trudno z tym walczyc. Proponuje pzreprowadzic
analogie z obalaniem teorii Newtona pzrez niektoryc hwynalazcow, czy
uporczywie krazacymi projektami samochodu napedzanego woda.

A.L.
>

do góry

A.L. <l...@a...com> napisał(a):

> Bycie firmy nie zalezy od programistow. To tak jakby powiedzec ze przy
> budowie mostu kazdy spawacz musi meic zastepce, bo jakby ten wlasciwy
> poszedl na chorobe i nei bylo zastepcy, to by sie budowa zawalila.

To raczej tak jakby powiedziec ze jakosci spawow nie trzeba
sprawdzac bo spawacz powinien sobie poradzic, w koncu byl na kursie i
spawac umie.

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

W dniu 2012-02-19 22:16, Andrzej Jarzabek pisze:
> On 19/02/2012 20:11, bartekltg wrote:
>>
>> Ale to ma się nijak do histroi o wspolnym podnoszeniu
>> mebla. To wszystko 'pokazywanie że się ominęło śmiecia'.
>> Tego nie kwestionuję. Chciałem tylko zobaczyć przykład
>> z programowania odpowiadający historii o wspolnym
>> podnoszeniu mebla.
>>
>> Masz taki, czy jednak analogia była nietrafiona?
>
> Ja mam taki przykład. Przepraszam, że bez szczegółów, ale ogólnie
> sytuacja wyglądała tak, że program się zachowywał w sposób, który nie
> powinien być możliwy. Byłem w stanie prześledzić do konkretnego momentu
> i po prostu wylgądało jakby zachowanie programu było sprzeczne z kodem,
> tudzież zmieniało się wraz ze zmianą okoliczności, które na to
> zachowanie nie powinny mieć wpływu. Straciłem dwa dni na debugowaniu wtę
> i wewtę, logowaniu różnych rzeczy, podstawianiu danych itd. i nic - po
> prostu paradoks. Pokazałem koledze i w 10 minut zorientowaliśmy się,
> gdzie popełniłem błędne założenie.

To nawet częsta sytuacja. Ale to zwykła praca zespołowa.

> Oczywiście możesz powiedzieć, że założenie błędne, bo gdybym nie
> poprosił kolegi o pomoc, to pewnie sam bym w końcu wpadł na właściwe
> rozwiązanie, nawet gdyby to miało zająć kolejne 3 dni, ale tak to już
> bywa z analogiami - nie zawsze są w 100% dokładne.

Ale ta była dodana jako kolejna, po 'zwykłej pracy zespołowej'.

"Gdy trzeba wyrzucic zepsuta komode to jedna nigdy by nie
poradzila bo jest za slaba.
We dwie i tego smiecia sie pozbeda."

Tu mamy zupełnie inną sytuację. Bez pomocy nie masz możliwości
sobie poradzić, bo za mały udźwig, a z pomoca niesiecie.

Wydeje mi się, że M.M po prostu przesadził z porównaniem i tyle.
Bo porównanie jest z sufitu.


> Inną, być może lepszą, ale też trudniejszą do wykazania na konkretnym
> przykładzie analogią jest jakość kodu wytwarzanego przez programistów i
> jego konsekwencje. Najbardziej oczywistą sprawą jest ilość defektów:
> nawet mając dział QA, który wykrywa powiedzmy większość defektów, ilość
> tychże w kodzie programisty ma kolosalne znaczenie: zawsze ilość
> defektów pozostanie niewykrytych, co może narazić klientów na straty i
> spowoduje utratę reputacji firmy i zespołu, natomiast nawet te, które
> zostaną wykryte, będą opóźniać release lub powodować redukcję ficzerów w
> danej wersji. I teraz możesz założyć, że dany programista będzie
> popełniał ileś tam błędów w danym kawałku kodu - będzie to zależało od
> różnych czynników, jak język, narzędzia, metodologia itd., ale zawsze
> jakiś tam poziom błędów będzie. I w zasadzie niewiele może sam z siebie
> zrobić, żeby ten poziom błędów zmniejszyć - gdyby potrafił pisać lepiej,
> to by już tak pisał. Ta ilośc błędów to waga szafki, którą może
> udźwignąć. Pracując z drugim programistą razem stworzą kod, który ma
> mniejszą ilość defektów, niż którykolwiek z nich mógłby osiągnąć z
> osobna. Czyli dźwigają cięższą szafkę, niż każdy z nich z osobna mógłby
> udźwignąć.

Nie. To jest dokładnie przykład z posta wcześniej, obie sprzątaczki
szukają śmieci i razem mają mniejszą szansę przegapić paproszek.

Takie przykłady można by mnożyć. Masz napisać coś na 'za 24h'.
Sam nie dasz rady, z kolegą dasz. Ale nie jest to odpowiednik
siłowania sie z szafką.


> Taką samą analogię można zbudować dla innych parametrów jak performance,
> maintainablility, jakość projektu rozmaitych interfejsów itd.

Tak. I to wszytko analogia jakości sprzątania czy wyrobienia
się na powrót właścicieli domu. Nie masz tam nigdzie sytuacji
typu 'sam nie ruszysz bo nie masz możliwości'.

pzdr
bartekltg

do góry

W dniu 2012-02-19 22:21, M.M. pisze:

> Nigdy Ci sie nie zdarzylo ze kazde 15 minut zwloki powodowalo
> jakies ryzyko? Mnie sie zdarzylo ze przedwczesnie zainstalowany
> system uniemozliwil normalny powrot do domu 300 ludziom (i
> nie tylko). Poziom wkurwienia klienta rosl wykladniczo, klient
> znal 30 innych klientow i mogl smrodu narobic. Kazde 15 minut
> przy usuwaniu usterki bylo na wage zlota. Jestes pewny ze jeden
> programista tak samo podola jak para przy takim stresie?

Super, ale to nie ten przykład:)

Dobra, kończe to bo się trollociąg z rozumienia
różnic między analogiami zrobi

pzdr
bartekltg

do góry

bartekltg <b...@g...com> napisał(a):

> Wydeje mi się, że M.M po prostu przesadził z porównaniem i tyle.
> Bo porĂłwnanie jest z sufitu.

Porownanie bylo celowo tak dobrane aby uwypluklic o co chodzi, bo ktos
kompletnie nie zrozumial i mysla ze chodzi o "dwie sprzataczki zamiataja
jedna miotla".

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

bartekltg <b...@g...com> napisał(a):

> W dniu 2012-02-19 22:21, M.M. pisze:
>
> > Nigdy Ci sie nie zdarzylo ze kazde 15 minut zwloki powodowalo
> > jakies ryzyko? Mnie sie zdarzylo ze przedwczesnie zainstalowany
> > system uniemozliwil normalny powrot do domu 300 ludziom (i
> > nie tylko). Poziom wkurwienia klienta rosl wykladniczo, klient
> > znal 30 innych klientow i mogl smrodu narobic. Kazde 15 minut
> > przy usuwaniu usterki bylo na wage zlota. Jestes pewny ze jeden
> > programista tak samo podola jak para przy takim stresie?
>
> Super, ale to nie ten przykład:)

Ten przyklad. Tam sobie sprzataczka nigdy nie poradzi sama. Tutaj sobie
programista nigdy nie poradzi sam bo klient zrezygnuej ze zlecenia i
firma padnie. No chyba ze bedze pracowal hobbystycznie bez wyplaty.

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 19/02/2012 22:20, bartekltg wrote:
> W dniu 2012-02-19 22:16, Andrzej Jarzabek pisze:
>>
>> Ja mam taki przykład. Przepraszam, że bez szczegółów, ale ogólnie
>> sytuacja wyglądała tak, że program się zachowywał w sposób, który nie
>> powinien być możliwy. Byłem w stanie prześledzić do konkretnego momentu
>> i po prostu wylgądało jakby zachowanie programu było sprzeczne z kodem,
>> tudzież zmieniało się wraz ze zmianą okoliczności, które na to
>> zachowanie nie powinny mieć wpływu. Straciłem dwa dni na debugowaniu wtę
>> i wewtę, logowaniu różnych rzeczy, podstawianiu danych itd. i nic - po
>> prostu paradoks. Pokazałem koledze i w 10 minut zorientowaliśmy się,
>> gdzie popełniłem błędne założenie.
>
> To nawet częsta sytuacja. Ale to zwykła praca zespołowa.

No więc zwykła praca zespołowa (przynajmniej taka, z jaką się zwykle
spotykam) prowadzi do sytuacji, gdzie szukasz pomocy po np. dwóch dniach
walenia głową w mur. Przewaga programowania parami jest taka, że pomoc
masz od razu.

[...]
> Nie. To jest dokładnie przykład z posta wcześniej, obie sprzątaczki
> szukają śmieci i razem mają mniejszą szansę przegapić paproszek.
[...]
>> Taką samą analogię można zbudować dla innych parametrów jak performance,
>> maintainablility, jakość projektu rozmaitych interfejsów itd.
>
> Tak. I to wszytko analogia jakości sprzątania czy wyrobienia
> się na powrót właścicieli domu. Nie masz tam nigdzie sytuacji
> typu 'sam nie ruszysz bo nie masz możliwości'.

Różne analogie można tworzyć, zależy co się za co podstawi. Ogólnie
można powiedzieć, że praca sprzątaczki i praca programisty są na tyle
różne, że dowolna analogia zawali się jak zaczniesz ją rozbierać.

Tutaj jest analogia tylko taka, że kod produkowany przez parę
programistów ma szanse mieć lepsze parametry, niż kod produkowany przez
każdego z tych programistów oddzielnie.

Być może analogia załamuje się na sytuacji, gdzie programiści co prawda
na ogół pracują solo, ale sobie pomagają. Problem wtedy jest taki, że
jeśli sobie pomagają rzadko i krótko to to niewiele daje, a jeśli sobie
pomagają dużo i często to ma praktycznie wszystkie wady programowania
parami, plus dodatkowo taką, że częste przełączanie kontekstów powoduje
utratę produktywności samo z siebie.

do góry