Bezsens pisania kodu dla korporacji

Cześć,

Czy nie macie czasami wrażenia, że całe pisanie kodu biznesowego dla korporacji to bezsens i programiści nie powinni się podejmować takiej pracy?
Dostajecie jakieś małe albo większe zadanie, które musicie wkomponować w jakiś legacy kod, który przeważnie jest napisany beznadziejnie.
Programiści w szczególności nie powinni pracować w zespołach, gdzie biznes czymkolwiek zarządza jak np. wybór kolejnej funkcji która ma zostać zaimplementowana.

Biznes powinien móc co najwyżej napisać sobie listę funkcji, które chce mieć w systemie a od IT dostać odpowiedź, że dostanie kiedy dostanie.

Czy nie jest bezsensem całe estymowanie w story pointach i ile czasu coś zajmie, jeżeli i tak nie jesteśmy opłacani od ilości wykonywanych zadań?
Czy jest sens tracić 2 dni z 10 na różne planowania itp.

Nie. Coś czego programiści często nie rozumieją:

business value > code quality

Kiedyś też nie rozumiałem np. dlaczego firmy biorą projekty, chociaż nie mają pokrycia zespołu. Skutkowało to opóźnieniami w dostarczaniu funkcjonalności. Gdy przyszedł kryzys zrozumiałem po co.

Business value to jest jakiś mit, który powinno się zakopać. Moim zdaniem jest to bardzo krótkowzroczna praktyka.
Jeżeli tak podchodzimy do tematu to mamy masę beznadziejnego kodu, który z czasem coraz trudniej jest rozwijać.
Business value szybko od razu, kosztem długu technicznego, którego nigdy, albo bardzo rzadko można poprawić.

Bo IT jest dla biznesu a nie na odwrót, mamy dostarczyć wartośc która można sprzedać a nie przeprowadzać heksagonalną trzepaninę nad wzorcami i jakością kodu.

snakeomeister napisał(a):

... dla korporacji to bezsens i programiści nie powinni się podejmować takiej pracy?

Ale nie musisz. Załóż swój biznes, nie będziesz zależał od nikogo itd...
Żadnemu korpo nie będziesz służył ...

AnyKtokolwiek napisał(a):

snakeomeister napisał(a):

... dla korporacji to bezsens i programiści nie powinni się podejmować takiej pracy?

Ale nie musisz. Załóż swój biznes, nie będziesz zależał od nikogo itd...
Żadnemu korpo nie będziesz służył ...

Nie chodzi mi o to, żeby od nikogo nie zależeć.
Chodzi mi o bezsens całego procesu wytwarzania oprogramowania.

snakeomeister napisał(a):

Chodzi mi o bezsens całego procesu wytwarzania oprogramowania.

Ależ nie ma problemu. Możesz sfinansować dowolny inny proces.

Ja sie podejmuje bo dobrze płacą. Jak beda chcieli to bede w paincie malował obrazki byle płacili. A jakoś kod, wzorce, jakies wywody o sensie czy bezsensie to kazdy ma w dupie ( ze mna na czele )

"Programiści w szczególności nie powinni pracować w zespołach, gdzie biznes czymkolwiek zarządza jak np. wybór kolejnej funkcji która ma zostać zaimplementowana."

Bzdura ( i nie dlatego ze mylisz funkcje z funkcjonalnoscia ) . Biznes sprzedaje produkt i decyduje o kierunku rozwoju. IT bez biznesu nie ma, znajmy swoje miejsce....

Moim zdaniem w korpo problemem są tutaj różnego rodzaje proxy typu, jakiś product owner który nie wie co robi, manager, scrum master i inni tego typu. Jeśli komunikacja jest bezpośrednio biznes - programiści to jest dobrze bo przynajmniej wiesz po co dokładasz ten kawałek kodu do legacy. Pod tym względem mi się dobrze pracowało w software house, gdzie po prostu jechałem do klienta i sobie rysowaliśmy po tablicy co, jak i po co. Co do estymowania w story pointach to strata czasu i głupota i takie zdanie ma nawet scrum master w moim korpo no ale taka moda.

a business value tak naprawdę jest często "pokaże że mam dłuższego" jakiegoś menażera średniego szczebla
ci, którzy programu używają chcieliby coś innego, programiści widzą że ma to sens techniczny, ale nieeeee, trzeba pokazać ze pointy-haired-boss tu rządzi

