Temat: A ja się dziwię programistom, przepraszam Was...

mamy coś takiego (źr. http://bircza.net.pl/pascal%5Cpojecie_programowania_ob..., cytuje całość bo ważna:

[i]Programowanie, w którym program tworzony jest za pomocą obiektów
nazywamy programowaniem obiektowym. Obiektem nazywa się tutaj
podstawowy element programu, łączący opis stanu pewnego elementu
rzeczywistości opisywanego przez program z jego zachowaniem (czyli
funkcjami, lub inaczej mówiąc metodami obiektu).

Programowanie obiektowe łączy w całośd dane i funkcje na nich działające.
Obiektowe podejście pozwala łączyd cechy obiektów z ich zachowaniem.
Ponadto pozwala na klasyfikowanie obiektów podobnych – obiekty są tutaj
częścią klas (reprezentujących typ obiektu o określonym zachowaniu).
Programowanie obiektowe bliższe jest naturalnemu
sposobowi opisu rzeczywistości.

Obiekt jest modułem, z którego programista buduje cały program. Obiekt w
swojej strukturze zawiera dane zwane polami i funkcje zwane metodami.
Aby móc stworzyć w programie obiekt, trzeba zdefiniować klasę, do której
należy obiekt.

Klasa jest to złożony typ będący opisem (definicją) pól i metod obiektów w
programie. Relacja między obiektem a klasą: Obiekt jest zmienną typu zdefiniowanego w klasie .[i]

takie "lekcje" widzę nagminni także w materiałach dla studentów (ciekawe kto od kogo zrzyna...), jeżeli chodzi o pisanie kodu powyższe jest prawdą, jeśli chodzi o analizę obiektową i projektowanie jest to klęska...

Tak programiści, przepraszam, macie rację programując tak jak programujecie: Wasz kod to w końcu to jakieś moduły z jakimiś danymi i jakimiś na nich operacjami, ale uwierzcie mi, że obiektowy model rzeczywistości to nie moduły, nie funkcje itp., to świat rzeczywisty, który: nie poddaje się normalizacji, uczeń niczego nie dziedziczy po nauczycielu, faktura nie jest asocjacją kontrahenta, produktów i ich wartości a po protu trwałym, spójnym bytem, świat składa się z redundancji.

Jak dostajecie wyniki obiektowej analizy "świata rzeczywistego" to nie zamieniajcie jej na kod z dziedziczeniem, normalizacją, asocjacjami itp. tylko przyjmijcie z pokorą model tego świata bo języki obiektowe powstały po to by Wam to ułatwić a nie nie po to by zmienić paradygmat.

Jak piszecie kod, którego celem jest szyfrowanie transmisji, renderowanie obrazków itp. to róbcie to jak najlepiej potraficie ale jak implementujecie model dziedziny to dajcie mu spokój, to nie Wasz problem, po protu skopiujcie go, a jak Wasz analityk nie potrafi Wam dać takiego modelu obiektowego to zmieńcie analityka...

Temat: A ja się dziwię programistom, przepraszam Was...

Jarek Żeliński:
/.../
Jak dostajecie wyniki obiektowej analizy "świata rzeczywistego" to nie zamieniajcie jej na kod z dziedziczeniem, normalizacją, asocjacjami itp. tylko przyjmijcie z pokorą model tego świata bo języki obiektowe powstały po to by Wam to ułatwić a nie nie po to by zmienić paradygmat.
/.../

Oj, Jarek, wygląda to jakbyś dzielił ludzi na lepszych i gorszych :)
Programiści mają nie myśleć, nie ułątwiać sobie pracy, nie optymalizować kodu (z myślą o ułatwieniu przyszłego jego utrzymania), tylko mają z pokorą i bez zastrzeżeń realizować model nieomylnego analityka?

