Temat: Kto płaci za dobry kod?

Marcin M.:
[...]
Dlatego też, rozwiązywanie problemu przez zatrudnianie "skończonej liczby praktykantów", powoduje tylko wzmacnianie pierwotnego problemu.

Dlatego tak ważne jest posiadanie przynajmniej jednej osoby doświadczonej, która będzie potrafiła "utemperować" ich zapędy, nauczyć i wytłumaczyć idee i techniki, ktoś, od kogo będą mogli się uczyć.
Osoba z odpowiednią wiedzą i umiejętnościami interpersonalnymi potrafi poprowadzić takich programistów i stworzyć z nich całkiem zgrany i dobry zespół.

Mieliście może doświadczenia z tym problemem ?

A kto nie miał? Sam kiedyś byłem takim "problemem" :)
Na szczęście w odpowiednim momencie spotkałem ludzi, którzy byli w stanie mi pokazać co robię źle i wytłumaczyć mi dlaczego to jest złe. Teraz sam staram się jak mogę, robić to samo :)

Temat: Kto płaci za dobry kod?

który oszacował. Na wejściu taki programista powinien dostać wynik analizy + projekt i wziąć się do pracy ;)

Ciekawe postawienie sprawy :-))
W zasadzie nigdy nie byłem prawdziwym programistą, więc pewnie dlatego moje doświadczenia są inne. Obecnie programista (czy jak to nazwiemy) dostaje problem do rozwiązania. Obecne języki programowania są tak ekspresyjne, że napisanie (sensownej) specyfikacji kosztuje więcej czasu i energii niż napisanie działającego kodu.

Temat: Kto płaci za dobry kod?

Sylwester R.:

Obecne języki

programowania są tak ekspresyjne, że napisanie (sensownej) specyfikacji kosztuje więcej czasu i energii niż napisanie działającego kodu.

rzekłbym że mocno kontrowersyjna teza. Czyli według Ciebie obecnie pisze się prototypy (skąd wiadomo co ma robić taki prototyp i czy ma reprezentować zarządzaniem chłodzeniem elektrowni atomowej czy też zarządzaniem pocztą www?) a dopiero później się je przerabia na X sposobów dochodząc do tego co Klient oczekuje?

Temat: Kto płaci za dobry kod?

Jarosław S.:
rzekłbym że mocno kontrowersyjna teza. Czyli według Ciebie obecnie pisze się prototypy (skąd wiadomo co ma robić taki prototyp i czy ma reprezentować zarządzaniem chłodzeniem elektrowni atomowej czy też zarządzaniem pocztą www?) a dopiero później się je przerabia na X sposobów dochodząc do tego co Klient oczekuje?

Oczekujesz odpowiedzi szczerej, czy politycznie poprawnej? Bo obawiam się że często-gęsto tak to właśnie wygląda. Wiecie, taka wariacja na temat agile ;)

Temat: Kto płaci za dobry kod?

Maciej N.:
Oczekujesz odpowiedzi szczerej, czy politycznie poprawnej? Bo obawiam się że często-gęsto tak to właśnie wygląda. Wiecie, taka wariacja na temat agile ;)