ToBeSpecific napisał(a):

Ja sie podejmuje bo dobrze płacą. Jak beda chcieli to bede w paincie malował obrazki byle płacili. A jakoś kod, wzorce, jakies wywody o sensie czy bezsensie to kazdy ma w dupie ( ze mna na czele )

teraz to już wychodzi z ciebie typowy polski "programista" klepacz crudów, brak skilla, brak ambicji

aoeuidhtn napisał(a):

ToBeSpecific napisał(a):

Ja sie podejmuje bo dobrze płacą. Jak beda chcieli to bede w paincie malował obrazki byle płacili. A jakoś kod, wzorce, jakies wywody o sensie czy bezsensie to kazdy ma w dupie ( ze mna na czele )

teraz to już wychodzi z ciebie typowy polski "programista" klepacz crudów, brak skilla, brak ambicji

Heh, to mi przypomina jak dostałem ofertę na testowanie lokalnie w Bielsku Białej a jak aktualnie siedziałem 40 km po drugiej stronie Katowic (jakieś 80 km od BB) i odpowiedziałem iż za dwa razy więcej niż teraz (w zasadzie to wtedy) zarabiam to mogę robić wszystko byle legalne :D

snakeomeister napisał(a):

Czy nie macie czasami wrażenia, że całe pisanie kodu biznesowego dla korporacji to bezsens i programiści nie powinni się podejmować takiej pracy?
Dostajecie jakieś małe albo większe zadanie, które musicie wkomponować w jakiś legacy kod, który przeważnie jest napisany beznadziejnie.

I to ten beznadziejny kod napisał? Pewnie ludzie z biznesu?

Programiści w szczególności nie powinni pracować w zespołach, gdzie biznes czymkolwiek zarządza jak np. wybór kolejnej funkcji która ma zostać zaimplementowana.