Nie podoba mi się to.
Analiza biznesowa chyba przecież nie jest "sztuką dla sztuki", ale stanowi raczej pewną warstwą pośrednią pomiędzy biznesem a projektowaniem i kodowaniem - i tutaj całą rola analizy polega na tym, żeby wymyślać modele tak, żeby dały się wygodnie i serwisowalnie implementować.

Temat: A ja się dziwię programistom, przepraszam Was...

Oj, Jarek, wygląda to jakbyś dzielił ludzi na lepszych i gorszych :)

nie, :) po protu znowu dostałem do ręki projekt programistów gdzie dodanie faktury zaliczkowej do projektu rozwalało cały system... a integracja z cudzym ERP była po prostu nie możliwa bo taniej było by napisać system od nowa...

jeżeli w ogóle dzielę ludzi to raczej na bazie tego czy są uczciwi i potrafią to co obiecują, że potrafią.

Programiści mają nie myśleć, nie ułątwiać sobie pracy, nie optymalizować kodu (z myślą o ułatwieniu przyszłego jego utrzymania), tylko mają z pokorą i bez zastrzeżeń realizować model nieomylnego analityka?

powoli, na razie kluczowe założenie:
- albo analityk i programista, każdy w swojej dziedzinie są super
- albo obaj są brakorobami

odrzućmy drugi przypadek więc pozostaje uczciwość

Nie podoba mi się to.
Analiza biznesowa chyba przecież nie jest "sztuką dla sztuki", ale stanowi raczej pewną warstwą pośrednią pomiędzy biznesem a projektowaniem i kodowaniem - i tutaj całą rola analizy polega na tym, żeby wymyślać modele tak, żeby dały się wygodnie i serwisowalnie implementować.

jak sam napisałeś projektowanie i kodowanie to nie to samo i właśnie o to mi chodzi: nie zgodzę się, że modele wymagań mają być łatwe do implementacji, one mają być dobre dla użytkownika. Gdyby tak było jak napisałeś, to w budownictwie wszystkie domki jednorodzinne były brzydkimi gierkowskimi kostkami projektowanymi przez inżynierów budownictwa a nie ładnymi domami z rąk architektów będącymi nie raz ozdobą osiedli.

Jak masz wątpliwości to porównaj zabudowę wiejską z tym co widać na miejskich osiedlach projektowanych przez architektów. Po drugie byle powódź pacyfikuje doszczętnie tylko wiejskie twory wykonane poza prawem budowlanym rękami swoich budowniczych.

Niedawno miałem kolejną przygodę:
- wykonałem pewien projekt obiecując klientowi, że przyszłe ewentualne rozbudowy i integracje będą relatywnie mało kosztowne
- wykonawca zignorował zalecenia i projekt, przerobił model dziedziny upraszczając go mocno, normalizując (!) moje diagramy klas ukrywając to przede mną (projekt był załącznikiem do umowy).
- po pewnym czasie pojawiła się potrzeba integracji z nowym ERP
- klient do mnie dzwoni, że wykonawca aplikacji za tę integracje żąda kwoty znacznie większej niż pierwotnie planowana
- pytam wykonawce o uzasadnienie kosztorysu i tu odkrycie: zaimplementowany model dziedziny jest zupełnie inny niż w projekcie.

Gdyby zrobili zgodnie z projektem integracja była by znacznie tańsza (co sami przyznali) a teraz czeka tę firmę alternatywa: kara za wykonanie zmian w projekcie poza umową, praca poniżej kosztów, wszyscy się chandryczą bo czas ucieka....

Temat: A ja się dziwię programistom, przepraszam Was...

