konto usunięte

Temat: Kto płaci za dobry kod?

Marcin M.:
Problem w tym, że bardzo ciężko zmierzyć i ocenić postęp tej degradacji, ani określić kiedy i jak mocno to zaboli. Są systemy, które z różnych względów(małe skomplikowanie, stały zespół, mała ilość zmian, dobrze narzucona architektura etc...) pozostają w formie przez wiele lat, bez jakiejkolwiek kontroli kodu.

Dla małych systemów możesz robić co Ci się podoba. I tak zwykle nie będzie tragicznie (mały system, łatwo wszystko ogarnąć, niski koszt wejścia itp).
Przypuśćmy, że w dodatku do starego jest tworzony nowy system i po pierwszej zmianie programiści krzykną o x kasy na rewizje jego kodu. Kierownictwo najprawdopodobniej uzna to za ekstrawagancje działu IT. Przecież wszystko działa, jedyne co trzeba to "kilka małych poprawek".

Kilka poprawek to i zwykle koszt rewizji nieduży. A czy to nie ma być tak, ze masz oszczędzać robiąc rewizję, a nie żądać dodatkowo pieniądze ? Przecież rewizja ma sens wtedy kiedy wyłapuje defekty (i dane pokazują, że jest to jeden z najlepszych sposobów - czyt. najtańszych). Skoro tak to wcześniej te błędy szły dalej i kasa była ładowana w dział QA albo w tworzenie fixpacków. Jedno i drugie rozwiązanie ostatecznie jest droższe i bardziej ociężałe (a to drugie dodatkowo redukuje zaufanie klientów).
Ponadto jest stary system, który tego nie wymagał, więc wszystkie prezentowane dane nie będą przekonujące. Co gorsze, nawet jeśli kierownictwo będzie świadome problemu, to może się łudzić, że nie będzie potrzeba dużo więcej zmian, i że lepszym wyjściem będzie zostawienie syfu i "przeforsowanie" ostatnich zmian. Później okazuje się, że takie myślenie jest od pięciu wersji kodu, co dzieje się dalej dokładnie wiecie.

Nie od razu Kraków zbudowano. Nie jest pożądanym nagłe zmienianie procesu developerskiego z dnia na dzień (nawet na lepszy). Wszystko zmiany procesowe wprowadza się stopniowo (żeby zredukować koszt wejścia - bo zawsze na początku będzie spadek wydajności). Zresztą jak nie będzie rezultatów to nie ma co wprowadzać. Code review przecież nie robi się dla przyjemności.
Z tego co doświadczyłem, najlepszym rozwiązaniem takiego błędnego koła, jest świadoma osoba pół-techniczna w kierownictwie.

Albo team lead mający repekt w organizacji (dobra historia osiągnięć). Z moich doświadczeń, skuteczniejszy od tego powyżej (bo w odróżnieniu od tego drugiego wie co mówi ;)Ten post został edytowany przez Autora dnia 03.06.13 o godzinie 17:31

konto usunięte

Temat: Kto płaci za dobry kod?

Problem w tym, że bardzo ciężko zmierzyć i ocenić postęp tej degradacji, ani określić kiedy i jak mocno to zaboli.

To pozorny problem.. każda degradacja kiedyś (raczej szybciej niż później) bardzo zaboli.
Są systemy, które z różnych względów(małe skomplikowanie, stały zespół, mała ilość zmian, dobrze narzucona architektura etc...) pozostają w formie przez wiele lat, bez jakiejkolwiek kontroli kodu.

Tak, i te systemy były dobrze zaplanowane. To, czy system "pozostaje w formie" nie jest kwestią przypadku. Niestety, mało kto posiada umiejętność planowania.
Przypuśćmy, że w dodatku do starego jest tworzony nowy system i po pierwszej zmianie programiści krzykną o x kasy na rewizje jego kodu. Kierownictwo najprawdopodobniej uzna to za ekstrawagancje działu IT. Przecież wszystko działa, jedyne co trzeba to "kilka małych poprawek". Ponadto jest stary system, który tego nie wymagał, więc wszystkie prezentowane dane nie będą przekonujące. Co gorsze, nawet jeśli kierownictwo będzie świadome problemu, to może się łudzić, że nie będzie potrzeba dużo więcej zmian, i że lepszym wyjściem będzie zostawienie syfu i "przeforsowanie" ostatnich zmian. Później okazuje się, że takie myślenie jest od pięciu wersji kodu, co dzieje się dalej dokładnie wiecie.

Kierownictwo ma problem ? Straszne ...
Z tego co doświadczyłem, najlepszym rozwiązaniem takiego błędnego koła, jest świadoma osoba pół-techniczna w kierownictwie.

Świadoma ale pół techniczna ? A może półświadoma i techniczna....
Bzdury...
Marcin Mroczkowski

Marcin Mroczkowski Programista JAVA/JEE

Temat: Kto płaci za dobry kod?

Jakub W.:
Problem w tym, że bardzo ciężko zmierzyć i ocenić postęp tej degradacji, ani określić kiedy i jak mocno to zaboli.

To pozorny problem.. każda degradacja kiedyś (raczej szybciej niż później) bardzo zaboli.

Wiem, że każdy spadek jakości kodu w końcu wychodzi, tylko nie zawsze to boli to na tyle, żeby przeważyć krótkofalowe korzyści z pisania "na szybko". Osobiście pracowałem w systemie bardzo zdegradowanym i pod względem jakości implementacji kodu, aż po brak jednoznacznej architektury i o dziwo ten system ma się dobrze. Fenomen moim zdaniem wynikał ze stałości i zgrania zespołu, ale oczywiście w takim przypadku ciężko znaleźć jednoznaczną przyczynę.
Są systemy, które z różnych względów(małe skomplikowanie, stały zespół, mała ilość zmian, dobrze narzucona architektura etc...) pozostają w formie przez wiele lat, bez jakiejkolwiek kontroli kodu.

Tak, i te systemy były dobrze zaplanowane. To, czy system "pozostaje w formie" nie jest kwestią przypadku. Niestety, mało kto posiada umiejętność planowania.

