Andrzej Jarzabek <a...@g...com> napisał(a):

> Na pewno jednak też zdajesz sobie sprawę, że niezależnie od strat
> spowodowanych w produkcji, znajodwanie i naprawianie błędów w programach
> jest nieproporcjonalnie bardziej prachochłonne niż pisanie nowego kodu.
Zart?

Mozna tak ogolnie powiedziec w oderwaniu od konkretnego przypadku?
Czasami lepiej jest napisac na nowo, a czasami lepiej poprawic.

Pisalem na nowo glownie poto zeby miec druga (trzecia) wersje i
sprawdzic czy daja te same wyniki. W ekstremalnej optymalizacji tez
dochodzilem do wniosku ze zmian bedzie az tak duzo, ze lepiej przepisac
niemal na nowo. Podobnie gdy dochodzilem do wniosku ze oplaca sie zmienic
interfejsy komunikacyjne... wtedy tez prawie pisalo sie na nowo.

Ale w zwyklchy aplikacjach, gdy najbardziej liczy sie zysk ze sprzedazy w
stosunku do kosztow wykonania to rzadko sie oplaca pisanie duzych
fragmentow od nowa, a moze nigdy sie nie oplaca.

Pozdrawiam


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

do góry

On 19/02/2012 14:33, Bronek Kozicki wrote:
> On 19/02/2012 12:31, Andrzej Jarzabek wrote:
>>
>> Druga sprawa jest taka, że to, co opisujesz jest tylko możliwe wtedy,
>> kiedy masz innych członków zespołu pracujących nad tym samym, co ty. A
>> to ma te same wady, które są przypisywane programowaniu parami.
>
> różnica polega na tym, że każdy z członków zespołu może w danym momencie
> pracować nad innym zadaniem, i tylko okazjonalnie poświęcić swoją uwagę
> zadaniom kolegów.

W takiej sytuacji jest kilka problemów:

Skoro kolega zajmuje się czymś innym, to niekonieczenie ma orientację w
tym, co robisz, żeby jakkolwiek pomóc. Więc musi się wdrożyć w tematem,
potem musi się zastanowić nad twoim problemem, potem ci powiedzieć, co
wymyślił. To wszystko też zajmuje czas, a zanim to się stanie, to ty
możesz co najwyżej samemu się zastanawiać nad rozwiązaniem swojego
problemu. W końcu jeśli wymyślisz lepsze rozwiązanie, to jego czas
został zmarnowany, jeśli jego rozwiązanie jest lepsze, a ty, czekając na
niego zacząłeś już implementować swoje, gorsze, to musisz pozmieniać to,
co właśnie zrobiłeś.

Kolejną istotną sprawą jest czas przestawienia się, zmiany kontekstu.
Jeśli twój kolega pracuje nad czymś innym, ale odrywa się od swojej
pracy, żeby tobie pomóc, to powrót do stanu wysokiej produktywności przy
tym, co robił wcześniej, zajmie mu sporo czasu. Szacuje się, że
każdorazowy "context switching" to strata kilku roboczogodzin. Żeby nie
było, że to tylko moje zdanie, to odsyłam znowu do "Peopleware".

> A to że nad jednym projektem pracuje więcej niż jedna
> osoba, nie ma żadnego związku z programowanie parami (zdarzało mi się to
> drugie też) tylko to zdrowy rozsądek.

Problem jest taki, że w jednym projekcie jest zwykle wiele oderwanych od
siebie tematów i zadań. To, że ktoś pracuje nad modelem GUI do tego
samego produktu, nie znaczy, że będzie miał cokolwiek do powiedzenia w
temacie zrównoleglenia obliczeń.

do góry

On 19/02/2012 15:45, A.L. wrote:
> Ja mialem kiedyc na intervice takiego goscia, ktory jak twierzil jest
> wybitnym ekspertem od C++ i zadal dobrze ponad 100 tysiecy dolcow
> rocznie. N pytanei i wyjatki, powiedziel bez krepacj ize nei zna. Gdy
> zaczalem drazyc, powiedzial ze "C++ jest zbyt skomplikowany zeby jeden
> czlowwiek go opanowal. Wiec jeden zna wyjatki, a drygi templates i tak
> dalej. A sztuka zbudowanai zespolu polega na tym zeby wszyscy znali
> calosc".