Szkoda tylko iż to biznes zarządza budżetem :(

Biznes powinien móc co najwyżej napisać sobie listę funkcji, które chce mieć w systemie a od IT dostać odpowiedź, że dostanie kiedy dostanie.

To nawet nie jest takie głupie. Jeszcze by dodali priorytety i mamy coś w rodzaju kanbana

Czy nie jest bezsensem całe estymowanie w story pointach i ile czasu coś zajmie, jeżeli i tak nie jesteśmy opłacani od ilości wykonywanych zadań?
Czy jest sens tracić 2 dni z 10 na różne planowania itp.

A to racja. iż SP są bez sensu. Ja nawet wpadłem na pomysł iż proste rzeczy powinny być estymowane na dużo a trudne na mało. Bo jak nie dowieziesz dużej to mówisz ale to tylko 2 SP, a za to zrobiłem dwa inne zadania na 5 SP

Biznes powinien móc co najwyżej napisać sobie listę funkcji, które chce mieć w systemie a od IT dostać odpowiedź, że dostanie kiedy dostanie.

Wyobraź sobie, że rząd mówi, że od 1 lipca wchodzi KSeF (faktury elektroniczne), biznes mówi do IT "chcemy obsługi KSeF", a IT mówi "30 grudnia!" xD

U mnie w pracy po 3 latach projektu widać cięcie na jakości, pytam się programistów dlaczego tak kod słabo napisany i brak testów.

• „Bo biznes chciał szybko” xD

A niby pracują w Agile i Scrumie.

Albo pytam się gościa dlaczego to tak tak słabo napisane?

• „Bo miałem tylko na to dwa tygodnie”

W Scrumie nie wolno robić czegoś dłużej niż dwa tygodnie, to taki cynizm.

Albo query do bazy idzie 25 sekund, pytam się dlaczego to tak zrobione.

• „Bo nie było czasu”.

Ogólnie to wnioski moje są takie że po prostu niektórym młodym programistom brakuje tzw. jaj i pewności siebie. Komunikowania problemów związanych z daną implementacją oraz jak to wpłynie na przyszłość projektu i wydajność. Najlepiej by był w zespole Lider techniczny który umie powiedzieć „stop” oraz któremu ludzie z biznesu ufają. Brakuje bardzo takich ludzi.

Druga sprawa też jest taka że przez ostatnie 5 lat do IT weszło masę ludzi z ulicy na stanowiska managerskie, product ownerskie, scrum masterskie i mają często zielone pojęcie o IT. Nie mówię że mają być programistami ale pasowałoby by choć trochę się interesowali. A tutaj nic. W takich projektach jest najwięcej potem patologii bo jest trywializowanie i spłaszczanie wszystkiego.

Przecież gdyby biznes rozkminił ze 100% efektywnością co jest potrzebne, to większość programistów, w tym forumowych asów kręcących bekę z ludzi aktualnie nie mogących znaleźć pracy (oni aktualnie wstrzelają się w chwytliwe bubble w roadzju ML) wylądowałaby na bruku. Aktualnie do klepania crudów wystarczy maks kilkadziesiąt tys worldwide, plus pare tysięcy do cutting-edge AI/ML i to jest wszystko, a w kolejcje swą kraje z MILIARDOWYMI populacjami ludzi którzy za wszelką cenę chcą się wyrwać z nędzy, z dostępem do internetu z wszystkimi możliwymi informacjami.

Ależ autystyczny temat. Ludzie chcą mieć aplikację na termin X i ma być zrobiona. Jeśli z dobrymi praktykami i wzorcami się nie da to leci spaghetti byle by zdążyć, normalka. Zwłaszcza jak to nie ma być nowy ficzer tylko zmiana istniejącego kodu, to lecą grube ify. Potem po dopięciu deadline warto zaproponować refactor.

Rexioo napisał(a):

U mnie w pracy po 3 latach projektu widać cięcie na jakości, pytam się programistów dlaczego tak kod słabo napisany i brak testów.

• „Bo biznes chciał szybko” xD

A niby pracują w Agile i Scrumie.

Albo pytam się gościa dlaczego to tak tak słabo napisane?

• „Bo miałem tylko na to dwa tygodnie”

W Scrumie nie wolno robić czegoś dłużej niż dwa tygodnie, to taki cynizm.

Albo query do bazy idzie 25 sekund, pytam się dlaczego to tak zrobione.

• „Bo nie było czasu”.

Ogólnie to wnioski moje są takie że po prostu niektórym młodym programistom brakuje tzw. jaj i pewności siebie.

Oraz wzięcia odpowiedzialności za to, co wypuszczają w świat.
Wypuścić program z bugami? Spoko, wypuszczają, bo biznes kazał.
Wypuścić coś, co będzie zamulało aplikację? Wypuszczą, bo "nie było czasu" zrobić dobrze.
Wypuścić coś, co będzie powodowało realne straty pieniędzy z powodu długu biznesowego? Też wypuszczą, bo przecież "biznes chciał szybko".

Wujek Bob ostrzegał przed takim podejściem, że o ile teraz programiści to święte krowy, to w końcu ktoś kiedyś może ich pociągnąć do odpowiedzialności za to, że wpuszczają zabugowany kod (@Riddle pamiętasz może, gdzie to było? Gdzie Wujek Bob mówił o hipotetycznym scenariuszu, że programista napisze kod, który spowoduje wypadek, a później hipotetycznie państwa wprowadziłyby regulacje zawodu i gdzie radził, żeby programiści jako cała społeczność zastosowała uderzenie wyprzedzające i żeby programiści sami przyjęli dyscyplinę i etykę zawodu).

Drzewiec napisał(a):

Ależ autystyczny temat. Ludzie chcą mieć aplikację na termin X i ma być zrobiona. Jeśli z dobrymi praktykami i wzorcami się nie da to leci spaghetti byle by zdążyć, normalka. Zwłaszcza jak to nie ma być nowy ficzer tylko zmiana istniejącego kodu, to lecą grube ify. Potem po dopięciu deadline warto zaproponować refactor.

Okej, ale jeśli programista to posłuszny klepacz, który klepie bezmyślnie to, co mu każą, to za chwilę będzie zastąpiony za pomocą AI (dobra, część programistów się zostawi, żeby byli operatorami ChatGPT). Samo klepanie kodu to coś, co już teraz można zautomatyzować i ChatGPT też potrafi robić "grube ify". To, co najbardziej wartościowe dla biznesu, to nie klepańsko kodu, tylko głębsze spojrzenie i umiejętność połączenia strategii z taktyką. A jeśli programista rezygnuje z głębszego spojrzenia, tylko spaghetti byle by zdążyć, normalka, to jego pracę dość łatwo się zautomatyzuje.

Potem po dopięciu deadline warto zaproponować refactor.

"Potem" to dojdą kolejne wymagania i znowu nie będzie czasu.

Niekoniecznie "bezmyślnie klepie". Często celowo robi się gorszy kod, bo zleceniodawcy świadomie chcą szybko, a nie porządnie. Tak jest w każdej branży. Nawet w medycynie pacjentów na NFZ się przyjmuje taśmowo, żeby zdążyć z terminami. Przecież taki lekarz rodzinny mógłby coś dodać o suplementacji witaminą D, zasadach zdrowego odżywiania, zaleciłby regularne spacery i ćwiczenia pacjentom. Ale wypisze szybko antybiotyk na ból ucha i nara, bo kolejni pacjenci czekają w kolejce. Jeśli "biznes" nie da sobie przetłumaczyć, że ma być refactor, to ich problem, że wolą spaghetti.

LukeJL napisał(a):

Wujek Bob ostrzegał przed takim podejściem, że o ile teraz programiści to święte krowy, to w końcu ktoś kiedyś może ich pociągnąć do odpowiedzialności za to, że wpuszczają zabugowany kod (@Riddle pamiętasz może, gdzie to było? Gdzie Wujek Bob mówił o hipotetycznym scenariuszu, że programista napisze kod, który spowoduje wypadek, a później hipotetycznie państwa wprowadziłyby regulacje zawodu i gdzie radził, żeby programiści jako cała społeczność zastosowała uderzenie wyprzedzające i żeby programiści sami przyjęli dyscyplinę i etykę zawodu).

Chyba talk pod tytułem "Expecting professionalism":

Drzewiec napisał(a):

Niekoniecznie "bezmyślnie klepie". Często celowo robi się gorszy kod, bo zleceniodawcy świadomie chcą szybko, a nie porządnie. Tak jest w każdej branży. Nawet w medycynie pacjentów na NFZ się przyjmuje taśmowo, żeby zdążyć z terminami. Przecież taki lekarz rodzinny mógłby coś dodać o suplementacji witaminą D, zasadach zdrowego odżywiania, zaleciłby regularne spacery i ćwiczenia pacjentom. Ale wypisze szybko antybiotyk na ból ucha i nara, bo kolejni pacjenci czekają w kolejce. Jeśli "biznes" nie da sobie przetłumaczyć, że ma być refactor, to ich problem, że wolą spaghetti.

Otóż to. Właśnie taka usługa wykonana w gorszej jakości, ale dostarczona w szybszym czasie może mieć dużo większą wartość dla biznesu. Taka wymuskana, bez bugów, i łatwo utrzymywalna przez lata, ale dostarczona zbyt późno może być zupełnie bezwartościowa, bo np. okienko czasowe "opportunity" minęło.

Jeśli biznesowi zależy na czasie bardziej niż na jakości, to nie ma nic złego w dostarczeniu im takiej usługi - i to wcale nie musi być przejaw braku profesjonalizmu.

KamilAdam napisał(a):

I to ten beznadziejny kod napisał? Pewnie ludzie z biznesu?

Programiści, ale pewnie nie 1-2 tylko kilkudziesięciu średnio słabych.

Poniekąd można tak powiedzieć, bo jak sobie rozplanują jakiś feature na kilka mniejszych i nie mają pojęcia jak rozwiązanie wygląda w kodzie to właśnie oni są za to odpowiedzialni.
Powiedzmy że tworzą sobie epika na jakiś temat i pod nim kilkanaście user stories.
Na produkcję wchodzi połowa teraz bo ma business value, a druga połowa może wejść później kawałkami.
Po jakimś czasie zmienia się kilku devów, którzy robili początkowe zadania i nie do końca przemyśleli sprawę.
Nowi, którzy przyszli mają narzuconą starą wycenę i nie znają rozwiązania, które mają dokończyć w tym sprincie, czyli dowieźć powiedzmy pozostałe 30%.
Rozwiązanie jest rozbite na if-y w 20 różnych miejscach w systemie i wywołania różnych metod.
Nowi devowie pracują pod presją czasu, bo jak nie dowiozą to spadnie na kolejny sprint.
Robią i oddają do testów, po czym tester odkrywa, że jeszcze to nie działa i tamto nie działa, więc wraca do nich z błędami - spadło na kolejny sprint.
Kolejny sprint kolejne testy nowe błędy, jeden z nowych devów się frustruje i odchodzi, a na jego miejsce przychodzi ktoś nowy i uczy się rozwiązania od nowa.
Zadanie skończone feature jest na produkcji, ale zmienia się kontraktornia u klienta i teraz ma to rozwiązanie utrzymywać na produkcji nowy zespół po sesji KT.
Biznes o czymś jeszcze zapomniał i trzeba dodać małą historyjkę na 1-2sp i tak co jakiś czas.
Jak wygląda kod po czymś takim?
Kto tutaj jest winny?

Biznes powinien móc co najwyżej napisać sobie listę funkcji, które chce mieć w systemie a od IT dostać odpowiedź, że dostanie kiedy dostanie.

To nawet nie jest takie głupie. Jeszcze by dodali priorytety i mamy coś w rodzaju kanbana

I przyszli za miesiąc i zmienili priorytety :)