Tutaj ma Pan całkowitą rację, dobrze zaprojektowany system jest znacznie bardziej odporny na kulawe zmiany i tym samym ma większe szanse się udać, Nie zmienia to faktu, że wszystko da się zarzucić warstwą niepasującego do architektury kodu.
Przypuśćmy, że w dodatku do starego jest tworzony nowy system i po pierwszej zmianie programiści krzykną o x kasy na rewizje jego kodu. Kierownictwo najprawdopodobniej uzna to za ekstrawagancje działu IT. Przecież wszystko działa, jedyne co trzeba to "kilka małych poprawek". Ponadto jest stary system, który tego nie wymagał, więc wszystkie prezentowane dane nie będą przekonujące. Co gorsze, nawet jeśli kierownictwo będzie świadome problemu, to może się łudzić, że nie będzie potrzeba dużo więcej zmian, i że lepszym wyjściem będzie zostawienie syfu i "przeforsowanie" ostatnich zmian. Później okazuje się, że takie myślenie jest od pięciu wersji kodu, co dzieje się dalej dokładnie wiecie.

Kierownictwo ma problem ? Straszne ...

Tak Panie Jakubie, tutaj problem ma nie tylko kierownictwo, ale i cała firma. Przypomnę może, o czym jest ta dyskusja. Staramy się dociec dlaczego, aż tak często w firmach pozwala na istnienie kodu, napisanego poniżej jakiejkolwiek krytyki, który później powoduje horror w utrzymaniu.
Nawiązałem tutaj do wypowiedzi Sebastiana i Michała, dotyczącej sposobu "udowodnienia" przed kierownictwem, że kontrola jakości kodu jest potrzebna. Przytaczając tą przykładową sytuacje, chciałem pokazać, jak łatwo można ten problem zbagatelizować. Podobny schemat zaobserwowałem, już w nie jednej firmie.
Następnym razem proszę o sensowną argumentację, bo te jedno lekceważące zdanie, jest całkowicie nie na miejscu.
Z tego co doświadczyłem, najlepszym rozwiązaniem takiego błędnego koła, jest świadoma osoba pół-techniczna w kierownictwie.

Świadoma ale pół techniczna ? A może półświadoma i techniczna....
Bzdury...

Tym fragmentem udowadnia Pan kompletny brak chęci zrozumienia, tego co mam do przekazania i i po prostu wyszydza Pan to co napisałem. "Pół-techniczna" osoba, to moim rozumieniu osoba, która posiada umiejętności techniczne(prawdopodobnie dawny szeregowy programista), ale i zarazem będąca na szczeblu kierowniczym, która ma wpływ na podejmowane decyzje. Użyłem nieprecyzyjnego i rzadkiego określenia, ale nie jest to powód do nabijania się z wypowiedzi.

Mam wrażenie, że od Pana pierwszej wypowiedzi, w której dostrzegł Pan pozorną sprzeczność ma Pan potrzebę negacji wszystkiego co napiszę. Odpisałem najbardziej rzeczowo jak mogłem, w zamian dostałem porcję szydzenia. Nie tak ta dyskusja powinna wyglądać.

konto usunięte

Temat: Kto płaci za dobry kod?

Marcin M.:
Problem w tym, że bardzo ciężko zmierzyć i ocenić postęp tej degradacji, ani określić kiedy i jak mocno to zaboli. Są systemy, które z różnych względów [...] pozostają w formie przez wiele lat, bez jakiejkolwiek kontroli kodu.
Zgadza się. Systemy takie działają i dla wielu niezauważalna jest utrata jakości. Jednak nieumiejętność dostrzeżenia problemu nie oznacza, że go nie ma, oznacza jedynie tyle, że nie potrafimy zauważyć objawów.
A tych jest kilka z tego typu aplikacjami:
małe skomplikowanie,
Jeżeli coś żyje odpowiednio długo, to wymaga ulepszeń, jeżeli produkt ma być konkurencyjny i nawet przy braku rozbudowy samej logiki, aplikacja "obrasta" w zależności i relacje, w ilość kodu, klas, itp. W takim wypadku stopień złożoność zwiększa się coraz szybciej, z każdą nową linijką kodu i dodaną zależnością.
stały zespół
jest plusem do momentu, gdy odejście któregokolwiek z jego członków będzie dotkliwym ciosem dla firmy (widziałem to wielokrotnie). Wiedza na temat produktu znika wraz z pracownikiem, a jakość kodu nie pozwala wdrożyć się w rozsądnym czasie nowej osobie bez pomocy innych.
Takie uzależnienie jest złe dla firmy, ale również jest dowodem na to, że coś dzieje się złego z aplikacją.
mała ilość zmian
Tu się zgadzam, pod warunkiem, że ilość ich nie wynika bezpośrednio z niemożności implementacji większych zmian.
dobrze narzucona architektura
Która w przypadku rozwijania się aplikacji rozrasta się w tylu kierunkach i na tyle różnych sposobów, że po pewnym czasie umiera śmiercią naturalną lub jest zakopana pod gruzem kodu, który powstał później. I to bez względu na to, czy zespół się zmienia czy nie. Ludzie się rozwijają, uczą, poznają nowe rzeczy i to, co było świetnym rozwiązaniem rok temu, jest tym, czego nie stworzyliby obecnie.

Jedną z istotnych rzeczy, na którą warto spojrzeć to tempo "wzrostu" aplikacji.
W takich projektach spada, z cyklu na cyklu coraz bardziej i coraz wyraźniej. I zarząd może nie zauważać patrząc na chwilę obecną, bo zespół nadal coś produkuje. Jednak, gdy popatrzą na statystyki dotyczące całego "życia" aplikacji, to zazwyczaj okazuje się, że po pewnym czasie, przy dodaniu nowych osób do zespołu, zwiększeniu umiejętności starych, tworzą coraz mniej, a zmiany, które wprowadzają są coraz mniej istotne.
I o ile taka zależność jest właściwie regułą dla każdego projektu, to w przypadku braku dbałości o jakość, linia na wykresie spada drastycznie.

Powyższe punkty oczywiście nie będą prawdziwe w przypadku dbania o jakość kodu, architektury, aplikacji jako całości. A przynajmniej nie będą miał tak wielkiego i negatywnego wpływu na rozwój.

Z tego co doświadczyłem, najlepszym rozwiązaniem takiego błędnego koła, jest świadoma osoba pół-techniczna w kierownictwie.
Tu popieram Pawła.
Jeżeli lider zapracował sobie na zaufanie, to zarząd (czy jakkolwiek nazwiemy osoby decyzyjne i zajmujące się częścią biznesową) są skłonne posłuchać jego/jej rad, gdyż niejednokrotnie już im udowodnił (pośrednio czy też bezpośrednio), że warto słuchać jego rad.
Problem z osobami pół-technicznymi (czy też technicznymi) w kierownictwie jest to, że często lubią pchać się z butami do implementacji, a utrzymanie ich zapędów w ryzach kosztuje wiele wysiłków. Choć oczywiście nie jest to reguła.
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: Kto płaci za dobry kod?

