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