Rexioo napisał(a):

U mnie w pracy po 3 latach projektu widać cięcie na jakości, pytam się programistów dlaczego tak kod słabo napisany i brak testów.

• „Bo biznes chciał szybko” xD

A może np. powiedział biznesowi jakie to spowoduje problemy w przyszłości, ale biznesu to nie obchodzi.
Ma być po prostu szybko i działać?

A niby pracują w Agile i Scrumie.

I właśnie dlatego.

Albo pytam się gościa dlaczego to tak tak słabo napisane?

• „Bo miałem tylko na to dwa tygodnie”

Dokładnie, przecież w sprincie jest commitment i nic nie powinno spaść na kolejny.

W Scrumie nie wolno robić czegoś dłużej niż dwa tygodnie, to taki cynizm.

Albo query do bazy idzie 25 sekund, pytam się dlaczego to tak zrobione.

• „Bo nie było czasu”.

Patrz wyżej, biznesu nie obchodzi jak coś jest zrobione, ma być najszybciej i najtaniej jak to możliwe.
Możesz sobie narzekać, że kod jest powolny i w wielu miejscach zły, ale dopóki wydajnie działa na produkcji to twój głos nie będzie słyszany.
Jak produkcja zacznie zwalniać to zacznie się dokładanie kolejnych serwerów, więc nadal ok, więc może się okazać, że query które idzie 25 sekund to premature optymalizacja, jeżeli chiałbyś skrócić np. o połowę, bo np. jest wywoływane raz w miesiącu :D