Programiści owszem, mają tendencję do upraszczania, ale od czegoś tam byli kierownicy i osoby decyzyjne. Jeśli powiedzieli programistom "panowie, weźcie to i zróbcie po swojemu, szczegóły nas nie interesują", to owszem, mogło tak być. Programiści zwykle nie mają dostępu do informacji o tym, jak będzie wyglądać dalsze życie produktu. Mogli stwierdzić "ale gość nawydziwiał" (nie mając tej wiedzy o potencjalnych integracjach, etc.) i poupraszczali wiele rzeczy, wbrew DDD. A może tak ich przyzwyczajono pisać w tamtej firmie? Programista programiście nie równy, jedni to składacze klocków/klikacze w kreatory, inni to znów "młodzi Einsteini" na zasadzie "jak by to jeszcze skomplikować", a jeszcze inni są na prawdę dobrzy w tym, co robią. Sporo programistów nie zna SQLa (i często to właśnie ci strasznie kochają ORMy i wychwalają pod niebiosa, ale nie ze względu na ich rzeczywiste zalety, a nieznajomość SQLa właśnie :) efekt ten sam, powód inny), UMLa, a wiekszość ich algorytmów działa nieomal w czasie wykładniczym ;)

Ale jeśli wziął to na tapetę przed nimi ktoś decyzyjny i stwierdził powyższe ("ale gość nawydziwiał") i dał to programistom z poleceniem "uproszczenia tematu", to pada teraz pytanie - czy odbiorca został poinformowany, że ingerowanie w przedstawiony model dziedziny może spowodować a), b), c), d)?

Jeśli tak - to ich problem. Jeśli nie - to cóż, trzeba na przyszłość informować, że: "panowie, płacicie mi za coś i ja to robię. Jeśli szanujecie SWOJE pieniądze i SWÓJ czas, a dodatkowo jeszcze JA BIORĘ za to, co robię odpowiedzialność, to dla własnego dobra NIE ingerujcie w to. By nie być gołosłownym, potencjalne ryzyko jest następujące: ....".

Temat: A ja się dziwię programistom, przepraszam Was...

Piotr Głudkowski:
Oj, Jarek, wygląda to jakbyś dzielił ludzi na lepszych i gorszych :)

Ale jeśli nie musimy zachowywać poprawności politycznej to tak właśnie jest. Znam lepszych analityków(zrobią bdb projekt w miesiąc): Jarka, Rafała, Marcina
Gorszych analityków (zrobią bdb projekt w 2 miesiące): siebie
i zupełnie złych, których projekt jest tak niejednoznaczny, że taniej wykonać go od nowa, niż wyjaśniać implementując
Znam lepszych architektów/lead programistów (zrobią bdb implementację tego projektu w 450rbh): Grzegorza, Deepaka
Gorszych (zrobią bdb implementację tego projektu w 600-900 rbh): Michała, Jakuba
i zupełnie złych, którzy po 600rbh dostarczą coś niezgodnego z projektem co nie działa i poprawienie zajmie dłużej niż napisanie od nowa

Programiści mają nie myśleć, nie ułątwiać sobie pracy, nie optymalizować kodu (z myślą o ułatwieniu przyszłego jego utrzymania), tylko mają z pokorą i bez zastrzeżeń realizować model nieomylnego analityka?

Mają myśleć, ułatwiać sobie pracę i optymalizować kod w ramach realizacji modelu. Jeśli optymalizacja kodu ma zmienić model, muszą zapytać analityka czy mogą, ponieważ "premature optimalisation is the root of all evil". Potem się okazuje, że ktoś optymalizując kod pod raporty zamiast 2 klas robi jedną i przy planowanej rozbudowie systemu koszty rosną 10-krotnie, bo model został zmieniony.

Nie podoba mi się to.
Analiza biznesowa chyba przecież nie jest "sztuką dla sztuki", ale stanowi raczej pewną warstwą pośrednią pomiędzy biznesem a projektowaniem i kodowaniem - i tutaj całą rola analizy polega na tym, żeby wymyślać modele tak, żeby dały się wygodnie i serwisowalnie implementować.

Tak. Więc jeśli model przygotowuje dobry analityk i model jest dobry to bez konsultacji wara dotykać. Jeśli zakładamy, że model jest błędny to zmieńmy analityka.