A czy programistę powinno interesować kto płaci za "dobry kod"? Programista powinien być w stanie oszacować ile
czasu zajmie mu napisanie "dobrego kodu" realizującego określoną funkcjonalność i napisać "dobry kod" w tym czasie, który oszacował. Na wejściu taki programista powinien dostać wynik analizy + projekt i wziąć się do pracy ;)

Kto zapłaci i ile za ten kod, powinno interesować kogoś kto będzie sprzedawał. Ten ktoś ma możliwość sterowania
ceną (upusty/niższa marża/etc.) oraz innymi parametrami oferowanego produktu (wydłużony okres gwarancji, czas reakcji na zgłoszenia, kolor ;) etc.)

Jak klient ma wybierać między produktem A oraz produktem B, dostarczających tej samej funkcjonalności, to zapewne wybierze ten, który jest tańszy, chyba, że różnica w cenie nie jest wielka, zaś z jednym z produktów związane są "inne korzyści".

Produkty/usługi, które nie są konkurencyjne zapewne znikną z rynku. Niewykluczone, że producent również.
Michał Pyclik

Michał Pyclik Architekt
Oprogramowania,
Biuro Projektowania
Systemów Cy...

Temat: Kto płaci za dobry kod?

Problem z osobami pół-technicznymi (czy też technicznymi) w kierownictwie jest to, że często lubią pchać się z butami do implementacji, a utrzymanie ich zapędów w ryzach kosztuje wiele wysiłków. Choć oczywiście nie jest to reguła.
Otóż to! Chyba jednak reguła :)
A czy programistę powinno interesować kto płaci za "dobry kod"? Programista powinien być w stanie oszacować ile
czasu zajmie mu napisanie "dobrego kodu" realizującego określoną funkcjonalność i napisać "dobry kod" w tym czasie, > który oszacował. Na wejściu taki programista powinien dostać wynik analizy + projekt i wziąć się do pracy ;)

Mnie chodzi bardziej z punktu widzenia pracownik-pracodawca. W wielu firmach liczy się przede wszystkim wydajność, wręcz nawet są gotowi zapytać na rozmowie ile linii kodu na minutę piszesz. Jednak żeby napisać coś dobrze, potrzeba czasem znacznie więcej czasu niż do "po prostu" napisania. Pomijam tu zupełnie aspekt ambicji - dobrze jest dobić coś ciekawie, z głową, natomiast klepanie kodu na pałę, żeby działało, to trochę tak, jak na kasie w TESCO... (bez obrazy ;))

konto usunięte

Temat: Kto płaci za dobry kod?

Paweł Grzegorz K.:
A czy programistę powinno interesować kto płaci za "dobry kod"?
Oczywiście, że powinno, bo dobremu programiście (lub takiemu, który chciałby takim zostać) powinno zależeć na tym, aby w firmach dbających o jakość pracować. Dlaczego? Bo przy dużych projektach to się zawsze opłaca, czas włożony w jakość nigdy nie jest czasem straconym i nie chodzi o to, że on się zwraca po pewnym czasie, on po pewnym okresie życia projektu (w porównaniu do takiego, o którego jakość nie zadbano) zaczyna na siebie zarabiać.
Każdy chce się rozwijać, a dużo lepiej uczyć się dobrych praktyk, wzorców i rozwiązań, niż grzebać się w nieskończoność w tragicznych rozwiązaniach.
Programista powinien być w stanie oszacować ile
czasu zajmie mu napisanie "dobrego kodu" realizującego określoną funkcjonalność i napisać "dobry kod" w tym czasie, który oszacował.
Jakość kodu to nie tylko, to co piszesz, to także aktywności, które mają miejsce poza faktyczną implementacją (jeszcze nie zakończona seria, ale: http://sebastian-malaca.blogspot.com/search/label/wiec... ) i programista nie zawsze ma możliwość zdecydować, czy będzie mógł sobie pozwolić na owe aktywności (testowanie, refaktoring, projektowanie itp.)
Tak więc taka estymacja to mrzonka (jeżeli szef nie płaci za jakość), bo możesz usłyszeć, żeby nie testować, nie robić review kodu itp., bo to "jedynie strata czasu".
Na wejściu taki programista powinien dostać wynik analizy + projekt i wziąć się do pracy ;)
Świetnie, że powinien, a jak często tak się dzieje? A nawet jeśli, to i tak wiele rzeczy pozostaje do wymyślenia i rozwiązania przez zespół programistów. Ich praca, nawet przy takim założeniu, nie sprowadza się do przepisania UML na kod, implementacja to spore wyzwanie nawet z bardzo dobrym projektem. I wiele razy można zgubić się z jakością.
Kto zapłaci i ile za ten kod, powinno interesować kogoś kto będzie sprzedawał. Ten ktoś ma możliwość sterowania
ceną
Ale nie może ją sterować w nieskończoność. Musi opłacić czas programistów, a dbanie o jakość kodu tego czasu wymaga (testy, refaktoryzacja, code review) i często to tutaj decydują się na "cięcie kosztów". Dlaczego w cudzysłowie? Bo jest to jedynie iluzoryczne cięcie, ponieważ w pewnym momencie, przy wprowadzaniu zmian i nowych funkcjonalności, okaże się, że te "zaoszczędzone" pieniądze nagle uciekają przez palce.
oraz innymi parametrami oferowanego produktu
(wydłużony okres gwarancji, czas reakcji na zgłoszenia, kolor ;) etc.)
Support? Maintenance? Przecież za to też trzeba komuś zapłacić, więc gdzie tu miejsce na cięcie kosztów?
Jak klient ma wybierać między produktem A oraz produktem B, dostarczających tej samej funkcjonalności, to zapewne wybierze ten, który jest tańszy, chyba, że różnica w cenie nie jest wielka, zaś z jednym z produktów związane są "inne korzyści".
Jeżeli mówimy o stronach internetowych, czy projektach na dwa-trzy miesiące góra, to zgadzam się. Jednak przy większych aplikacjach często zdarza się tak, że klient po pewnym czasie, gdy zaczyna dostrzegać, że każda kolejna zmiana to coraz większa droga przez mękę, rezygnuje. Często wraca do tej drugiej firmy, która pomimo wyższych kosztów gwarantuje lepszą jakość.
Produkty/usługi, które nie są konkurencyjne zapewne znikną z rynku.
O konkurencyjności nie tylko decyduje cena, ale często właśnie jakość, tym bardziej, gdy w grę wchodzą duże pieniądze.Ten post został edytowany przez Autora dnia 04.06.13 o godzinie 15:05