Ogólnie to wnioski moje są takie że po prostu niektórym młodym programistom brakuje tzw. jaj i pewności siebie. Komunikowania problemów związanych z daną implementacją oraz jak to wpłynie na przyszłość projektu i wydajność. Najlepiej by był w zespole Lider techniczny który umie powiedzieć „stop” oraz któremu ludzie z biznesu ufają. Brakuje bardzo takich ludzi.

Niektórym ludziom z biznesu brakuje tzw. umiejętności słuchania osób zajmujących się wytwarzaniem oprogramowania.
Zwykłego użytkownika biznesowego nie obchodzi jak coś wpłynie na wydajność oprogramowania on chce mieć funkcjonalność A i tyle.

Druga sprawa też jest taka że przez ostatnie 5 lat do IT weszło masę ludzi z ulicy na stanowiska managerskie, product ownerskie, scrum masterskie i mają często zielone pojęcie o IT. Nie mówię że mają być programistami ale pasowałoby by choć trochę się interesowali. A tutaj nic. W takich projektach jest najwięcej potem patologii bo jest trywializowanie i spłaszczanie wszystkiego.

Nawet jeżeli się interesują to niewiele to pomaga.

@LukeJL:

spaghetti byle by zdążyć, normalka

Tworzenie spaghetti to akurat nie oszczędność czasu, a brak umiejętności. Realna oszczędność czasu jest np. gdy porzucamy pisanie testów, przebudowania architektury wraz z rozwijająca się aplikacją czy pisania dokumentacji.