Temat: A ja się dziwię programistom, przepraszam Was...

Adrian Olszewski:
Programiści owszem, mają tendencję do upraszczania, ale od czegoś tam byli kierownicy i osoby decyzyjne. Jeśli powiedzieli programistom "panowie, weźcie to i zróbcie po swojemu, szczegóły nas nie interesują", to owszem, mogło tak być.

czyli uczciwość... poszła

Programiści zwykle nie mają dostępu do informacji o tym, jak będzie wyglądać dalsze życie produktu.

i raczej nie będą mieli...

Mogli stwierdzić "ale gość nawydziwiał" (nie mając tej wiedzy o potencjalnych integracjach, etc.) i poupraszczali wiele rzeczy,

tego właśnie szanujący się nawzajem ludzie nie robią...

Sporo programistów nie zna SQLa (i często to właśnie ci strasznie kochają ORMy i wychwalają pod niebiosa, ale nie ze względu na ich rzeczywiste zalety, a nieznajomość SQLa właśnie :) efekt ten sam, powód inny), UMLa, a wiekszość ich algorytmów działa nieomal w czasie wykładniczym ;)

rzecz w tym, że większość programistów po nauce Pascala i diagramów ERD na studiach najpierw (lub rónolegle) projektuje bazę danych a potem dorabia do tego kod aplikacji i to jest tragedia bo tu faktycznie musi dojść do kompromisowych uproszczeń...

jeżeli ktoś pisze na swojej stronie w zakładce Kompetencje "nowoczesne metody obiektowe" to:
- najpierw prowadzi analizę obiektową
- tworzy obiektowy model systemu i testuje go
- implementuje zatwierdzony model
projektowanie bazy danych jest na samym końcu procesu - to implementacja - i nie "baza danych RBDMS" a implementacja utrwalania obiektów (a to nie to samo).

Ale jeśli wziął to na tapetę przed nimi ktoś decyzyjny i stwierdził powyższe ("ale gość nawydziwiał") i dał to programistom z poleceniem "uproszczenia tematu",

to doskonały powód by firmy programistyczne nie prowadziły etapu analizy i projektowania

to pada teraz pytanie - czy odbiorca został poinformowany, że ingerowanie w przedstawiony model dziedziny może spowodować a), b), c), d)?

nie został, jak zapewne wiesz, żaden dostawca nie pisze pism projektowych: Panie Prezesie, ratując marże znacznie upraszczamy Pana projekt i implementację, jednak koszty przyszłej rozbudowy wzrosną o rząd wielkości dzięki temu także nasze przychody, jesteśmy zadowoleni ze współpracy z Państwem., za to prawie każdy dostawca ma w planie odrabiania niskiej ceny w przetargu...Jarek Żeliński edytował(a) ten post dnia 30.06.11 o godzinie 13:59

Temat: A ja się dziwię programistom, przepraszam Was...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:50

Temat: A ja się dziwię programistom, przepraszam Was...

Paweł Włodarski:

Jarek Żeliński:
Jak piszecie kod, którego celem jest szyfrowanie transmisji, renderowanie obrazków itp. to róbcie to jak najlepiej potraficie ale jak implementujecie model dziedziny to dajcie mu spokój, to nie Wasz problem, po protu skopiujcie go, a jak Wasz analityk nie potrafi Wam dać takiego modelu obiektowego to zmieńcie analityka...

A jeśli programiście twierdzą, że analityk nie potrafi dostarczyć właściwego modelu dziedziny zaś sam Analityk uważa, że model jest doskonały to trzeba skopiować model czy z pokorą wymienić analityka ;)?