Temat: Kto płaci za dobry kod?

Osobiście Panowie widzę dwa standardowe przypadki.

1) Właścicielem produktu jest klient. W takim przypadku "jeśli to nie jest soft do sterowania elektrownią atomową" to ilość śmieci w kodzie bardzo szybko przekracza akceptowalny poziom nawet jeśli przy zarządzie jest ktoś kto ma pojęcie ponieważ jego głos stanowi tylko część decyzji.

2) Kiedy właścicielem softu jest IT na własnym rozrachunku (między innymi przypadek Pawła) wtedy ilość śmieci jest minimalna ponieważ IT posiada pełną decyzyjność ale też i pełną odpowiedzialność.

Można szukać przypadków pośrednich ale generalnie wszystko sprowadza się do tego po której stronie leży odpowiedzialność. Jeśli po stronie "biznesu" to większe prawdopodobieństwo, że będzie śmieć jeśli po stronie IT to większe prawdopodobieństwo, że będzie dobrze.

Zatem za dobry kod płacą ci, którym na tym zależy bo dobry kod to kod łatwy w utrzymaniu a im łatwiejszy w utrzymaniu tym więcej można zarobić z samej oszczędności czasu :)Ten post został edytowany przez Autora dnia 04.06.13 o godzinie 15:24
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: Kto płaci za dobry kod?

Dla klienta "jakość" (stopień w jakim produkt spełnia oczekiwania klienta?) znaczy coś innego niż "jakość kodu" dla programisty (stopień zgodności ze zdefiniowanymi w ramach procesu produkcyjnego standardami?).

To jak ktoś sobie ustawi proces produkcyjny i w jego ramach kontrolę jakości (w szczególności standardy, które powinny być spełnione i miary), to sprawa tego kogoś. Za efekt końcowy płaci klient (czy to wewnętrzny czy zewnętrzny). Jak proces jest wątpliwej jakości, to faktycznie mamy do czynienia ze sztuką... rzeźbienia w materiale
miękkim ;-)

Kupując samochód nie interesuję się czy śrubki (kod) przeszły kontrolę jakości. Jak w trakcie użytkowania okaże się, że samochód psuje się bo śrubki są marnej jakości, to pewnie nie kupię więcej shitu marki XYZ i nie omieszkam podzielić się opinią ze znajomymi ;-) Albo, że jedyna szansa na naprawę, to wymiana znacznej części samochodu^*)

Nie sądzę, że dla programisty istotne jest czy produkt zamówił Kowalski czy Nowak. Powinno być istotne to, że napisał "dobry kawałek kodu", który realizuje poprawnie funkcjonalności, które zostały zamówione. Jeśli ma problem z akceptacją procesu produkcyjnego, to wg mnie powinien zgłosić zastrzeżenia do właściciela tegoż procesu albo poszukać sobie innej/lepszej pracy ;-)

Jeśli programista ma aspirację układania procesów wytwórczych, to może powinien odłożyć programowanie i rozwijać się w innym kierunku?

^*) na Discovery oglądałem program o zmaganiach inżynierów z Tata Motors Ltd z autami, które doświadczały samozapłonu (i nie chodziło o samoczynne uruchomienie silnika ;-) )

Temat: Kto płaci za dobry kod?

Paweł Grzegorz K.:

Kupując samochód nie interesuję się czy śrubki (kod) przeszły kontrolę jakości. Jak w trakcie użytkowania okaże się, że samochód psuje się bo śrubki są marnej jakości, to pewnie nie kupię więcej shitu marki XYZ i nie omieszkam podzielić się opinią ze znajomymi ;-) Albo, że jedyna szansa na naprawę, to wymiana znacznej części samochodu^*)

To jest klasyczny przykład odpowiedzialności po stronie producenta gdzie odpowiada on za cały proces od powstania samego pomysłu do wypuszczenia produktu końcowego i jego udoskonalanie. Przemysł samochodowy opanował tą sztukę do perfekcji. Takich przypadków w IT jest mało ale jak się trafiają to robią dobry stuff. Częściej wygląda to tak, że klient przychodzi i mówi chcę samochód, nie wiem ile chcę za niego zapłacić, nie wiem do czego ma służyć ale chcę go na wczoraj (przypadek skrajny ale spotykany) :) Możesz mieć najlepsze procedury, metodologie etc. ale jeśli klient nie chce w nich partycypować to i tak na końcu zamiast samochodu wyjdzie łopata.

Jest takie powiedzenie: Gorszy pieniądz wypiera lepszy.
Wiesław Młynarski

Wiesław Młynarski Programista Java

Temat: Kto płaci za dobry kod?

Marcin M.:
Problem w tym, że bardzo ciężko zmierzyć i ocenić postęp tej degradacji, ani określić kiedy i jak mocno to zaboli. Są systemy, które z różnych względów(małe skomplikowanie, stały zespół, mała ilość zmian, dobrze narzucona architektura etc...) pozostają w formie przez wiele lat, bez jakiejkolwiek kontroli kodu.

W tym pomaga sonar. http://www.sonarsource.org/ da się zmierzyć w pewien sposób.
Nie gwarantuje to w żadnym przypadku dobrego kodu, ale przynajmniej masz do dyspozycji metryki które wskazuję. "Crap" który został już stworzony i postęp jaki osiągasz w utrzymując system.
Na przykładzie mojej firmy, sonar pomógł znaleźć parę krytycznych błędów oraz zmierzyć aktualną poprawę kodu.
Wynikającą z wprowadzenia narzędzi jak checkstyle, formatterów, oraz szablonów kodu, liczby testów itd.
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: Kto płaci za dobry kod?

Piotr R.:

<ciach>
Częściej wygląda to tak, że klient przychodzi i mówi chcę samochód, nie wiem ile chcę za niego zapłacić, nie wiem do czego ma służyć ale chcę go na wczoraj (przypadek skrajny ale spotykany) :) Możesz mieć najlepsze procedury, metodologie etc. ale jeśli klient nie chce w nich partycypować to i tak na końcu zamiast samochodu wyjdzie łopata.
</ciach>