"Nie mówię że mają być programistami ale pasowałoby by choć trochę się interesowali"

Ale bzdura, to mityczne PaSjOnOwAnIe SiĘ It

Pracowałem z wieloma pasjonatami, niepasjonatami i nie ma żadnej różnicy. Znam gości co podchodzą na zasadzie - do 8h pracy i jak starczy czasu to nauka w czasie pracy, a po pracy inne zajęcia - pasjonaci nie mieli podjazdu do tego fachowca i przychodzili po rady. Znam też pasjonatów co rzeczywiście jeździli po jakichś konferencjach, hackatonach, no żyli branżą - ale z kolei skille miękkie kulały, przejawiali zachowania typu "dam ci odczuć, że jestem lepszym koderem bom pasjonat - bez mówienia tego wprost" no wiecie o co chodzi, taka aura niefajna. Znałem też pasjonatów, którzy byli średni w kodowaniu i niepasjonatów którzy byli fatalni. Reguły brak.

Nie ma znaczenia czy jesteś pasjonatem czy też nie, to twoja osobista sprawa i za przeproszeniem - nie twój interes co kto robi po pracy. I zdecydowanie nikt nie powinien stygmatyzować kogoś bo się nie pasjonuje nudnym dla 90% społeczeństwa kodowaniem, to jest przede wszystkim praca i ma dostarczać nam pieniędzy. Ktoś musi wychowywać dzieci, zajmować się rodziną a nie poświęcać wieczory i weekendy na seminarium z czystego kodu i obczajać najnowsze wzroce projektowe i nowe frameworki/języki. Ba nawet powiem wiecej - to pozytywna cecha nowego pokolenia, że potrafią zadbać o swoje zdrowie psychiczne, przychodzą po 8h do pracy po pieniądze i nara, a po pracy robią inne rzeczy. Rodziny, nowe pokolenia na tym zyskają a nie ucierpią, tak samo wychowane dzieci gdzie rodzice byli obecni a nie zapracowani lub z głową w drugiej pracy po pracy (pasji) Chwała dobrym pasjonatom i chwała dobrym fachowcom nie-pasjonatom.

W żadnej branży nikt nie spotyka się z taką presja na pasjonowanie się branżą, nigdy nie słyszałem aby fryzjer, kosmetyczka, lekarz, prawnik musiał się czymś pasjonować - a przecież też mają sporo nauki w pracy, bo zmienia się moda, przepisy, metody leczenia.

ten sam wujek Bob który twierdził, że programista powinien poświęcać dodatkowe (nie pamiętam ile więc strzelam) 40h miesięcznie na samorozwój po pracy, bo inaczej nie powinien nazywać się programistą? Słaby autorytet w 2023 roku, w dobie wypalenia zawodowego wśród 80% programistów co popracują 5-10 lat, bo żyją wyłącznie kodowaniem i potem nie umieją odpoczywać :)

LukeJL napisał(a):

Wujek Bob ostrzegał przed takim podejściem, że o ile teraz programiści to święte krowy, to w końcu ktoś kiedyś może ich pociągnąć do odpowiedzialności za to, że wpuszczają zabugowany kod (@Riddle pamiętasz może, gdzie to było? Gdzie Wujek Bob mówił o hipotetycznym scenariuszu, że programista napisze kod, który spowoduje wypadek, a później hipotetycznie państwa wprowadziłyby regulacje zawodu i gdzie radził, żeby programiści jako cała społeczność zastosowała uderzenie wyprzedzające i żeby programiści sami przyjęli dyscyplinę i etykę zawodu).

Wujek Bob też mówił:

Uncle Bob in his book “The clean coder” has a very clear answer to his question: ”You should plan on working 60 hours per week. The first 40 hours are for your employer. The remaining 20 are for you.

A potem zdziwienie, że programiści pracują 240h miesięcznie i czują wypalenie zawodowe po 5-10 latach w branży, a żony i dzieci nienawidzą swoich nieobecnych ojców programistów. No coś za coś.

Nie mówię że ktoś powinien lub nie powinien kodować po pracy, ale dawanie takich sztywnych limitów skreśla jak dla mnie Wujka Boba z autorytetu, wszystko zależy od sytuacji. Jeśli ktoś koduje do 40h w tygodniowo i rozwija się w trakcie pracy i koduje może nie idealnie, ale chociaż przyzwoicie (fachowiec niepasjonata) - to nie mam zastrzeżeń