ja tylko polemizuje z generalizującymi tezami wyciągniętymi na podstawie uogólnienia. Nie można napisać prototypu jak nie wiadomo z jakiej dziedziny jest. Można w ten sposób pracować gdy łupie się standardowe i powtarzalne projekty i na podstawie hasłowego przedstawienia informacji można np. skonfigurować jakieś oprogramowanie (typu wdróż mi naszego CRM'a ze standardowym zestawem ról i aktywnymi modułami) ale to chyba nie ma za dużo wspólnego z dostarczaniem spersonalizowanego kodu. Natomiast rzucanie tezy że można napisać działający kod bez jakiejkolwiek specyfikacji bo mamy super fajne języki programowania jest co najmniej kontrowersyjne chyba że autor postu ma zdolności czytania w podświadomości innych osób i ma do nich dostęp. To wcale nie znaczy że w praktyce biznesowej kompletność specyfikacji (cokolwiek formalnego / nieformalnego mamy tutaj na myśli) nie mieści się w przedziale od kilku do 99 %. A już bym mocno polemizował przy stwierdzeniu że taniej jest kodować niż pisać specyfikację. Koszt kodowania liczony w roboczogodzinach * koszt godziny pracy (w rozumieniu analizy technicznej + architektury + implementacji + TDD w jakimś stopniu) jest w większości znacznie większy niż koszt przygotowania specyfikacji. Problem w tym że w praktyce specyfikację powinni pisać ludzie (odpowiednik product ownera) którzy mają najmniej czasu na to, nie są dostępni w danym momencie, lub nie ma świadomości odpowiedniego poziomu szczegółowości wymagań u sponsorów projektu lub trzeba pokazać pierwszy milestone sponsorowoi projektu jak najszybciej żeby przekonać że ma się zdolność do wytworzenia projektu (co częstwo wprowadzana dodatkowe koszty niepotrzebne ale zmniejsza to poczucie ryzyka u sponsora wiec jest uzasadnione z jego punktu widzenia). I to jest przyczyna zderzania się przy projektach z przypadkami gdzie trzeba ogarniać luki w rozumowaniu / analizie a nie dlatego że ktoś stwierdził że taniej jest rzucić X programistów niż poświęcić czas product ownera. W dużej części przypadków nie ma możliwości przeprowadzenia analizy lepszej po prostu i to się toczy siłą rozpędu. Można sobie tylko życzyć mieć super dostępność product ownera, dowolnie długi czas na analizę.

Temat: Kto płaci za dobry kod?

Maciej N.:
Oczekujesz odpowiedzi szczerej, czy politycznie poprawnej? Bo obawiam się że często-gęsto tak to właśnie wygląda.

Ale taki sposób pracy powoduje, że firma nigdy nie wyrobi sobie marki (no chyba, że będzie miała naprawdę więcej szczęścia niż rozumu). Takie działanie sprawdzi się kilku(nasto)krotnie przy większych zamówieniach, a później, kolejni potencjalni klienci nie podejmą współpracy, bo będą wiedzieli, że nic z tego dobrego nie wyjdzie. Zapewne taka firma znajdzie dziesiątki mniejszych klientów, dla których jedynym istotnym punktem przy podjęciu decyzji będzie cena, ale to sprowadzi się do braku rozwoju i ekspansji. Firma utknie.

Wiecie, taka wariacja na temat agile ;)

Jeżeli ktoś taki sposób pracy u siebie określiłby słowem Agile tzn., że nie rozumie terminu, którym się posiłkuje w celu ukrycia panującego chaosu. Wielokrotnie widziałem takie "Scrumy" i "Kanbany", gdzie ludzie decydowali się na "bycie Agile", bo lepiej powiedzieć, że "jesteśmy zwinni" niż przyznać się, że mamy burdel w firmie i nie umiemy sobie z nim poradzić.

Temat: Kto płaci za dobry kod?

Jarosław S.:
Koszt kodowania [...] jest w większości znacznie większy niż koszt przygotowania specyfikacji.

A mimo to przy nawet dużych projektach nadal nie poświęcają na to czasu. Czasami naprawdę nie jestem w stanie zrozumieć zachowań ludzkich. Takich tym bardziej, bo przecież powinny opierać się na kalkulacjach, statystykach i cyfrach, więc tym rozsądniejsze powinny być.
Jak widać, zazwyczaj jest jednak inaczej.

Problem w tym że w praktyce specyfikację powinni pisać ludzie
którzy mają najmniej czasu na to, nie są dostępni w danym momencie, lub nie ma świadomości odpowiedniego poziomu szczegółowości wymagań u sponsorów projektu

Powinna być przeprowadzona analiza przez specjalistę. Zwiększa to (i to naprawdę w dużym stopniu) prawdopodobieństwo sukcesu.

lub trzeba pokazać pierwszy milestone sponsorowoi projektu jak najszybciej żeby przekonać że ma się zdolność do wytworzenia projektu

Można stworzyć prototyp. Jedyne o czym nie można jednak zapomnieć, to żeby taki prototyp nie trafił do finalnego produktu.

I to jest przyczyna zderzania się przy projektach z przypadkami gdzie trzeba ogarniać luki w rozumowaniu / analizie a nie dlatego że ktoś stwierdził że taniej jest rzucić X programistów niż poświęcić czas product ownera. W dużej części przypadków nie ma możliwości przeprowadzenia analizy lepszej po prostu i to się toczy siłą rozpędu.