Programista nie może twierdzić że tak jest bo model dziedziny weryfikuje się z biznesem a nie z programistą, ponieważ to biznes daje nam informacje o tym jak wygląda dziedzina.
To wiedza organizacji dla której tworzymy system musi dać odpowiedź na to jakimi obiektami będzie operowała.
Programista jest jak murarz. Jeśli jego doświadczenie podpowiada że w danym miejscu można ściankę z karton-gipsu - niech zapyta czy może - ale sam zmienić tego nie może, bo potem ktoś powiesi na tej ściance drążek do wymyków i ktoś się zabije.Mateusz Kurleto edytował(a) ten post dnia 30.06.11 o godzinie 21:29

Temat: A ja się dziwię programistom, przepraszam Was...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:50

Temat: A ja się dziwię programistom, przepraszam Was...

To wszystko się zgadza poza przypadkami kiedy jest inaczej. Doceniam twój post ale teraz chciałbym aby Jarek mi odpisał, bo jak zrozumiałem z jego wypowiedzi on dopuszcza opcję wymiany analityka przez programistów.

oczywiście, dopuszczam sytuację, w której np. implementujący developerzy zmieniają (zwalniają) analityka, ale pod jednym warunkiem: oni go zatrudniali, bo jeżeli analityka zatrudnia inwestor (nabywca oprogramowania) to uczciwy developer może:
1. wykonać projekt
2. odstąpić od wykonania projektu

Temat: A ja się dziwię programistom, przepraszam Was...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:37

Temat: A ja się dziwię programistom, przepraszam Was...

Paweł Włodarski:

Jarek Żeliński:
oczywiście, dopuszczam sytuację, w której np. implementujący developerzy zmieniają (zwalniają) analityka, ale pod jednym warunkiem: oni go zatrudniali, bo jeżeli analityka zatrudnia inwestor (nabywca oprogramowania) to uczciwy developer może:
1. wykonać projekt
2. odstąpić od wykonania projektu

Wiesz, najbardziej interesuje mnie tutaj aspekt możliwości posiadania przez (nazywanych w skrócie) developerów pewnych uwag co do prac analityka.
Weźmy teraz przykład po środku zakładający, że 50% z tych uwag jest zasadnych.

Kto ocenia ich zasadność? Developer? Skoro dwie strony są w sporze to wypadało by zlecić ocenę trzeciej strony, i znam takie przypadki. Nie mniej jednak czas na uwagi do projektu jest przed przyjęciem projektu do realizacji, potem już "nie wypada" się budzić z uwagami skoro się wcześniej złożyło ofertę na realizację projektu...

Dodatkowo załóżmy, co jest chyba dość często spotykaną okolicznością, że owi developerzy nie mają władzy aby odstąpić od wykonania projektu co twoim zdaniem powinni w takiej sytuacji zrobić?

jak to ktoś napisał tu w innym wątku "albo siedzisz w tym bo akceptujesz albo nie akceptujesz i wychodzisz", to także w kontekście uczciwości... jak mi ktoś proponuje robienie bełkotu to odmawiam, jak każe to rezygnuje z tej roboty..

Użyłeś słowa "uczciwy" w dosyć dziwnym kontekście. Czy osobę, która zrobi cokolwiek nie zgadzając się z tym co robi nazwiesz uczciwą ? Trochę to dziwne.

nie rozumiem dlaczego "dziwnym", to proste: dostajesz pytanie o projekt do realizacji i albo składasz ofertę a potem zgodnie z ofertą realizujesz zlecenie albo nie składasz oferty bo uważasz, że projekt jest wg. Ciebie nierealizowalny. Możesz ewentualnie w ofercie zgłosić zastrzeżenia, które inwestor ewentualnie przemyśli. Ale złożenie oferty a potem psioczenie lub wręcz ignorowanie projektu bez zgłoszenia tego faktu jest po protu nieuczciwe. I niestety takie próby są dość powszechne, i nawet nie dlatego, że projekt był zły a dlatego, że są to nieautoryzowane uproszczenia projektu w celu rozpaczliwego ratowania marży po wygraniu ceną...

Temat: A ja się dziwię programistom, przepraszam Was...