niezłe - chyba będę cytował :)


B.

do góry

On 19/02/2012 19:06, M.M. wrote:
> Andrzej Jarzabek<a...@g...com> napisał(a):
>
>> Na pewno jednak też zdajesz sobie sprawę, że niezależnie od strat
>> spowodowanych w produkcji, znajodwanie i naprawianie błędów w programach
>> jest nieproporcjonalnie bardziej prachochłonne niż pisanie nowego kodu.
> Zart?
>
> Mozna tak ogolnie powiedziec w oderwaniu od konkretnego przypadku?
> Czasami lepiej jest napisac na nowo, a czasami lepiej poprawic.

Nie mówię, że w sensie - "jak jest błąd, to wyrzucić wszystko i napisać
od nowa" - to absurd. Mówię o tym, że w ileś tam dni można napisać
całkiem sporo linii kodu, ale nietrudno też w tym kodzie popełnić kilka
błędów takich, że poprawienie jednego z nich też zajmie kilka dni.

do góry

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?

Moze jestes taki dobry ze nawet 10 osob nie poda lepszego
rozwiazania?

Pozdrawiam


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

do góry

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?

pzdr
bartekltg

do góry

On 19/02/2012 15:45, A.L. wrote:
>
> Programwoanei parami i XP zostalo wymyslone pzrez kretynow dla
> kretynow. Proponuje pamietac ze zostalo ono wymyslone w trakcie takieg
> ospobie projektu w ktorejs z firm samochodowych. Projekt calkowicie
> upadl, a caly zespol zostl wyrzucony na tak zwana "zbita trwarz".
> Poniewaz guru mial jakby spalone w przemysle, postanowil zostac Guru.
> I owszem, w swoicn memuarach pisal na temat owego projektu: "Yes,
> project failed, but methodology was right".

Oczywiście jakby kogoś interesowały takie pierdoły jak fakty, to ten
"guru" to Kent Beck, który dzisiaj pracuje m.in. jako programista w
Facebooku, a jego kretynizm przejawia się m. in. tym, że wymyślił
również Test Driven Development i jest współtwórcą JUnit.

System, o którym mowa, Chrysler Comprehensive Compensation, został
wdrożony do produkcji w 1997 roku, z dwumiesięcznym opóźnieniem.
Problemem były dalsze fazy wdrożenia, które się nie udały - Beck
twierdzi że (w skrócie) z powodu konfliktu między działami płac
kierownictwem IT. Oczywiście być może kłamie i zawiniła jego indolencja,
ale jako komuś, kto przez parę ładnych lat pracował w dużych
korporacjach, jego wersja nie wydaje mi się szczególnie
nieprawdopodobna. A fakt, że Chrysler miał mergera w 1998 (żeby nie
powiedzieć że został przejęty), jak i dalsza historia firmy
DaimlerChrysler skłania mnie do tego, żeby jednak w tej kwestii wierzyć
Beckowi.

Wszystko to łatwo sprawdzić w powszechnie dostępnych źródłach informacji.

do góry

On Sun, 19 Feb 2012 19:18:08 +0100, szyk <s...@o...pl> wrote:

>
>> "Praca parami" to nie relacja "dyrektor-zastepca". No i ciekawe by
>> bylo gdyby kazdy programista mial "zastepce".
>
>Co w tym dziwnego? Co prawda sam nie widziałem czegoś takiego, ale mogę
>sobie wyobrazić, że jakiś "super-mistrz-zen" vel "starszy programista"
>ma "do swojej dyspozycji" kilku "młodszych programistów" którzy
>wyczesują dla niego różne trzeciorzędne tematy (np. przygotowanie
>środowiska po instalacji systemu, albo oskrypcenie jakiejś czynności,
>opracowanie wersji na inne systemy, robienie instalatorów, podczepianie
>zewnętrznej biblioteki pod fasadę zdefiniowaną przez "mistrza"). Mi by
>się to wydawało normalką tak jak w zakładach rzemieślniczych "mistrz" i
>"uczniowie". Poza tym w każdej poważnej firmie musi być "zastępca
>programisty" na okoliczność sytuacji życiowych (urlop, choroba,
>odejście), bo inaczej co? Programista znika i firma stoi?

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.