W to nigdy nie będę w stanie uwierzyć. Firma nie ma możliwości poświęcić czas, ale jest skłonna wyrzucać duże pieniądze w błoto? Bo niestety tym są niektóre wydatki dotyczące tworzonego oprogramowania, jeżeli wcześniej nie poświęci się czasu.
Zaangażowanie osoby ze znajomością biznesu (która może podejmować wiążące decyzje) zawsze jest oszczędnością w przypadku tworzenia rozwiązań dla firmy, bo są one lepsze i dokładniejsze.

Można sobie tylko życzyć mieć super dostępność product ownera,

I jeszcze aby był przygotowany do swojej roli lub przynajmniej skłonny do nauczenia się jej:)

dowolnie długi czas na analizę.

Tutaj bym nie przesadzał, bo mogłoby się skończyć na "przeanalizowaniu" :P

Temat: Kto płaci za dobry kod?

Dlatego agile tłumaczy się w naszych realiach nie jako "zwinne" a "na żywioł" ;)

Generalnie chciałbym podzielać wasz optymizm odnośnie pięknych standardów, wyrabiania sobie marki itp. Ale nie zapominajcie, że tu jest Polska i podejście "jakoś to będzie" ma się dobrze.

Temat: Kto płaci za dobry kod?

Maciej N.:
Dlatego agile tłumaczy się w naszych realiach nie jako "zwinne" a "na żywioł" ;)

Jakkolwiek by tego nie tłumaczyli, to w IT "being agile" ma swoją definicję, tak samo jak każdy agilowy framework i jeżeli używasz słowa, ale nie stosujesz się do definicji, to nie jest to nic więcej jak okłamywanie siebie i potencjalnych/obecnych pracowników.

Generalnie chciałbym podzielać wasz optymizm odnośnie pięknych standardów, wyrabiania sobie marki itp. Ale nie zapominajcie, że tu jest Polska i podejście "jakoś to będzie" ma się dobrze.

Zdefiniuj "dobrze".

Czy to znaczy, że nadal jest popyt na takie oprogramowanie? Oczywiście, że jest, bo przy niewielkich produktach (do 3 miesięcy pracy, realnej, a nie wyestymowanej :), to wszystko jest do "ogarnięcia" nawet przy braku testów i jakości i rzeczywiście każdy przeciętny student sobie poradzi.
W przypadku większych aplikacji klienci zaczynają dojrzewać. Jeżeli po pół roku prac nadal nie widzą efektów, a jedynie faktury i przesuwany deadline, a plan był na miesiąc (pracowałem w takiej firmie), to czasami rezygnują, często produkt końcowy nie spełnia nawet minimalnych warunków i jeżeli nadal będą uważali, że software jest w stanie usprawnić ich pracę, to pójdą do kogoś, kto nie obieca im gruszek na wierzbie, ale dostarczy coś, co będzie działało i to w sposób oczekiwany.

Nasz rynek jest jeszcze młody i tak naprawdę niektóre firmy dopiero zaczynają doświadczać skutków "cięcia kosztów". Im więcej firm zacznie "zbierać plony" wdrożenia takiego oprogramowania, tym mniej pójdzie w ich ślady.

I tak na koniec. Po rozmowach z wieloma osobami, które żyją w naszym świecie (bez względu na to czy są programistami/architektami/analitykami itp.), to nigdy nie usłyszałem od nikogo, kto stosuje dobre praktyki, żeby narzekał na brak klientów.
Pierwsze kroki zazwyczaj są trudniejsze, ale później już idzie z górki.

Temat: Kto płaci za dobry kod?

Sebastian M.:

Czy to znaczy, że nadal jest popyt na takie oprogramowanie? Oczywiście, że jest, bo przy niewielkich produktach (do 3 miesięcy pracy, realnej, a nie wyestymowanej :), to wszystko jest do "ogarnięcia" nawet przy braku testów i jakości i rzeczywiście każdy przeciętny student sobie poradzi.
W przypadku większych aplikacji klienci zaczynają dojrzewać.