Wydaje mi się, że tej dyskusji zaczynamy obracać się wokół pojęcia środowiska wysokiego zaufania i niskiego zaufania.

W środowisku wysokiego zaufania wśród uczestników projektu panuje zaufanie, to że każdy z nich wykonuje swoją pracę profesjonalnie i rzetelnie. Każdy uczestnik projektu skupia się na zadaniach dla niego przeznaczonych.

W środowisku niskiego zaufania każdy zaczyna zastanawiać się i weryfikować pracę pozostałych uczestników projektu. Programista podważa prace projektanta, projektant prace analityka, analityk nadinterpretuje słowa klienta. Doprowadza to do znacznych opóźnień w projekcie.

Niestety, to co ja często obserwuję w Polsce, dochodzi trzecia klasyfikacja środowisk projektowych. Środowiska kompletnego braku zaufania. Programista przeprojektowuje, projektant wykonuje analizy, analityk decyduje o zakresie funkcjonalnym, a project manager jest zbędnym balastem.

Trochę przejaskrawiłem, ale problem wygląda mniej więcej tak. Skąd się bierze --- nie wiem. Może za dużo mamy inżynierów i magistrów? Może na uczelniach prywatnych mamy za niski poziom nauczania? Może studia powinny być prowadzone w formule projektowej, a nie na zasadzie wykładów i egzaminów? Nie wiem.

Moim zdaniem, ten konkretny opis jest definicją programowania "obiektalnego" (obiektowo-strukturalnego) :) Użycie terminów programowania strukturalnego do wyjaśnienia programowania obiektowego moim zdaniem na samym początku spacza naukę: tak, obiekty to moduły, metody to funkcje, a stałe i zmienne to pola (taka inna nazwa).

Temat: A ja się dziwię programistom, przepraszam Was...

Niestety, to co ja często obserwuję w Polsce, dochodzi trzecia klasyfikacja środowisk projektowych. Środowiska kompletnego braku zaufania. Programista przeprojektowuje, projektant wykonuje analizy, analityk decyduje o zakresie funkcjonalnym, a project manager jest zbędnym balastem.

Trochę przejaskrawiłem, ale problem wygląda mniej więcej tak. Skąd się bierze --- nie wiem.

trzy tygodnie temu byłem na konferencji, gdzie dokładnie ten temat poruszono w kuluarach, jeden z uczestników - kierownik wielu projektów IT - potwierdzając powyższe, powiedział: "jednym z największych ryzyk projektów jest programista z nadmiarem testosteronu, niestety dowiadujemy się o tym dopiero jak spaprze projekt".

;)

Temat: A ja się dziwię programistom, przepraszam Was...

To może wynikać z trzech sytuacji.

Pierwsza. Bardzo dużo jest firm, gdzie programista jest jednocześnie projektantem i analitykiem, albo kolejno pełnił te funkcje. Nawet w większych korporacjach nie jest to wyjątek. Ścieżki awansu potrafią być bardzo różne. Zresztą nie tylko awansu, ale zwykłych kolei życia i "podróży po firmach". Dziś programista tu, jutro analityk tam. A ponieważ często jednak można spotkać się z niekompetencją dziedzinową, to ktoś, kto pracował wcześniej jako ekspert dziedzinowy, gdy potem staje się projektantem albo inżynierem naturalnie (automatycznie) wyłapuje niedociągnięcia analityka w zakresie określenia dziedziny (pojęć, reguł). I to jestem w stanie zrozumieć, bo znam z praktyki. Ktoś wtedy zwykle odpada - albo "wątpliwy ekspert, który wtrynia swoje 3 grosze gdzie nie trzeba", albo denny analityk. To już musi ktoś zweryfikować. Tutaj jest zatem problem niekompetencji dziedzinowej analityka.