Tak samo jak ktoś z własnej woli pracuje 40h i dodatkowe 20h się dokształca po pracy - również nie mam zastrzeżeń. Ale ani 1 ani 2 nie powinien być stawiany jako lepszy czy wzór idealny. A może być też taki przypadek, że ktoś koduje 40h w pracy i 20h po pracy i dalej jest fatalny i pisze spagetti

To jest trochę inny temat, poza tym, wypaczasz argument.

Martinowi z tym 40h/20h, chodziło o to że nie można się nauczyć dobrze programować w pracy - większość "dobrej nauki" płynie z eksperymentów, i próbowania nowych rzeczy - coś, na co nie można sobie pozwolić w pracy. Z tym myślę nikt nie będzie polemizował.

Ale to jak znaleźć czas na takie eksperymenty, no to już inna sprawa.

bagietMajster napisał(a):

Bo IT jest dla biznesu a nie na odwrót, mamy dostarczyć wartośc która można sprzedać a nie przeprowadzać heksagonalną trzepaninę nad wzorcami i jakością kodu.

Powtarzam to od lat a i tak wielu nadal próbuje z tym system walczyć. To trochę jak z państwowymi przetargami / projektami. Liczy się idea którą można sprzedać. Cała reszta jest nieistotna.

Wujek Bob może ma kontrowersyjne poglądy, ale liczy się ogólne podejście do programowania XD

Riddle napisał(a):

Martinowi z tym 40h/20h, chodziło o to że

Właśnie. Ludzie nie rozumieją Wujka Boba i cytują kontrowersyjne wypowiedzi wyrwane z kontekstu. I teraz trzeba go tłumaczyć innym.

Martin to trochę taki Korwin programowania o tyle, że ma on bardzo betonowe podejście w wielu sprawach i mówi dogmatycznie, jak powinno być, jak programiści powinni się zachować, nie biorąc poprawki na to, że nie zawsze to przystaje do rzeczywistości.

snakeomeister napisał(a):

Business value to jest jakiś mit, który powinno się zakopać. Moim zdaniem jest to bardzo krótkowzroczna praktyka.
Jeżeli tak podchodzimy do tematu to mamy masę beznadziejnego kodu, który z czasem coraz trudniej jest rozwijać.
Business value szybko od razu, kosztem długu technicznego, którego nigdy, albo bardzo rzadko można poprawić.

Po pierwsze musiałbyś biznesowi pokazać czarno na białym ile będzie ich kosztował dług techniczny.
Jakbyś im powiedział: "Dług techniczny będzie Was kosztował 1mln USD do końca roku, mam na to wyliczenia. Możemy poświęcić miesiąc pracy i usuniemy 50% długu".
To wtedy oni by zaczęli kombinować: "Do końca roku wdrożymy ficzer X i Y, które razem nam przyniosą 400k zysku. No to lepiej usunąć dług techniczny, a potem wdrożyć ficzer Y"

Po drugie: Żaden z ludzi o biznesu nie dostanie premii za usunięcie długu techn. Oni dostają premie za nowy ficzer, który przyniesie ileś kasy. Nawet CEO startupu musi cisnąć na nowe ficzery, bo je obiecał inwestorom. A jak mówimy o CEO korpo, to on z kolei też ciśnie nowe ficzery, żeby ceny akcji nie spadły i dostał premię

Po trzecie: Czemu Cię to tak boli, że to jest niby bez sensu? Dostajesz kasę? Dostajesz. Zawsze możesz odpalić projekt open source i tam prowadzić zgodnie ze sztuką.
Z mojej perpsektywy dużo bardziej bez sensu by był projekt bez długu technicznego i bez wypłaty dla mnie. Dlatego bezsensowne biznesowe decyzje mi powiewają, dopóki dostanę kasę za spełnianie ich zachcianek. Moja w tym głowa, żeby menago był zadowolony, bo mnie nie wywali z roboty i kurek z kasą będzie odkręcony

Nie wiem kim jest ten "wujek bob" ale chłop powinien przede wszystkim pilnie popracować nad swoją wagą bo dostanie zwału albo choroby wieńcowej.