Trudno się nie zgodzić, ale w takim przypadku można zaoferować usługi w modelu T&M.
Klient uporządkuje sobie wizję, wymagania i będzie można rozmawiać dalej albo zarzucić projekt :-)
Jest takie powiedzenie: Gorszy pieniądz wypiera lepszy.
Z pustego Salomon nie naleje :-)

konto usunięte

Temat: Kto płaci za dobry kod?

Piotr R.:
Można szukać przypadków pośrednich ale generalnie wszystko sprowadza się do tego po której stronie leży odpowiedzialność. Jeśli po stronie "biznesu" to większe prawdopodobieństwo, że będzie śmieć
Nie zgodzę się, taka sytuacja jedynie świadczy o tym, że osoba, która komunikuje się z tym "biznesem" nie nadaje się do swojej pracy lub ma przed sobą sporo nauki.

Na "cięcie kosztów" dostawca decyduje się dobrowolnie, nikt go do tego nie przymusza, a on zawsze może powiedzieć klientowi, że muszą się na chwilę obecną pożegnać.
Naprawdę, warto dbać o jakość swoich produktów, bo w pewnym momencie zaczyna ona pracować na markę firmy. A im więcej klientów będzie zadowolonych ze współpracy, tym łatwiej przyszłym będzie znosić różnicę w cenie i częściej zdecydują się na "przepłacenie".
Piotr R.:
[...] Częściej wygląda to tak, że klient przychodzi i mówi chcę samochód, nie wiem ile chcę za niego zapłacić, nie wiem do czego ma służyć ale chcę go na wczoraj (przypadek skrajny ale spotykany) :) Możesz mieć najlepsze procedury, metodologie etc. ale jeśli klient nie chce w nich partycypować to i tak na końcu zamiast samochodu wyjdzie łopata.
I tutaj wchodzi do akcji osoba odpowiedzialna za kontakt z klientem i jeżeli nie uda się ustalić "za ile", "co" i jakiegoś realnego terminu przy akceptacji wszystkich rozwiązań, które stosuje firma, to czy powinna ona(firma) się zdecydować na tworzenie czegokolwiek dla takiego klienta? Przecież to strzelanie we własne kończyny!
Od początku zdajesz sobie sprawę, że to będzie problematyczny klient i dobrowolnie decydujesz się na stres swój i swoich pracowników, a to bezpośrednio wpływa na obniżenie produktywności. Niezależnie od tego jakie procesy w projekcie stosujesz.
Zazwyczaj kończy się na:
- niezrealizowanym projekcie lub projekcie niespełniającym oczekiwań
- zmęczeniu wszystkich
- niezadowoleniu klienta
To nie jest budowanie dobrego wizerunku.

A zaczyna się od ustępstw w jakości :) Ten post został edytowany przez Autora dnia 04.06.13 o godzinie 23:59

konto usunięte

Temat: Kto płaci za dobry kod?

Paweł Grzegorz K.:
To jak ktoś sobie ustawi proces produkcyjny i w jego ramach kontrolę jakości (w szczególności standardy, które powinny być spełnione i miary), to sprawa tego kogoś. Za efekt końcowy płaci klient (czy to wewnętrzny czy zewnętrzny). Jak proces jest wątpliwej jakości, to faktycznie mamy do czynienia ze sztuką... rzeźbienia w materiale
miękkim ;-)

Kupując samochód nie interesuję się czy śrubki (kod) przeszły kontrolę jakości. Jak w trakcie użytkowania okaże się, że samochód psuje się bo śrubki są marnej jakości, to pewnie nie kupię więcej shitu marki XYZ i nie omieszkam podzielić się opinią ze znajomymi ;-) Albo, że jedyna szansa na naprawę, to wymiana znacznej części samochodu^*)

A może jednak samochód i IT to nie jest dobra analogia :)
Poniższa historia wydarzyła się naprawdę - wszystkie imiona, fakty i zdarzenia zostały zmienione.

ROZDZIAŁ 1

- Proszę za mną panie Stefanie, prezes może teraz pana przyjąć.

Słowa pani Ilonki, zastępcy pana Ryśka - prezesa wielkiego warsztatu samochodowego - wzbudziły w Stefanie uczucie lekkiego podniecenia.
Stefan był o krok od otrzymania pokaźnej premii od prezesa spółdzielni i zakupu swojego wymarzonego dębowego kredensu na werandę, którego na pewno będą zazdrościć mu wszyscy sąsiedzi.
Wszystko zaczęło się dwa lata temu kiedy Zbyszek - prezes spółdzielni mieszkaniowej im. Bohaterów Stadionu Narodowego - wezwał do siebie Stefana i przedstawił mu wizję swojego nietuzinkowego projektu.

- panie Stefanie przedstawię teraz panu wizję swojego nietuzinkowego projektu. Otóż po ostatnich podwyżkach czynszu nasz komornik Wacław nie wyrabia się
ze zbieraniem zaległości. Wacław w przyszłym tygodniu kończy 60 lat i niestety nie ma już tych sił co kiedyś gdy mógł eksmitować trzy rodziny dziennie.
A, że Wacka wymienić nie możemy bo Wacek to wie dobrze jak u nas w spółdzielni rzeczy działają to wymyśliłem, że zbudujemy mu wózek - wie pan taki elektryczny
bo benzyna jest droga - wydatki podciągniemy jakoś pod budżet na ochronę środowiska i będzie git. I tutaj pan na scenie wchodzi panie Stefanie. Znajdzie pan jakiś porządny warsztat
i niech no nam zbudują taki wózek a jak mnie pan panie Stefanie nie zawiedzie to i jakaś nagroda się znajdzie.

Stefan popytał tu i ówdzie , poszukał w ogłoszeniach i znalazł solidnego wykonawcę - „Mech Ryszard Solutions” - duża, wydawało się solidna firma.
I chociaż początki nie były łatwe bo przez pierwsze pół roku pracownicy Ryśka pokazywali mu jakieś bloczki, rysunki kółek i jakichś dziwnie pokręconych śrubek. Po co mu to pokazywali? nie wiedział. Gówno go interesowały jakieś śrubki.
Koniec końców gdy zobaczył pierwszy jeżdżący model wysłał fotę do prezesa, który ostatnio robił się coraz bardziej nerwowy. Stefan pamiętał ten dzień gdyż właśnie wtedy po raz pierwszy w wyobraźni
poczuł zazdrość sąsiadów na widok jego zajebistego kredensu...