Naprawdę chciałbym wierzyć w to co mówisz, ale moje doświadczenia są zgoła inne. W praktyce jest tak, że zadowolenie klienta wynika z trzech rzeczy: kasy, terminu i zrealizowanej funkcjonalności. Dokładnie tak jak w opowiadaniu Pawła, wózek zaczyna grać, śpiewać i tańczyć to klient z zadowoleniem go bierze. Kolejni dostawcy, mają coraz ciężej i w takiej sytuacji bardzo kuszące jest olanie jakości, sforsowanie zmiany kolejną warstwą "taśmy samoprzylepnej", bo klient nasz Pan, a kasa z nieba nie spada. Ten kto pierwszy zakomunikuje problem i zażąda znacznie większych pieniędzy, stanie się kozłem ofiarnym, bo "wszystko było super, a ten przyszedł i ma jakieś problemy, a do tego chce dwie bańki".
Wiem, że to głupie, że w końcu takie systemy padną, ale tak się to ciągle kręci. To co mówisz jest piękne, ale niestety na razie brzmi jak utopia.

Temat: Kto płaci za dobry kod?

Zwróć jednak uwagę na to, że kiedyś w końcu klient usłyszy, że dalszy rozwój jest niemożliwy/nieopłacalny. Może i się bardzo wk#&%i, ale dzięki temu może następnym razem trochę lepiej przemyśli inwestycję.
A nawet jeżeli on się nie nauczy, to z pewnością swoim doświadczeniem się z kimś podzieli i istnieje szansa, że któryś z jego rozmówców też będzie miał potrzebę stworzenia oprogramowania i wyciągnie wnioski z jego lekcji.

Wiem, że jest to proces wolny biorąc pod uwagę czas od rozpoczęcia prac nad projektem aż do momentu, gdy zaczyna sprawiać niemożliwe do przeskoczenia problemy, ale on zachodzi.

Z drugiej strony są firmy, które przywiązują wagę do jakości. Pewnie mają na początku pod górkę, ale budują markę, z którą inni będą chcieli mieć coś wspólnego. Zarówno klienci jak i potencjalni pracownicy.

I tak jak powtarzam od początku, zdaję sobie sprawę, że pewnie w większości przypadków jest całkowicie inaczej, a w żadnym nie jest idealnie. Mimo to, z racji swojej wiedzy i doświadczenia, tym mocniej powinniśmy walczyć o te dobre praktyki.
Tylko należy pokazać klientowi, że my nie walczymy o to dla siebie, bo mamy takie widzimisię, nie, my walczymy dla nich (mimo iż pozornie z nimi), o to by dostali to, czego chcą i wydali na to jak najmniej pieniędzy.

Bo przecież głównym celem stosowania tych praktyk nie jest sztuka dla sztuki, a zadowolenie klienta.

Temat: Kto płaci za dobry kod?

Sebastian M.:

A mimo to przy nawet dużych projektach nadal nie poświęcają na to czasu. Czasami naprawdę nie jestem w stanie zrozumieć zachowań ludzkich. Takich tym bardziej, bo przecież powinny opierać się na kalkulacjach, statystykach i cyfrach, więc tym rozsądniejsze powinny być.
Jak widać, zazwyczaj jest jednak inaczej.

hmm, nie chce tutaj zgadywać ale wydaje mi się że chyba nie uczestniczyłeś w większym zakresie w procesach sprzedaży typowego software house. Gdybyś uczestniczył lub porozmawiał z działem sprzedaży nie miałbyś takiego czarno-białego obrazu rzeczywistości. Tak jak wcześniej powiedziałem duża część przyczyn niekompletności dokumentacji wynika z przyczyn leżących poza firmą (klient i słaba dostępność do wiedzy po jego stronie (wiedzy może dostarczyć kluczowy pracownik klienta, który jest zaangażowany w mega kluczowy proces biznesowy u klienta i można wyżebrać tylko pół godziny dziennie jego czasu - wcale nie rzadki przypadek gdy wchodzimy w rzadką wiedzę domenową), konkurencja drepcząca po piętach, działanie w warunkach przetargu?) a nie z problemów wewnątrz niej (niekompetencja kierownictwa, "burdel" jak to określiłeś). I to jak sobie dana firma w tej sytuacji "niepewności" radzi niejednokrotnie decyduje o jej sukcesie rynkowym. To jest ryzyko prowadzenia działalności gospodarczej.

Można stworzyć prototyp. Jedyne o czym nie można jednak zapomnieć, to żeby taki prototyp nie trafił do finalnego produktu.

no chyba że zbliża się deadline a Twój team nie ma innego wyjścia niż włączyć jakiś słabo napisany kod dla celów prototypowych do kodu produkcyjnego bo jak nie to lecą kary umowne które zmieniają rentowny projekt w projekt do którego dokłada firma. Tylko proszę nie mów mi że to wynika ze słabego kierownictwa / braku właściwego agile itp. Takie rzeczy zdarzają się najlepszym i bardzo doświadczonym ludziom i wynika min. ze złożoności procesu wytwórczego oprogramowania,