Inna sytuacja, to gdy osoba, która ma duże doświadczenie dziedzinowe, "staje się" analitykiem, którego rolą jest wyprodukowanie formalnej analizy. Nie ma dużego pojęcia o projektowaniu, wzorcach, tych wszystkich niuansach, nad którymi toczą się dyskusje w tej grupie, ale jest cennym ekspertem dziedzinowym i jednocześnie pomostem między firmą a klientami (nie zawsze klient jest ekspertem dziedzinowym ;) ). Widać to szczególnie wyraźnie w projektach, gdzie pisze się produkt wg własnych analiz, który następnie weryfikuje grupa odbiorców, a na tej podstawie tworzy się listę zmian (spirala). Jeśli trafimy na sytuację, gdy ów ekspert, ale jednocześnie początkujący analityk tworzy analizę, która potem trafia do osoby, która wcześniej pełniła funkcję analityka, ma w tym doświadczenie, to ta weryfikacja pracy i zgłaszanie uwag następuje często. I tę sytuację także znam z otoczenia. Ale tutaj sytuacja naturalnie się rozładowuje w miarę, jak analityk nabiera umiejętności. Tutaj jest problem niekompetencji "analitycznej" analityka.

Najczęściej zresztą (w małych i dużych firmach) spotykałem się z sytuacją, gdzie ekspert dziedzinowy, zwany analitykiem, tworzył "średnio formalny" dokument (i nie tykał się niczego związanego z IT i projektowaniem, poza GUI, UC i paroma diagramami) i spotykał się z projektantem, który dopiero modelował, a jednocześnie określał architekturę systemu, łącznie ze szczegółami technicznymi, inżynierskimi. Programista dostawał do pisania kod. Stąd mój nawyk do bliskiego łączenia funkcji architekta i projektanta. A często spotykałem połączenie wszystkich trzech funkcji (+analityk) w "dział analiz i projektowania".

Trzecia sytuacja wreszcie - i tę trudno mi zrozumieć (chociaż też się z nią spotkałem), to gdy dana osoba nie posiada wiedzy dziedzinowej ani na temat architektury systemu, ani na temat projektowania obiektowego, ale wprowadza własne poprawki. Czyli - programista upraszcza dziedzinę (pomimo nalegania analityka, by tego nie czynił), a analityk, zamiast pozostać przy terminie "kontrakt" bądź "interfejs", zaczął wchodzić w szczegóły architektoniczne (co się zdarza często), uparł się na webserwisy, chociaż w danym rozwiązaniu od dawna funkcjonują foldery wymiany plików, wymiana informacji przez bazę danych bądź gniazda i nikt nie będzie przerabiał medium transmisyjnego.

Tępiłem i tępię samowolne zmiany w projekcie, ale jestem także bezwzględny w zakresie braku przepływu informacji: "dlaczego nie zapytałeś?", "co jeszcze powinienem wiedzieć na ten temat?", "czy ktoś ma jeszcze jakieś uwagi na ten temat?. Specjalizacja jest cenna, ale nie może być nigdy oderwana od reszty projektu "każdy sobie rzepkę skrobie". Nie lubię po prostu sytuacji, gdzie potem każdy umywa ręce od problemu, mając swój RWD ("Ratuj Własną D...") - "ja swoje zrobiłem, reszta mnie nie interesuje, oto maile, podkładki" i winnego brak, a projekt leży. Oczywiście NIE oznacza to, że tester ma weryfikować kod, programista pisać scenariusze testowe, a analityk zajmować się wyciekami pamięci. To nie o to chodzi. Są jednak miejsca styku specjalizacji, gdzie nie może być muru, tylko przepływ informacji. Jeśli go brak, a pojawiają się niedomówienia, zgrzyty, to rodzi się brak zaufania, którego potem trudno się pozbyć.