ROZDZIAŁ 2

Masywne drzwi gabinetu pana Ryszarda otworzyły się ukazując wszechstronne wnętrze wykończone w stylu gotycko-greckim.

- Panie Stefanie zapraszam do środka, co pana do mnie dzisiaj sprowadza? Jak sprawuje się nasz wózek.
- Dzień dobry panie Ryśku. Wózek? Wózek sprawuje się świetnie ale nastąpiło coś czego nie przewidzieliśmy. Ostatnio gdy
pan Wacek wracał sobie spokojnie po uczciwie przepracowanym dniu z zebranymi pieniędzmi - nie uwierzy pan co się stało -
jakieś niecne draby wpadły na wózek pana Wieśka i wyrwały mu torbę z pieniędzmi. Rozmawiałem z prezesem i stwierdziliśmy, że musimy zamontować na wózek jakiś
system ochrony dla pana Wieśka , wie pan jakieś miotacze ognia czy coś w tym stylu.
- świetnie panie Stefanie, świetnie. Zawołam Cześka, naszego specjalistę od skręcania i wkręcania tego i owego.

Stefan znał Cześka. To ten, który zawsze mówił, że wszystko jest pod kontrolą nawet wtedy gdy termin oddania wózka przesuwali po raz trzeci.
W drzwiach pojawił się pewny siebie jak zwykle Czesiek. Przez 5 minut nasłuchiwał się opowieścią Stefana i nowym wymaganiom co do miotaczy ognia.

- rozumiem panie Stefanie , to będzie kosztować bańkę.

Stefan przypomniał sobie o zaległych badaniach u laryngologa, przez chwilę wydawało mu się, że usłyszał "bańkę".

- ile to będzie kosztować?
- bańkę!

Stefan opadł na fotel. Wyobrażenie kredensu zaczęło blaknąć.

- czy was coś popierdoliło!
- o co panu chodzi panie Stefanie?
- jak to bańkę?
- ano tak to. Pana wózek nie jest przystosowany do montowania miotaczy ognia. W zasadzie pana wózek nie jest przystosowany do żadnego systemu obrony.
- (prezes mnie zajebie) ludzie czy was pojebało. Myślałem, że pracuję z profesjonalistami!
- niech się pan uspokoi, pierwotna specyfikacja nie zakładała montowania żadnego systemu obrony.
- skąd miałem wiedzieć, że będzie potrzebne coś takiego. Myślałem, że to wy jesteście specjalistami od wózków.
- cóż miotacze ognia to nie jest standardowe wyposażenie wózków...
- ale bańka?!?
- panie Stefanie terminy były mocno napięte. Mechanicy musieli na szybko powkręcać śrubki tu i ówdzie. Teraz będzie trudno to poodkręcać.
- co?!
- gdyby tylko zapłacił pan za pełną 5 letnią analizę to mielibyśmy czas porządnie zaplanować każdy gwint panie Stefanie

kurwa, kurwa, kurwa - myśli Stefana były dosyć prostolinijne w tym momencie. Jak prezes się dowie to go zajebie!
Nie ma mowy żeby zamówić nowy samochód - drugi raz wałek z dotacjami unijnymi nie przejdzie. Zresztą nie ma czasu.
Ale zaraz dlaczego wkręcanie śrubek to taki problem. Stefan widział kiedyś jak mechanicy siedzieli w swoich
boksach i skręcali śrubki - nie wydawało się to trudne. To Rysiek! Ta pijawka chce zedrzeć z niego ostatni grosz.
Trzeba poszukać kogoś innego - na pewno jest ktoś inny...

ROZDZIAŁ 3

"Firma Mietek Mechanics Consulting to pewny partner z bogatymi tradycjami". Taki napis zauważył Stefan nad drzwiami zakładu mechanicznego, który polecił mu znajomy na forum.
To byłą ostatnia deska ratunku dla Stefana - ostatnia nadzieja na kredens.

- panie Stefanie - głos Mietka nie przejawiał oznak entuzjazmu - niestety nie mam dobrych wiadomości. Pojazd, który nam pan przesłał to istny labirynt.
Gdy próbowaliśmy odkręcić lewy reflektor włączyły się wycieraczki a próba wymiany bezpieczników spowodowała wyparowanie płynu hamulcowego.

-(Stefan nie wiele rozumiał z tych słów)
-Ponadto te śrubki. Nie wiem kto wpadł na to aby tak to poskręcać. A tutaj widzi pan tę śrubkę - nikt nie używa takiej technologii wkręcania śrubek od 15 lat.
O a żeby odkręcić tę tutaj potrzebny będzie klucz 69 - niestety licencja na klucz 69 kosztuje. Oto nasza wycena
- zabij mnie..
- dwie bańki

Stefan opadł na podłogę. Nawet było mu wszystko jedno czy podjedzie po niego Łódzkie pogotowie...

ROZDZIAŁ 4

Być może Stefan potrzebował odpoczynku a być może to uderzenie o podłogę sprawiło, że jego umysł sam odnalazł rozwiązanie.
Spółdzielczy budżet na nowe technologie. Trzeba tylko zamontować dodatkowy monitor, który będzie sterował miotaczem ognia, nazwie się to
"ochrona 2.0" i rada spółdzielni na pewno to kupi!

- panie Stefanie cieszę się, że pan do nas wrócił - Rysiek w głębi duszy śmiał się szyderczo gdyż wiedział, że oni zawsze wracają - nie mają wyboru
Zapoznaliśmy się z pana koncepcja monitora sterującego - teraz to będzie kosztować półtorej bańki
- nie ważne, róbcie, róbcie jak najszybciej , Wacław nie może zbierać odsetek
- tylko tutaj jeden podpis i zaczynamy
- czy tym razem będę mógł wcześniej wypróbować wózek?
- my tak nie pracujemy panie Stefanie...

Stefan nie miał wyjścia. To będzie długa współpraca. Nie wiadomo jakie jeszcze niebezpieczeństwa niesie ze sobą świat rzeczywisty, świat tak bardzo nieprzewidywalny.
Stefan zrozumiał, ze to będzie długa współpraca....

EPILOG

Roman siedział zadowolony w swoim fotelu. Ten cały Stefan z tym dziwnym pomysłem na wózek. To będzie kolejny długoletni klient – oni wracają zawsze wracają.