I to jest przyczyna zderzania się przy projektach z przypadkami gdzie trzeba ogarniać luki w rozumowaniu / analizie a nie dlatego że ktoś stwierdził że taniej jest rzucić X programistów niż poświęcić czas product ownera. W dużej części przypadków nie ma możliwości przeprowadzenia analizy lepszej po prostu i to się toczy siłą rozpędu.

W to nigdy nie będę w stanie uwierzyć. Firma nie ma możliwości poświęcić czas, ale jest skłonna wyrzucać duże pieniądze w błoto? Bo niestety tym są niektóre wydatki dotyczące tworzonego oprogramowania, jeżeli wcześniej nie poświęci się czasu.

problem opisałem wcześniej -> przyczyny w dużej mierze poza kontrolą firmy, sprzedawca może nie wchodzić w dany deal i zostać z niewykorzystanymi etatami w firmie które kosztują nie mało i dopłacać do stanowisk lub wejść w proces w którym oszacować można z jakimś przybliżeniem kosztochłonność. Niestety polska rzeczywistość jest taka:

- zdecydowana większość kontraktów to fixed price a firma konkuruje z innymi głównie przez pryzmat oszacowanej ceny za wykonanie, tylko niewielka część kontraktów to kontrakty z płaceniem za "konsulting IT" gdzie w pełni świadomy klient płaci za godzinę pracy pracowników software house
- klienci w zdecydowanej większości przypadków nie chcą płacić za analizę biznesową która by drastycznie zmniejszyła ryzyko szacowania kosztów implementacji tego co początkowo chciał klient

Można z tym się nie zgadzać i odrzucać kontrakty (i dopłacać z kieszenie właścicieli do firmy) lub pogodzić się z rzeczywistością. Gdy się połączy powyższe to wcale nie dziwi człowieka dlaczego to tak działa w większości przypadków.

Temat: Kto płaci za dobry kod?

Jarosław S.:
hmm, [...] To jest ryzyko prowadzenia działalności gospodarczej.

Musiałem się źle wyrazić, ponieważ nie chciałem niczego generalizować i upraszczać (wrzucać w czarno-białe ramy). Zdaję sobie sprawę z tych wszystkich czynników (lecz od razu się przyznaję, że od "zdawania sobie sprawy" do pełnego pojmowania droga jeszcze daleka:), lecz ja wcale nie pisałem, że ich nie ma. Rozumiem, że problem jest dużo bardziej złożony, a im większa firma, im większe pieniądze wchodzą w grę i im większy zakres projektu, tym większa złożoność.

Mój brak zrozumienia dotyczy jedynie tego braku czasu ze strony klienta, co jest niestety nagminnym zachowaniem. Ja naprawdę doświadczyłem niejednokrotnie różnych tłumaczeń i nie mogę powiedzieć, że kiedykolwiek usłyszałem, że "nie, bo nie", zawsze otrzymywałem rozsądne "usprawiedliwienie".
Mimo to zwykle próbowałem tą komunikację i wymianę informacji ulepszyć (z różnym skutkiem), ponieważ to jest działanie na korzyść klienta. Przecież nam nie chodzi o to, żeby sobie pogadać z kimś, bo od tego mamy znajomych czy też kolegów w pracy, nam wszystkim chodzi o to, aby stworzyć coś, co zadowoli zamawiającego i sprosta jego oczekiwaniom. I, choć ciężko to klientowi wytłumaczyć i udowodnić, za tą potrzebą "tracenia" ich czasu, kryje się chęć oszczędzenia ich pieniędzy.

a nie z problemów wewnątrz niej (niekompetencja kierownictwa, "burdel" jak to określiłeś)

Co do burdelu, to odnosiłem się jedynie do wykorzystania terminu "agile" w wielu firmach. Staje się to coraz częstszą praktyką, że brak organizacji i nieumiejętności w zarządzaniu są ukrywane za "byciem zwinnym".

Można stworzyć prototyp. Jedyne o czym nie można jednak zapomnieć, to żeby taki prototyp nie trafił do finalnego produktu.