Zapewne inaczej wygląda to, gdy produkt jest pisany na zamówienie klienta, a więc etapy analizy, projektowania, produkcji są pasmem następstw, a nie spiralą przy już istniejących rozwiązaniach (a także nowo zakupionych, odziedziczonych), a także gdy wykonawcami poszczególnych etapów są firmy zewnętrzne, specjalizujące się w danym zagadnieniu i świadome tego, że w dobie wielkiej konkurencji wpadka może oznaczać utratę kontraktu.Adrian Olszewski edytował(a) ten post dnia 04.07.11 o godzinie 13:07

Temat: A ja się dziwię programistom, przepraszam Was...

Adrian: opisałeś pięknie wszystkie chyba antywzorce :), niestety piszesz prawdę...

Temat: A ja się dziwię programistom, przepraszam Was...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:37

Temat: A ja się dziwię programistom, przepraszam Was...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:38

Temat: A ja się dziwię programistom, przepraszam Was...

Paweł Włodarski:

Aleksander Olszewski:
Trochę przejaskrawiłem, ale problem wygląda mniej więcej tak. Skąd się bierze --- nie wiem. Może za dużo mamy inżynierów i magistrów? Może na uczelniach prywatnych mamy za niski poziom nauczania? Może studia powinny być prowadzone w formule projektowej, a nie na zasadzie wykładów i egzaminów? Nie wiem.

Cześć,

Na uczelniach ogólnie mamy za niski poziom nauczania ale tutaj jest dla mnie interesujący jeszcze jeden aspekt jeśli już zastanawiamy się dlaczego jest tak a nie inaczej.

Powiedz ilu znasz ludzi, którzy mają 10 lub więcej lat doświadczenia w tworzeniu kodu?

PS. Może tym razem uda nam się uda podyskutować ;)

Moim zdaniem problem z uczelniami jest taki, że
1. uczą zbyt jednotorowo - zbyt mały przegląd możliwych technologii i rozwiązań, po uczelni ludzie mają "klapki na oczy" w jedną stronę
2. zbyt duże przywiązanie do indywidualnego oceniania - ludzie nie potrafią współpracować w grupie i brać odpowiedzialności wspólnie za los projektu
3. zbyt dużo teorii i zbyt mało ćwiczeń w których to student sam dojdzie do rozwiązania i wtedy pokaże się mu teorię jaka za tym stoi

Takie moje 2 grosze ;)

Temat: A ja się dziwię programistom, przepraszam Was...

Paweł Włodarski:
Napisałeś, że Ty byś rzucił robotę a co gdybyś jednak nie mógł jej rzucić?

podaj przykład dlaczego? żyjemy w wolnym kraju ...

Napisałeś "dostajesz pytanie o projekt do realizacji", a co jeśli go nie dostajesz? Co jeśli pracujesz w metodyce RUB? (w końcu z kolegami za wszelką cenę chcesz z programistów zrobić murarzy :)).

co to jest RUB? Chodzi o RUP? to jest implementacja...

niczego nie robię za wszelka cenę, po drugie logika biznesowa to ledwie kilka procent kodu więc "informatycy" maja co robić i daleko jestem od robienia z nich murarzy (chyba, że klepią kretyński kod jak małpy pod zlecenie PM'a, który musi rano wystawić fakturę za cokolwiek...)

Próbujesz mimo wszystko wykonać swoja prace jak najlepiej i zauważasz ryzyko w projekcie. Masz teraz zamknąć usta bo mówić prawdy na tym etapie "nie wypada"?. No świetna definicja uczciwości:)

gdzie tak napisałem? Ja raczej właśnie "mówię" prawdę, czytaj bez emocji ...

Jakkolwiek podkreślę, że nie wiem w jakich warunkach wykonujesz projekt. Jeśli współpracujesz głównie z jednoosobowymi działalnościami gospodarczymi to sytuacja jest faktycznie troszeczkę inna i tutaj przyznam ci rację, że owi ludzie nie powinni się zobowiązywać do czegoś czego nie wykonają.

pracuję czasem nawet z całym zespołem w Play.... albo przekazuje wymagania na system za kilka baniek.. nie wartościuj tak bo to ślepa uliczka...