Cmentarze pelne sa "niezastapionych ludzi".

A jak idzie o "pojscie na chorobe"?... Jak zaczalem pracowac w pewnej
firmie, dosyc dawno temu, na "dzien dobry" dostalem 100 tysiecy linii
Smaltalka z propozycja abym przyspieszyl wykonywane tak ze 2 czy 3
razy, i to szybko, bo jak nei to stracimy kontrakt. Oryginalny
producent kodu byl sie zwolnil i poszedl pracowac gdzie indziej. No i
co? No i nic. To sie nazywa "propozycja nei do odrzucenia"

Natomiast podzial zadan, i owszem jest, ale nie dokladnei taki jak
piszesz. Ja na przykald robie prototyp - ten prototyp wymaga dosyc
duzej wiedzy, matematycznej zwlaszcza, ale nie uwzglednai zadnych
detali "rzeczywistego" problemu. Albowiem owe detale opoznialyby prace
nad koncepcja i bylyby neispecjalnie istotne. Prototyp uwzglednai
tylko glowne cechy problemu. Prototyp dostaje dwoch mlodziencow ktorzy
dokonuja "produktyzacji', na przykald zamiast "szkeletowego domain
model" uzywaja prawdziwy, podlaczaja do bazy danych, hibernate, itede.
i testuja na produkcyjnych danych. Oczywiscie mam od nich "feedback" i
czasami musze korygowac prototyp[ i testowac te korekcje.

Dlaczego ja sam nei robie produktyzacji? Ano bo moja godzina kosztuje
za duzo zebym sie zajmowal zagadnieniami trywialnymi, a poza tym,
trzeba robic nastepny prototyp.

A co bedzie jak sie zwolnie? Ano, nic. Ci mlodziency znaja problem na
tyle, ze to co jest dokoncza i beda mogli rozwijac dalej. Nowego
prototypu nowej funkcjonalnosci nie bedzie, ale bez tego firma
przezyje i to dosyc dlugo.

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
przypadku by to oznaczal oze obaj maja umiejetnosci ponizej poziomu.
Bo gdyby mieli takie umiejetnosci jak tzreba, to by sie natychmiast
zatrudnili za pelna pensje w firmie po drugiej stronie ulicy.

A koszt projektu estymuje sie z grubsza jako ilocyn kosztu pracownika
produkcujnego pzrez ilosc pracownikow produkcyjnych. Koszt pracownika
produkcyjnego to 2 - 3 razy jego pensja, i ejst to liczba pilnie
stzrezona przez firme, albowiem to decyduje o kosztach projektu.
Konkurencja nei ma prawa tej liczby znac.

A.L.

do góry

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.

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.

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ąć.

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

do góry

On Sun, 19 Feb 2012 19:24:23 +0000, Bronek Kozicki <b...@s...net>
wrote:

>On 19/02/2012 15:45, A.L. wrote:
>> Ja mialem kiedyc na intervice takiego goscia, ktory jak twierzil jest
>> wybitnym ekspertem od C++ i zadal dobrze ponad 100 tysiecy dolcow
>> rocznie. N pytanei i wyjatki, powiedziel bez krepacj ize nei zna. Gdy
>> zaczalem drazyc, powiedzial ze "C++ jest zbyt skomplikowany zeby jeden
>> czlowwiek go opanowal. Wiec jeden zna wyjatki, a drygi templates i tak
>> dalej. A sztuka zbudowanai zespolu polega na tym zeby wszyscy znali
>> calosc".
>
>niezłe - chyba będę cytował :)
>
>
>B.

Nie jest "copyrighted", na dodatek jest prawdziwe, niestety...

A.L.

P.S. Czesto na samym poczatku interview delikwent zaznacza: "ale ja
bez watkow". Na pytanie "dlaczego" padaja rozne odpowiedzi.
Najczesciej ze "tego nie brali w szkole" albo ze "to jest sposob na
klopoty"

do góry