[...] Tylko proszę nie mów mi że to wynika ze słabego kierownictwa / braku właściwego agile itp. Takie rzeczy zdarzają się najlepszym i bardzo doświadczonym ludziom i wynika min. ze złożoności procesu wytwórczego oprogramowania,

Jasne, że się zdarzają i zdarzać się będą (chociaż życzę każdemu, żeby jak najrzadziej:).
Pisałem o wykorzystaniu prototypów odnośnie potrzeby szybkiego pokazania czegoś sponsorowi. W takim wypadku jest to idealne rozwiązanie, lecz zazwyczaj (zawsze?) należałoby w nim coś zmienić. Że czasami nie zdążymy? Trudno, świat nie jest idealny, a jedyne co my możemy robić, to próbować pomimo to stworzyć jak najlepsze produkty. Problemem nie jest jednak (a przynajmniej nie tragicznym), gdy czasami taki prototyp trafi do produkcji, problem jest wtedy, gdy my od początku zakładamy, że on tam wyląduje.

Niestety polska rzeczywistość jest taka:
- zdecydowana większość kontraktów to fixed price a firma konkuruje z innymi głównie przez pryzmat oszacowanej ceny za wykonanie, tylko niewielka część kontraktów to kontrakty z płaceniem za "konsulting IT" gdzie w pełni świadomy klient płaci za godzinę pracy pracowników software house
- klienci w zdecydowanej większości przypadków nie chcą płacić za analizę biznesową która by drastycznie zmniejszyła ryzyko szacowania kosztów implementacji tego co początkowo chciał klient

Niestety. Tylko ja nadal nie jestem w stanie zrozumieć dlaczego nie chcą?
I tutaj wracamy do kalkulacji. Przy odpowiednio dużym projekcie taka analiza jest opłacalna i tak, jak napisałeś - zmniejsza ryzyko.

Można z tym się nie zgadzać i odrzucać kontrakty (i dopłacać z kieszenie właścicieli do firmy) lub pogodzić się z rzeczywistością. Gdy się połączy powyższe to wcale nie dziwi człowieka dlaczego to tak działa w większości przypadków.

Ale je nie twierdzę, żeby się z tym nie zgadzać i odrzucać kontrakty, bo każdy musi za coś żyć (pracowników trzeba opłacić). Jednak nie widzę też powodów, aby się z tym pogodzić.
Czy nie jest możliwe nie zgadzać się i wprowadzać zmiany? Ja nie mówię o rewolucjach, bo na te nikt się nie zgodzi i szczerze mówiąc, każde drastyczne zmiany niosą ze sobą (moim zdaniem) zbyt duże ryzyko. Ale czy stopniowa ewolucja nie jest możliwa? Nawet w trakcie trwania projektu? Taka rewolucja poprzez (czasochłonną, trudną i wymagającą dużo wysiłku i cierpliwości) ewolucję?

Może moje wypowiedzi były rzeczywiście zbyt czarno-białe jak to określiłeś, jednak nie wynika to z całkowitego braku doświadczenia, nieznajomości tematu bądź świata, w którym się poruszamy. Ja po prostu widziałem nie raz, że to działa, sprawdza się, a klienci są zadowoleni; dobre praktyki wpływają na szybkość tworzenia nowych rzeczy i rozwoju starych oraz na jakość tego, co powstało i powstaje.
Przypuszczalnie nigdy nie będzie mi dane pracować w idealnym projekcie, musimy godzić się na kompromisy, częściej większe niż mniejsze, jednak nie widzę przeszkód w tym, aby zostawiać obóz czystszym, niż się go zastało :)

Temat: Kto płaci za dobry kod?

Jarosław S.:

Sylwester R.:

Obecne języki

programowania są tak ekspresyjne, że napisanie (sensownej) specyfikacji kosztuje więcej czasu i energii niż napisanie działającego kodu.

rzekłbym że mocno kontrowersyjna teza. Czyli według Ciebie obecnie pisze się prototypy (skąd wiadomo co ma robić taki prototyp i czy ma reprezentować zarządzaniem chłodzeniem elektrowni atomowej czy też zarządzaniem pocztą www?) a dopiero później się je przerabia na X sposobów dochodząc do tego co Klient oczekuje?

Chodzi o to, że na początku nie do końca wiadomo co _dokładnie_ program ma robić. Wiadomo co ma robić w ogólności, ale zaprojektowanie wielu detali możliwe jest dopiero po zobaczeniu jak działa cały system.