- panie prezesie – Rozmyślania przerwał Czesiek – mamy mały problem. Okazało się, że blachy nie da się nagwintować tak jak planowaliśmy.
- To niech kręcą jak mogą
- Tak też im powiedziałem
- Więc w czym jest problem?
- Bolek z dziewiątki ma znowu rozterki natury moralnej. Narzeka, na bajzel wśród śrubek i chce wprowadzać jakieś dziwne narzędzia czy praktyki do kontroli jakości wkręcania.
- Hoho kurwa jeszcze co! Jak ma aspiracje do układania procesów wytwórczych to może powinien sobie poszukać nowej pracy
- Wydaje mi się, że Bolek ma w tym temacie duże doświadczenie może warto by się chociaż tym razem trochę temu przyjrzeć?
- Czesław, Czesław kiedy ty się nauczysz. Oni są tutaj od napierdalania a nie od myślenia. To najniższa kasta, oni maja się słuchać i nie marudzić. Weź go wyjeb.
- Bolka? A kto go zastąpi?
- Czesław – standardowo - zastąpi go skończona liczba praktykantów. Powiedz Ilonce żeby wrzuciła jakieś ogłoszenie o rekrutacji do młodej dynamicznej firmy pełnej wyzwań i rozwijającej się.

Czesław obrócił się na pięcie i wyszedł realizować zalecenia prezesa. Roman odetchnął i pomyślał w zadumie – ciekawe czy oni kiedyś zrozumieją, ciekawe czy kiedyś zrozumieją...

Temat: Kto płaci za dobry kod?

Sebastian M.:
Piotr R.:
Można szukać przypadków pośrednich ale generalnie wszystko sprowadza się do tego po której stronie leży odpowiedzialność. Jeśli po stronie "biznesu" to większe prawdopodobieństwo, że będzie śmieć
Nie zgodzę się, taka sytuacja jedynie świadczy o tym, że osoba, która komunikuje się z tym "biznesem" nie nadaje się do swojej pracy lub ma przed sobą sporo nauki.

Na "cięcie kosztów" dostawca decyduje się dobrowolnie, nikt go do tego nie przymusza, a on zawsze może powiedzieć klientowi, że muszą się na chwilę obecną pożegnać.
Naprawdę, warto dbać o jakość swoich produktów, bo w pewnym momencie zaczyna ona pracować na markę firmy. A im więcej klientów będzie zadowolonych ze współpracy, tym łatwiej przyszłym będzie znosić różnicę w cenie i częściej zdecydują się na "przepłacenie".
Piotr R.:
[...] Częściej wygląda to tak, że klient przychodzi i mówi chcę samochód, nie wiem ile chcę za niego zapłacić, nie wiem do czego ma służyć ale chcę go na wczoraj (przypadek skrajny ale spotykany) :) Możesz mieć najlepsze procedury, metodologie etc. ale jeśli klient nie chce w nich partycypować to i tak na końcu zamiast samochodu wyjdzie łopata.
I tutaj wchodzi do akcji osoba odpowiedzialna za kontakt z klientem i jeżeli nie uda się ustalić "za ile", "co" i jakiegoś realnego terminu przy akceptacji wszystkich rozwiązań, które stosuje firma, to czy powinna ona(firma) się zdecydować na tworzenie czegokolwiek dla takiego klienta? Przecież to strzelanie we własne kończyny!
Od początku zdajesz sobie sprawę, że to będzie problematyczny klient i dobrowolnie decydujesz się na stres swój i swoich pracowników, a to bezpośrednio wpływa na obniżenie produktywności. Niezależnie od tego jakie procesy w projekcie stosujesz.
Zazwyczaj kończy się na:
- niezrealizowanym projekcie lub projekcie niespełniającym oczekiwań
- zmęczeniu wszystkich
- niezadowoleniu klienta
To nie jest budowanie dobrego wizerunku.

A zaczyna się od ustępstw w jakości :)

Nie bardzo zrozumiałeś, co napisałem i mieszasz ze sobą dwie podstawowe formy rozliczeń: kiedy IT jest na swoim i kiedy IT jest integralną częścią firmy. Celowo piszę IT bo w praktyce to nie tylko development. Oba przypadki trzeba separować.

Kiedy IT jest na swoim może sobie prawie dowolnie dobierać klientów a z problemowymi przypadkami radzić środkami pośrednimi na przykład tak jak zaproponował Paweł Grzegorz Kwiatkowski by Time & Money. I wtedy nie trzymanie jakości to jak strzelanie sobie w głowę z haubicy ale ten przypadek już został omówiony i wszyscy się zgadzają.

Kiedy IT jest integralną częścią firmy przychodzi Pan Dyrektor Finansowy i mówi, że nie dostaniesz dodatkowych 160 roboczogodzin na rewizję systemu pod nową funkcjonalność a na pytanie dlaczego dostaniesz odpowiedź "Bo tak". I możesz sobie tłumaczyć i podawać racjonalne powody i podpierać się książkami i autorytetami i tabelkami jaki to jest wielki błąd z perspektywy przyszłego utrzymania systemu poparty cyferkami. Wiesz jak te wszystkie argumenty wyglądają w uszach takiego Dyrektora Finansowego, który się zaparł? Podpowiem: "ble ble ble ble". A przypominam, że Dyrektor Finansowy może zgodnie z prawem zablokować każdą decyzję Prezesa na wypadek jak by ci przyszło do głowy obejść jego decyzję. W tym akcie pierwsze skrzypce gra polityka a nie racjonalne myślenie. A jak już w przyszłości system obrośnie lakami i przestanie być rozwojowy to już nikt nie będzie pamiętał kto i kiedy podjął decyzje, które do tego doprowadziły. IT może tylko własnym ponadmiarowym wysiłkiem odwlekać ten dzień ale i tak on kiedyś nastąpi :)Ten post został edytowany przez Autora dnia 05.06.13 o godzinie 00:49

Temat: Kto płaci za dobry kod?

Paweł W.:

Hehe aż ciśnie się na usta tytuł serialu "Samo Życie" ;)

konto usunięte

Temat: Kto płaci za dobry kod?

Paweł W.:
<<ciach>>

Mistrz opowieści !! Hemingway się kryje.Ten post został edytowany przez Autora dnia 05.06.13 o godzinie 01:42

konto usunięte

Temat: Kto płaci za dobry kod?

Paweł W.:
[...]
Świetne :) Muszę link do twojego komentarza zapisać w ulubionych :)