Temat: Kto płaci za dobry kod?

Byłem kiedyś świadkiem rozmowy lidera programistów z osobą z biznesu:
- Ile zajmie zrobienie aplikacji ?
- Ale jakiej aplikacji?
- Jeszcze nie wiem, ale muszę wiedzieć, na kiedy możemy ją zrobić.

Na szczęście nie pracuję już w tej firmie. A pisała ona soft dla całkiem poważnych klientów.

Temat: Kto płaci za dobry kod?

ostatnio za dobry kod płaciła mi firma z Japonii ... (ale było to przed laty, obecnie te firmy omijają Polskę szerokim łukiem)
no może pozytywnie akceptowała firma z Holandii.

polskie firmy maja to głęboko w dupie (chyba, że wymusi to zagraniczny kontrahent) a polscy programiści traktują niemal jak zdradę.Ten post został edytowany przez Autora dnia 17.06.13 o godzinie 19:37

Temat: Kto płaci za dobry kod?

Strasznie narzekacie na te firmy w Polsce, trochę to takie typowo polskie: narzekanie, ale żeby coś z tym zrobić to ciężko :)

Ja mam zgoła inne doświadczenia i znam kilka, kilkanaście polskich firm, gdzie jakość kodu ma znaczenie i gdzie za zacommitowanie badziewia do repozytorium dostaniesz za swoje w code review. Za brak testów to samo.

Wiadomo, że refaktorowania dla samego sztuki nikt nie pochwali, ale jeśli widzę kiepski kawałek kodu i wiem, że dotykam go po raz N-ty, to po prostu poświęcę kilka godzin i zrobię z nim porządek.

Wszystko zależy od naszego podejśćia, bo jeśli akceptuje się taki stan rzeczy, to dla wszystkich staje się on "normą", jak wybite okno ( http://pl.wikipedia.org/wiki/Teoria_rozbitych_okien ). A jeśli sami zaczniemy o to dbać to powoli zacznie się coś zmieniać, ktoś inny też zacznie na to zwracać uwagę i krok w dobrym kierunku zostanie zrobiony.

A co jesli się nie da? Nie wiem, ale wydaje mi się, że rynek programistów Javy to w Polsce rynek pracownika, a nie pracodawcy, więc jeśli nie odpowiada Wam aktualna firma to są dwa wyjścia:

change your organisation or change your organisation :)

Temat: Kto płaci za dobry kod?

Jarema A.:
Byłem kiedyś świadkiem rozmowy lidera programistów z osobą z biznesu:
- Ile zajmie zrobienie aplikacji ?
- Ale jakiej aplikacji?
- Jeszcze nie wiem, ale muszę wiedzieć, na kiedy możemy ją zrobić.

Na szczęście nie pracuję już w tej firmie. A pisała ona soft dla całkiem poważnych klientów.

Słuchaj to jest właśnie biznes - mam podobne odczucia.
Przykładowo ja miałem dodać nową funkcjonalność, 1 interface + enum do konstruktora i rozwiązywał sprawę.
Zrobiłem zaimplementowałem i jestem happy, bo wszystko tak jak chcieli (wedle dokumentacji), a biznes:
- ale... jeżeli robisz taką funkcjonalność, to chcemy żeby ta sama funkcjonalność zadziałała tak i tak (czego było brak w dokumentacji), i jeszcze nie mówiliśmy Tobie tego ale według nas jak robisz tę funkcjonalność (przykładowo nowy jakiś formularz) to my (czytaj biznes) rozumiemy, że nam zrobisz jeszcze to i to wedle tej zmiany i oczywiście według biznesu jest to wszystko "dorozumiane" :)
A wszystkie zmiany poza dokumentacją są przez BYZNES dorozumiane, a człowieka szlag trafia!

Podzielam zdanie Tomka - jak zrobić to zrobić raz a dobrze, albo tak żeby potem 1 zmiana nie powodowała "lądowania helikoptera na dachu szklarnii" i wytrzymać [zasłyszane ciekawe porównanie Sławka Sobótki]

Temat: Kto płaci za dobry kod?

Tomasz D.:
Strasznie narzekacie na te firmy w Polsce, trochę to takie typowo polskie: narzekanie, ale żeby coś z tym zrobić to ciężko :)

Ja mam zgoła inne doświadczenia i znam kilka, kilkanaście polskich firm, gdzie jakość kodu ma znaczenie i gdzie za zacommitowanie badziewia do repozytorium dostaniesz za swoje w code review. Za brak testów to samo.

Wiadomo, że refaktorowania dla samego sztuki nikt nie pochwali, ale jeśli widzę kiepski kawałek kodu i wiem, że dotykam go po raz N-ty, to po prostu poświęcę kilka godzin i zrobię z nim porządek.

Wszystko zależy od naszego podejśćia, bo jeśli akceptuje się taki stan rzeczy, to dla wszystkich staje się on "normą", jak wybite okno ( http://pl.wikipedia.org/wiki/Teoria_rozbitych_okien ). A jeśli sami zaczniemy o to dbać to powoli zacznie się coś zmieniać, ktoś inny też zacznie na to zwracać uwagę i krok w dobrym kierunku zostanie zrobiony.

A co jesli się nie da? Nie wiem, ale wydaje mi się, że rynek programistów Javy to w Polsce rynek pracownika, a nie pracodawcy, więc jeśli nie odpowiada Wam aktualna firma to są dwa wyjścia:

change your organisation or change your organisation :)

Nie twierdzę, że nie masz racji, ale to częściej świadomi programiści walczą o dobry kod niż managerowie. Zwłaszcza, gdy są rozliczani z terminów. Miałem okazję pracować dla dużych klientów z branży finansowej. W jednym banku manager w dniu wdrożenia przyniósł listę dodatkowych wymagań i rzucił z tekstem: ma być na jutro. Pisaliśmy wtedy kod do 4tej rano. Wdrożenie się udało. A że po trzech miesiącach wyszedł bug to inna sprawa. Ale wtedy przynajmniej było więcej czasu i załatało go się zgodnie ze sztuką.Ten post został edytowany przez Autora dnia 18.06.13 o godzinie 22:21

Temat: Kto płaci za dobry kod?

Tomasz D.:
Strasznie narzekacie na te firmy w Polsce, trochę to takie typowo polskie: narzekanie, ale żeby coś z tym zrobić to ciężko :)

Czasem trzeba ponarzekać żeby coś w końcu zmienić.

Porównując do Niemiec w Polsce nie brak jest dobrych programistów którzy mają głowę na karku.
Problem jest w tym że metodologie z głównego nurtu przychodzą z opóźnieniem do polski i ogólnie do firm.
Przychodząc do firmy, jako świeżo upieczony magister, w zasadzie musisz liczyć na szczęście czy znajdziesz kogoś
z długim stażem, który pokaże ci właściwe kierunki. Inaczej jesteś sam i twoje ambicje.
W Niemczech zderzyłem się z tym że byłem jedną osobą która umiała pisać unit testy i to w nie jednej firmie.

Tomasz D.:

>Wszystko zależy od naszego podejścia, bo jeśli akceptuje się taki stan rzeczy, to dla wszystkich staje się on "normą", jak >wybite okno ( http://pl.wikipedia.org/wiki/Teoria_rozbitych_okien ). A jeśli sami zaczniemy o to dbać to powoli zacznie >się coś zmieniać, ktoś inny też zacznie na to zwracać uwagę i krok w dobrym kierunku zostanie zrobiony.

I to jest prawda. Udało mi się wyprosić posprzątanie kodu, dodania testów integracyjnych i jednostkowych.
Dzięki temu zmniejszyła się faktyczna liczba błędów krytycznych w trakcie wypuszczania nowej wersji, udało się nam zmniejszyć/uprościć kod. Po sprzątaniu faktycznie mogliśmy zobaczyć, co ten "burdel" faktycznie powinien robić.
Powoli jesteśmy w stanie określić wąskie gardła i potencjał do wzrostu w aplikacji.
Może i banał, ale powtarzając słowa Roberat. C. Martina, że to jest programista jest odpowiedzialny za kod, jego jakość, i niezawodność. Nikt nie może oczekiwać od klienta że będzie wiedział o aspektach tworzenia software u.
To jest jakby wymagać od klienta że musi wiedzieć jak zbudować dom żeby go kupić i w nim zamieszkać.
To budowlaniec i firma budowlana jest odpowiedzialna za budowę i za to żeby dom się nie zawalił i jest miarą profesjonalizmu cena końcowa i wysiłek włożony w wykonanie dzieła.