Sporo w tym prawdy, jednak jest pewien problem, o którym zapewne Pan Roman nie myśli. Im większa ilość takich klientów (niezadowolonych i zdruzgotanych), tym gorsze opinie krążą po sieci/mieście, co sprawia, że liczba nowych klientów się zmniejsza, co prawda powoli, ale w perspektywie czasu zauważalnie.
Poza tym rozmiar klientów się nie zwiększa, bo Ci, którzy inwestują większe pieniądze przyłożą większą uwagę do szukania opinii, a nawet jeżeli się zdecydują, to ich niezadowolenie odbije się negatywnie na "marce", którą stworzyła firma Pana Romana.
W dodatku po pewnym okresie nikt nie będzie chciał dotykać produktów firmy i przy nich majstrować, bo ludzie, którzy posiadali wiedzę są już gdzie indziej, a wszelkiej maści praktykanci (choćby ich nieskończona ilość była) nie będą w stanie sprostać zrozumieniu tajemnic produktu. Co za tym idzie? Obecni klienci odchodzą, bo nawet spece Pana Romana nic już nie wskórają. Jednak odchodzą bogatsi w doświadczenie wyniesione z tej "przygody"
i z pewnością jakiś procent (nie wszyscy, bo niektórzy nigdy się nie nauczą) następnym razem weźmie pod uwagę coś takiego jak jakość.

Oczywiście ten proces jest długoletni i może Pan Roman nigdy nie będzie zmuszony zamknąć działalności, ale szybko przestanie się rozwijać, zacznie się stopniowy spadek zysków, większe cięcia, mniejsza ilość pracowników, czyli wolniejszy dewelopment, mniejsze możliwości produkcyjne, spadek zysków i koło się zamyka.Ten post został edytowany przez Autora dnia 05.06.13 o godzinie 08:02

konto usunięte

Temat: Kto płaci za dobry kod?

Piotr R.:
Kiedy IT jest integralną częścią firmy przychodzi Pan Dyrektor Finansowy i mówi, że nie dostaniesz dodatkowych 160 roboczogodzin na rewizję systemu pod nową funkcjonalność a na pytanie dlaczego dostaniesz odpowiedź "Bo tak". I możesz sobie tłumaczyć i podawać racjonalne powody i podpierać się książkami i autorytetami i tabelkami jaki to jest wielki błąd z perspektywy przyszłego utrzymania systemu poparty cyferkami. Wiesz jak te wszystkie argumenty wyglądają w uszach takiego Dyrektora Finansowego, który się zaparł? Podpowiem: "ble ble ble ble". A przypominam, że Dyrektor Finansowy może zgodnie z prawem zablokować każdą decyzję Prezesa na wypadek jak by ci przyszło do głowy obejść jego decyzję. W tym akcie pierwsze skrzypce gra polityka a nie racjonalne myślenie. A jak już w przyszłości system obrośnie lakami i przestanie być rozwojowy to już nikt nie będzie pamiętał kto i kiedy podjął decyzje, które do tego doprowadziły. IT może tylko własnym ponadmiarowym wysiłkiem odwlekać ten dzień ale i tak on kiedyś nastąpi :)
Ale ja nie twierdzę wcale, że takie rzeczy się nie zdarzają, ubolewam nad tym, ale jestem daleki od takiego stanowiska (niestety zbyt często sam doświadczałem takich zachowań).

Mimo wszystko to, co opisałeś to przykład niekompetentnego dyrektora finansowego, który najwidoczniej nie wie co i jak powinien robić. Czy uda mu się przeforsować to, co sobie umyślił? Pewnie tak, ale nie zmienia to faktu, że działa na niekorzyść firmy. Co z tego, że chwasty tych decyzji będą widoczne za rok, dwa? Firma je odczuje.
Poza tym osoba na wysokim (decyzyjnym) stanowisku, która nie słucha doradców czy specjalistów, najzwyczajniej na takie stanowisko się nie nadaje. Nikt nie jest alfą i omegą i takie zachowanie świadczy jedynie o wielkiej arogancji.

Zdaję sobie sprawę, że świat nie jest idealny, ale to nie oznacza, że powinniśmy się na to godzić i nie próbować niczego zmienić. Oczywiście takie zmiany nie następują szybko, ale każdy się uczy i jeżeli odpowiednio podchodzisz do tematu i konsekwentnie dążysz do celu, to nawet myślenie takiego dyrektora da się zmienić.

Robert Stephenson Smyth Baden-Powell powiedział:
"Leave this world a little better than you found it."
I takie myślenie powinno kierować działaniami każdej osoby. Nie chodzi mi o wymuszanie zmian, ale raczej o nauczenie, że te zmiany przynoszą wymierne korzyści.
Marcin Mroczkowski

Marcin Mroczkowski Programista JAVA/JEE

Temat: Kto płaci za dobry kod?

Paweł W.:

He he he, nic lepiej nie oddaje lepiej natury problemu. Można by ten post obić w ramkę.

Abstrahując już od kwestii kierownictwa, chciałbym zwrócić uwagę na bardziej indywidualne powody powstawania "kwiecistego" kodu. Mianowicie zauważyłem (na swoim przypadku niestety też to przerobiłem), że młodzi programiści, są często zbyt ambitni i idealistyczni, co przy zderzeniu ze zardzewiałymi systemami prowadzi do szeregu problemów. Tacy ludzie zwykle:
- mają skłonność do przekładania mikro-optymalizacji i innych kruczków programistycznych nad czytelność i standaryzację
- ostro krytykują śmieciowy kod i są pewni, że potrafią go poprawić, problem w tym, że bez doświadczenia i dużej znajomości systemu, zwykle wprowadzają więcej błędów niż poprawek
- wykazują brak tolerancji dla innych podejść programistycznych i architektonicznych, zwykle posiadając jedno "złote" rozwiązanie, inne uważają ze jednoznacznie nieprawidłowe
- bardzo często nie mają pojęcia o zagadnieniach obiektowych i forsują rozwiązania proceduralne, którego są też zwykle uczeni na studiach
- po okresie szoku spowodowanego śmieciowym kodem, i próbach poprawiania, następuje zrezygnowanie owocujące spadkiem motywacji i produkcją jeszcze gorszego kodu w dużych ilościach

Dlatego też, rozwiązywanie problemu przez zatrudnianie "skończonej liczby praktykantów", powoduje tylko wzmacnianie pierwotnego problemu. Mieliście może doświadczenia z tym problemem ?

Następna dyskusja:

Kto z Was zajmuje się J2ME ?




Wyślij zaproszenie do