najzabawniejsze w takich tematach jest to że jakość, czysty kod - pojawia się wujek Bob i nikt więcej.
Kiedyś (tak 1-2 lata wstecz) na rozmowie specjalnie nie mówiłem o praktykach Boba udając że nie znam, ale wiele razy powoływałem się na Kenta Becka, Martina Fowlera, Goetza.
W efekcie zostałem sklasyfikowany jako coś pomiędzy juniorem a midem, podczas gdy goście sprawiali czasem wrażenie że mówię w innym języku.
Zwykle jest taki sens, że za to płacą. Ktoś chce za to płacić, więc pewnie mu potrzebne? Właściwie to nie zawsze, bo kapitalizm żywi się tworzeniem sztucznych potrzeb byle tylko sprzedać. Tylko kim ja jestem, żeby to oceniać? Tak więc staram się tego nie robić tylko pracować możliwie dobrze i możliwie szybko bez wypruwania sobie flaków. Żeby było zabawniej, dzięki temu idzie szybciej, bo nie pracuję w strachu, że nie ogarniam tego co robię (a może to lata praktyki w pracy i poza nią). Jest w tym jakiś sens, że jak sam nie umiesz założyć przedsiębiorstwa i stworzyć produkt/usługę to idziesz do pracy i oni ci mówią co masz robić, bo to oni wiedzą jak to sprzedać i chcą ponosić koszty mentalne prowadzenia biznesu, których mi może się nie chce na tą chwilę ponosić, a może jeszcze nie umiem.
Co się tyczy story pointów, to to już jest zwykła niekompetencja, że ludzie robią agile nie rozumiejąc o co w nim chodzi. Tak się ludzie na ogół uczą, że małpują póki nie załapią co jak i po co. Nie zawrócisz kijem Wisły.
snakeomeister napisał(a):
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.
Z cyklu "cytaty wielkich ludzi" :D
Kto płaci ten wymaga. Wyobraź sobie, że wsiadasz do taksówki w Warszawie i mówisz "pod Sejm", a kierowca zaczyna jechać do Łodzi i mówi ci, że na miejscu docelowym będziesz, kiedy będziesz.
Twoje narzekanie to narzekanie takiego taksówkarza, który chciałby jeździć po mieście i pokazywać fajne miejsca, a ci niewdzięczni klienci patrzą tylko na kasę, czas i czy w taksówce nie śmierdzi.
Wiecie co jest zabawne? Kolega w zasadzie opisał srum. PO ustawia priorytety w backlogu, zespół deweloperski sugerując się nimi dobiera rzeczy do sprintu. Robią to sami. Właśnie idea scruma to przerzysztoś pracy developerów oraz danie im bardzo dużej swobody w organizacji pracy w myśl tego, że oni wiedzą lepiej kiedy coś zrobią i jak.
i jak to dopiero jest groźne jak junior decyduje jak coś zrobi, za to zamiast technicznej osoby ustalającej co trzeba zrobić najpierw z technicznego punktu widzenia decyduje jakiś przydupas szefa czyli PO
Riddle napisał(a):
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ł.
Ja będę. Można i trzeba eksperymentować w czasie pracy i za pieniądze płatnika. Tylko trzeba to umieć przemycić.
Fajnie a jeśli kiepski kod to wcale nie wynik pisania na szybko przez niedoświadczonych programistów, ale właśnie wrzucania durnych pomysłów przez kierownictwo średniego szczebla (czyli takie które co prawda dostaje premie ale ma tak naprawdę wywalone na długoterminowe powodzenie całej firmy programistycznej).
Manago se wpisze do cv że projekt w jakimś nowym frameworku nadzorował, a to że trzeba było po roku go przepisać w czymś bardziej stabilnym to go nie obchodzi. Firma wydała mnóstwo kasy na poprawę nie tyle długu technicznego co błędów samego projektu i założeń, tez go nie obchodzi, swoją premię dostał. Programiści sfrustrowani kłótniami z idiotą odeszli, zostali sami juniorzy - no i spoko, będą bardziej się słuchać pana kierownika ;)
snakeomeister napisał(a):
Programiści, ale pewnie nie 1-2 tylko kilkudziesięciu średnio słabych.
Zadziwiające jest to, że prawie każdy tu piszący uważa się za tego dobrego programistę xD
Ja tam wiem, że jestem c****, może nie najtaniej, ale za to jako tako :-D
Miang napisał(a):
Fajnie a jeśli kiepski kod to wcale nie wynik pisania na szybko przez niedoświadczonych programistów
Jest dokładnie tak, każdy mówi że szybko szybko pisał, ale jak mu dać więcej czasu to się okaże że jednak lepiej nie umie.
marian pazdzioch napisał(a):
Miang napisał(a):
Fajnie a jeśli kiepski kod to wcale nie wynik pisania na szybko przez niedoświadczonych programistów
Jest dokładnie tak, każdy mówi że szybko szybko pisał, ale jak mu dać więcej czasu to się okaże że jednak lepiej nie umie.
W sumie to racja, ale niekiedy też zależy od tego jakiego typu to jest zmiana.
W pierwszej sytuacji może być tak, że lepiej tego nie ruszać po prostu dołożyć i zagmatwać jeszcze bardziej kod, ale oczywiście można napisać testy i zrobić refaktor.
Jeżeli na projekcie jest ciśnienie to wygra opcja 1, jeżeli nie to opcja 2. Ktoś może też stwierdzić, że pomimo ciśnienia wygra opcja 1, ale imho tutaj jeszcze nie można stwierdzić czy ktoś potrafi lepiej czy nie.
W drugiej sytuacji definitywnie już można stwierdzić czy ktoś potrafi lepiej czy nie.
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.
To jest oczywiście prawda. Wartość, którą można sprzedać jest bezpośrednim priorytetem. Należy do niej dążyć, za wszelką cenę. Szkoda, że większość programistów o tym zapomina.
Tylko niestety, programy ciągle wymagają zmian - wprowadzanie tych zmian kosztuje. Im gorsza jakość kodu, tym te zmiany są droższe. W pewnym momencie mogą się zbliżać do wartości produktu. Więc łatwość i niski koszt zmian są pośrednim priorytetem. Szkoda, że większość biznesów z kolei o tym zapomina.
@Riddle: Moim zdaniem główny problem tworzenia oprogramowania jest taki że kodu nie widać a jedynie jego efekty. Gdybyśmy produkowali jakieś lodówki i biznes mógł zobaczyć że "dobra zrobili to szybciej i mamy to co chcieliśmy ale tutaj odstaje rurka a z tyłu cieknie woda" to myślę że w dużej części (bo nie wszędzie) zrodziłby się wnioski że aspekt techniczny jest równie ważny. Tymczasem większość biznesów nie obchodzi jak tylko kiedy coś dodacie. Dodatkowym czynnikiem wpływającym na koszt zmian jest długość życia oprogramowania, jeśli oprogramowanie żyje np. 5 lat to przez to 5 lat z początkowych założeń projektu mało co zostaje i często program tworzony do mieszania herbaty zmienił swoje początkowe zastosowanie i teraz miesza pomidorową z ryżem.
Masz program, z którego korzysta 1000 osób dziennie, i który zarabia 200tys. złotych miesięcznie.
Chcesz dodać w nim funkcjonalność linków polecających. Przychodzisz do programistów, i oni estymują wprowadzenie tego feature'a na miesiąc, ale ostatecznie zajmuje im 3 miesiące żeby go wprowadzić. Feature którego wprowadzenie powinno zając dzień, zajął 3 miesiące. Programiści pracujący nad tym muszą dostać wypłaty za te 3 miesiące wprowadzania tego. Jak myślisz, z czego wynika taka powolność we wprowadzeniu tej zmiany? No właśnie z niskiej jakości kodu. Dobry programista zaprojektuje odpowiednią architekturę i czysty kod, i przez to że zrobi taką "trzepaninę" jak to ująłeś, wytworzy system w którym dodanie systemu referali zajmie jeden dzień zamiast 3 miesiące.
Dbanie o jakość kodu i architekturę, bezpośrednio przekłada się na koszt zmian.
bagietMajster napisał(a):
@Riddle: Moim zdaniem główny problem tworzenia oprogramowania jest taki że kodu nie widać a jedynie jego efekty. Gdybyśmy produkowali jakieś lodówki i biznes mógł zobaczyć że "dobra zrobili to szybciej i mamy to co chcieliśmy ale tutaj odstaje rurka a z tyłu cieknie woda" to myślę że w dużej części (bo nie wszędzie) zrodziłby się wnioski że aspekt techniczny jest równie ważny. Tymczasem większość biznesów nie obchodzi jak tylko kiedy coś dodacie.
Programowanie nie jest tutaj odosobnione. Wiele branż ma podobne cechy - że klienta nie obchodzi jak, tylko kiedy. Designerzy, prawnicy, budowlańcy. Jak zamawiam firmę budowlaną, to nie obchodzi mnie jakich narzędzi użyją, tylko kiedy coś dostarczą - interesuje mnie efekt końcowy. Jak zamawiam taksówkę, to nie obchodzi mnie czy kierowca ma manuala czy automat, ważne czy się spóźnię na umówione miejsce. Jak idę do dentysty, to nie obchodzi mnie technika leczenia, tylko koszt i to czy będę zdrowy.
Różnica pomiędzy budowlańcami a programistami jest taka, że przy programowaniu bardzo łatwo jest zaciągnąć dług techniczny. Tzn. teraz dostarczyć coś w jeden dzień zamiast dwa, ale za to za jakiś czas feature który powinien zając 1 dzień zajmie 3 miesiące.
bagietMajster napisał(a):
Dodatkowym czynnikiem wpływającym na koszt zmian jest długość życia oprogramowania, jeśli oprogramowanie żyje np. 5 lat to przez to 5 lat z początkowych założeń projektu mało co zostaje i często program tworzony do mieszania herbaty zmienił swoje początkowe zastosowanie i teraz miesza pomidorową z ryżem.
To nie jest do końca prawda. Widziałem projekty które trwały po 10 lat i dłużej, i ich jakość była bardzo dobra. Wprowadzanie zmian było szybkie.
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.
Poza tym, gdyby tak było, i dało się rozwijać projekt przez kilka lat bez wzorców, z niską jakością, to wszystkie firmy by tak robiły - największe shitcode'y by przegoniły wszystkich ludzi, i pisanie bez architektury stałoby się normą; bo miałoby przewagę ekonomiczną we wprowadzaniu zmian do software'u.
Można ostrożnie stwierdzić, że jedynym sposobem na zapewnienie ciągłego niskiego kosztu zmian jest poprawna architektura i czysty kod.
Bezsens pisania kodu dla korporacji
Źle do tego pochodzisz. Tak samo jak ikona jest obrazem a mimo to nikt ikon nie maluje tylko je piszą.
Przestać pisać kod a zacznij go rysować. Wtedy nabierze to więcej sensu a i prawdopodobnie tobie zwiększą się zarobki. Sens to semantyka.
bagietMajster napisał(a):
dobra zrobili to szybciej i mamy to co chcieliśmy ale tutaj odstaje rurka a z tyłu cieknie woda
No ale właśnie to jest ta zasadnicza różnica, że w software tych rurek nie widać. Oglądasz te rurki tylko ty (tani) programista, a Pan (drogi) ma od tego sługusów (tanich programistów).
Dobry programista zaprojektuje odpowiednią architekturę i czysty kod, i przez to że zrobi taką "trzepaninę" jak to ująłeś, wytworzy system w którym dodanie systemu referali zajmie jeden dzień zamiast 3 miesiące.
Pominąłeś tutaj kluczową estymację, czyli ile zajęła ta "trzepanina". Jakie były perspektywy na rozwój tego projektu etc.
Wywalanie budżetu na coś co może nam się przydać, ale nie musi to przepalanie budżetu. Odsyłam zasada YAGNI.
Zupełnie inny temat to gdy nie zadbamy o odpowiednią architekturę wiedząc, że na pewno przyniesie nam to znaczne benefity w przyszłości.
Inna sprawa, to w którym momencie najczęściej pojawia się bałagan (i bugi) w kodzie? Gdy często są zmieniane założenia i wymagania biznesowe...
Już też o tym pisałem wcześniej, że pisanie czystego kodu zajmuje tyle samo czasu co pisanie g*wno kodu, kwestia umiejętności.
Inna sprawa to czy do kodu dorzucamy testy, dokumentacje etc.
Inna sprawa, to w którym momencie najczęściej pojawia się bałagan (i bugi) w kodzie? Gdy często są zmieniane założenia i wymagania biznesowe... lub jest duża rotacja na projekcie.
Mjuzik napisał(a):
Dobry programista zaprojektuje odpowiednią architekturę i czysty kod, i przez to że zrobi taką "trzepaninę" jak to ująłeś, wytworzy system w którym dodanie systemu referali zajmie jeden dzień zamiast 3 miesiące.
Pominąłeś tutaj kluczową estymację, czyli ile zajęła ta "trzepanina". Jakie były perspektywy na rozwój tego projektu etc.
Wywalanie budżetu na coś co może nam się przydać, ale nie musi to przepalanie budżetu. Odsyłam zasada YAGNI.
To prawda. Moja zasada kciuka jest taka że jeśli projekt trwa 2-3 tygodnie to zrobię "na szybko" (nie robiłbym onion, ale nadal wybrałbym tdd). Jeśli będzie trwał dłużej, to już go zrobię jak należy.
Pracuje tak w firmie od długiego czasu, i nie słyszałem żeby ktoś narzekał na performance.
Wiadomo też nie każdy umie zrobić dobry design. To nke jest tak że byle jaki junior stwierdzi "a to sobie walne dobrą architekturę", to że mu to wyjdzie.
Zupełnie inny temat to gdy nie zadbamy o odpowiednią architekturę wiedząc, że na pewno przyniesie nam to znaczne benefity w przyszłości.
Inna sprawa, to w którym momencie najczęściej pojawia się bałagan (i bugi) w kodzie? Gdy często są zmieniane założenia i wymagania biznesowe...
No tutaj się nie zgadzam. Bugi i bałagan pojawiają się stale - kwestiach jak bardzo to sprzątamy w miarę czasu. To że wymagania biznesowe się zmieniają to jest standard.
Już też o tym pisałem wcześniej, że pisanie czystego kodu zajmuje tyle samo czasu co pisanie g*wno kodu, kwestia umiejętności.
Inna sprawa to czy do kodu dorzucamy testy, dokumentacje etc.
True.
Rexioo napisał(a):
Brakuje bardzo takich ludzi.
To się nazywa "senior" taki ludź (mówię o prawdziwym seniorze, a nie takim z nazwy). Tylko on jest drogi i trudno go znaleźć.
snakeomeister napisał(a):
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.
Opisałeś jak działa świat w każdej dziedzinie
nie żebyś był pionierem, bo np. Ronald Regan tez o tym mówił
tylko w odniesieniu do rządu
że są ludzie znający się na robocie - oni nigdy nie awansują
i są ludzie dobrzy w różnych takich gierkach, ale na robocie się się buca znają, ale to właśnie oni zazwyczaj są przełożonymi tych pierwszych
programowanie to mały pikuś
lepsze jaja są w tzw gałęziach strategicznych, gdzie sa ludzie z nadania którzy nic o branży nie wiedzą (np eneretyka) ale zarządzają
nie chcesz nie pracuj
ale świata raczej nie zmienisz
Mjuzik napisał(a):
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.
no dobrze, ale to podejście skutkuje później tym, że (a) bez przerwy pojawiają się kolejne bugi (b) zaimplementowanie nowej funkcjonalności zajmuje 10x tyle czasu, ile powinno.
jak się ugrzęźnie w beznajdziejnym kodzie, to potem ciężko z nim dalej pracować.
zaczynam być na tym etapie, że zdaje mi się, że gdyby jednak zadbać o jakość kodu, to nawet dla biznesu się to zwróci mniejszą awaryjnością produktu i większą możliwością poszerzania go o nowe funkcje, a tego przecież biznes chce?
snakeomeister napisał(a):
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.
z tym się głęboko nie zgadzam, o funkcjonalności decyduje zawsze biznes i tylko biznes, z przyczyn dość oczywistych.
marian pazdzioch napisał(a):
Rexioo napisał(a):
Brakuje bardzo takich ludzi.
To się nazywa "senior" taki ludź (mówię o prawdziwym seniorze, a nie takim z nazwy). Tylko on jest drogi i trudno go znaleźć.
I dlatego są firmy, które stoją juniorami. I nawet dowożą produkty, które mają dużą wartość biznesową. Tylko potem skutek jest taki, że kod jest beznadziejny, wszystko muli, wywala ciągle komunikaty błędów, praca z kodem jest upierdliwa i nieznośna.
Jest to zrozumiałe. W juniorach można przebierać i mało im płacić - nawet, jeśli wskutek tego do rozwoju produktu trzeba 10x więcej ludzi, niż gdyby siedzieli nad nim sami specjaliści, a tym juniorom wszystko i tak zajmuje 10x więcej czasu, niż powinno - i tak się opłaca.
Produkt muli i wali błędami? Co z tego, skoro kluczowe funkcjonalności są dowiezione. Klient może i jest zirytowany, ale produkt kupuje, bo czego potrzebował, ma. (Tak działa np. Visual Studio; wszyscy się wściekają, ale i tak korzystają).
Ale... Może jednak można inaczej? Połączyć jedno z drugim?
Zatrudnić jednego seniora, ale takiego prawdziwego, nie tylko z nazwy. Zapłacić mu ciężkie pieniądze. Pozwolić mu decydować o wszystkim, co jest związane bezpośrednio z kodem. Reszta programistów to niech będą juniorzy albo podszkoleni juniorzy (w sensie tacy, co zostali zatrudnieni w tym korpo dawno temu jako juniorzy i dalej tu pracują, wskutek czego doskonale znają produkt, ale z kolei nie mają obycia z obecnie stosowanymi najlepszymi praktykami i nie mają porównania, bo nigdy nie widzieli kodu innego, niż ten pisany w tym właśnie korpo).
Niech ten senior zarządza resztą zespołu, decyduje o architekturze, uczy ludzi dobrych praktyk, wymaga, by pisany kod był przynajmniej znośnej jakości. Kod niech pisze reszta zespołu. Może to przynajmniej pozwoli uniknąć najgorszych tragedii i piekiełek, jakich w innym wypadku jest pełno.
Nie wiem, to jest czyste zgadywanie z mojej strony. Czy taki układ miałby jakikolwiek sens? Jest gdzieś stosowany z sukcesem?
Zatrudnić jednego seniora, ale takiego prawdziwego, nie tylko z nazwy. Zapłacić mu ciężkie pieniądze. Pozwolić mu decydować o wszystkim, co jest związane bezpośrednio z kodem. Reszta programistów to niech będą juniorzy albo podszkoleni juniorzy (w sensie tacy, co zostali zatrudnieni w tym korpo dawno temu jako juniorzy i dalej tu pracują, wskutek czego doskonale znają produkt, ale z kolei nie mają obycia z obecnie stosowanymi najlepszymi praktykami i nie mają porównania, bo nigdy nie widzieli kodu innego, niż ten pisany w tym właśnie korpo).
Tutaj gość opowiada o tym podejściu i w skrócie ma to sens dopóki juniorzy zostają na dłużej niż rok i cały ten czasokoszt poświęcony im przez seniora aby przekazać wiedzę techniczno-biznesową ma szansę się zwrócić.
YetAnohterone napisał(a):
zaczynam być na tym etapie, że zdaje mi się, że gdyby jednak zadbać o jakość kodu, to nawet dla biznesu się to zwróci mniejszą awaryjnością produktu i większą możliwością poszerzania go o nowe funkcje, a tego przecież biznes chce?
Problem w tym, że ten tzw. biznes nie jest w stanie rozróżnić dbania o jakość kodu od niedbania połączonego z gadaniem, że się dba. Taki skutek zarządzania ludźmi mającymi pojęcie o rzeczywistym wytwarzaniu produktów, przez ludzi którzy tego pojęcia nie mają.
Zatrudnić jednego seniora, ale takiego prawdziwego, nie tylko z nazwy. Zapłacić mu ciężkie pieniądze. Pozwolić mu decydować o wszystkim, co jest związane bezpośrednio z kodem.
Obawiam się, że w obecnym systemie (rządy menadżerów), częściej będzie się to kończyło zatrudnieniem ściemniacza, który będzie opowiadał jak to niby perfekcyjnie pracę wykonuje, a rzadziej kogoś kto w rzeczywistości to robi. Zapłacenie ciężkich pieniędzy gwarantuje przyciągnięcie zachłannych na pieniądze, natomiast nie gwarantuje, że z grupy zachłannych na pieniądze oraz bardzo dobrych specjalistów, zostanie wybrany specjalista a nie ściemniacz.
jeżeli inżynier nie potrafi wysłowić się co robił to nie chciałbym go mieć w swoim zespole. ale jeżeli potrafi się wysłowić, ale nie potrafi porgramować wtedy już tak? Dlaczego wszyscy zakładają, że jak ktoś jest dobry w algorytmy to automatycznie nie potrafi się wysłowić? Wydaje mi się, że żeby zrozumieć algorytmy wymagana jest inteligencja na pewnym poziomie, która raczej nie wiąże się z problemami z wysławianiem się.
Ale nie udowodni czy umie rozmawiać wysokopoziomowo o problemach bez schodzenia w szczegóły implementacyjne ok a prowadząc rozmowę w ten sposób nie odkryjemy czy umiejętność wysokopoziomowej rozmowy o problemach nie jest jedyną rzeczą, którą potrafi.
miiiilosz napisał(a):
Po pierwsze musiałbyś biznesowi pokazać czarno na białym ile będzie ich kosztował dług techniczny.
Wiem, że zwykle nie działa to w ten sposób, ale to raczej biznes musi pokazać wyliczenia oszczędności wynikających z niespłacania długu. Dług techniczny jest zjawiskiem opisanym i zbadanym, nie trzeba udowadniać, że istnieje. Różne raporty wskazują na koszty rzędu 20% - 40%, np.:
Technical Debt tracking: Current state of practice: A survey and multiple case study in 15 large organizations
The Developer Coefficient
Tech debt: Reclaiming tech equity
Poza tym, komu konkretnie trzeba to pokazać? Kto to jest ten "biznes"? W korporacjach osoby decyzyjne, z którymi programiści mają kontakt na codzień, nie reprezentują "biznesu". Reprezentują przede wszystkim swój portfel i swoje ego. W innych rodzajach firm może być lepiej albo i nie. Generalnie na całej ścieżce, od prezesa do juniora, powinna być jakaś świadomość kosztów olewania jakości. Wystarczy przerwa w jednym miejscu i już jest problem, dlatego mamy więcej badziewia niż ładnych rzeczy.
Mjuzik napisał(a):
Pominąłeś tutaj kluczową estymację, czyli ile zajęła ta "trzepanina". Jakie były perspektywy na rozwój tego projektu etc.
Rzetelna ocena perspektyw jest bardzo trudna, powiedziałbym nawet, że niemożliwa z wyjątkiem szczególnych przypadków.
Z jednej strony, z powodu zmian na rynku program może zmienić zastosowanie, odkryć niszę itp. Wówczas perspektywa zmienia się w sposób niemożliwy do przewidzenia. Np. programik, który miał być jednorazową pomocą dla jednego klienta, zmienia się w podstawę nowego obszaru działalności.
Z drugiej strony, manager może łatwo podważyć każdą perspektywę, jeśli nie będzie pasowała do jego prywatnych celów, czytaj "mam wywalone, jak ten projekt będzie wyglądał za 3 lata, bo wtedy będę na innym szczeblu albo w innej firmie".
Odsyłam zasada YAGNI.
Tylko kto jest tą literką Y? Manager 10 lat temu? Czy programista utrzymujący 10-letnie legacy?
Zupełnie inny temat to gdy nie zadbamy o odpowiednią architekturę wiedząc, że na pewno przyniesie nam to znaczne benefity w przyszłości.
Ten warunek jest nie do spełnienia. Pewności nigdy nie ma. Poza tym (przy złej woli) można dowolnie redefiniować pojęcie "znaczne benefity": zysk zwiększył się o 7%? a to pech, bo w tym kwartale ustaliliśmy, że "znaczne" zaczynają się od 8.
Jak dla mnie kwestia konieczności spłacania długu technicznego jest oczywista i nikomu nie będę udowadniał, że nie jestem wielbłądem.
Dlatego, opierając się na danych z powyższych raportów, staram się zawsze przepchać jawną i stałą regułę "+20% czasu na małe refaktoringi". Z mojego doświadczenia wynika, że wystarcza to na tyle, żeby przynajmniej nie robić gorszego bajzlu, niż już jest.
Jeśli nie ma zgody managementu na taką regułę, ale jest wsparcie zespołu, to przepychamy refaktoringi po cichu. Dajemy większe wyceny nie chwaląc się tym, że nadwyżka idzie na walkę z szambem.
Jak się komuś się nie podoba, to niech mie zwolnią :P
Pracowałem w kilku firmach i potwierdzam, jeśli sami programiści nie wezmą spraw w swoje ręce i nie zaczną refaktorowac rzeczy jako codzienna rutyna to nie ma opcji by jakość się polepszyła. Biznes nie zapłaci za coś dwa razy a z ich perspektywy tak to wygląda bo przecież ta funkcjonalność już jest. Szkoda, że taki sobie los zgotowaliśmy, ale to już temat na inny wątek.
itsme napisał(a):
Pracowałem w kilku firmach i potwierdzam, jeśli sami programiści nie wezmą spraw w swoje ręce i nie zaczną refaktorowac rzeczy jako codzienna rutyna to nie ma opcji by jakość się polepszyła. Biznes nie zapłaci za coś dwa razy a z ich perspektywy tak to wygląda bo przecież ta funkcjonalność już jest. Szkoda, że taki sobie los zgotowaliśmy, ale to już temat na inny wątek.
:|
No ameryki nie odkryłeś. To jest standard przecież. Jasne, że to programiści i tylko programiści powinni dbać o jakość.
Tak dla ludzi twierdzących, że jakość kodu nie ma żadnego znaczenia.
Pamiętam taką sytuację, że dla software house'u bardzo ważny kontrakt wisiał na włosku, bo klient był zniesmaczony niestabilnością i awaryjnością produktu. Teoretycznie najważniejsza funkcjonalność biznesowa została zaimplementowana, ale co z tego, skoro aplikacja nagminnie waliła błędami, wieszała się, a nawet, jeśli błąd rzeczywiście wynikał z winy użytkownika, to komunikat o błędzie nie tłumaczył dobrze, co się stało, dlatego użytkownika szlag trafiał, bo z jego perspektywy "aplikacja nie działa" nawet, jeśli to on coś źle robi.
Jak to się skończyło, czy w końcu dostali kontrakt, czy nie, tego nie wiem. Ale sam fakt, że b. ważny kontrakt naprawdę wisiał na włosku z powodu problemów, których źródło ewidentnie leżało w niskiej jakości kodu, powinno dawać do myślenia.
YetAnohterone napisał(a):
Tak dla ludzi twierdzących, że jakość kodu nie ma żadnego znaczenia.
Pamiętam taką sytuację, że dla software house'u bardzo ważny kontrakt wisiał na włosku, bo klient był zniesmaczony niestabilnością i awaryjnością produktu. Teoretycznie najważniejsza funkcjonalność biznesowa została zaimplementowana, ale co z tego, skoro aplikacja nagminnie waliła błędami, wieszała się, a nawet, jeśli błąd rzeczywiście wynikał z winy użytkownika, to komunikat o błędzie nie tłumaczył dobrze, co się stało, dlatego użytkownika szlag trafiał, bo z jego perspektywy "aplikacja nie działa" nawet, jeśli to on coś źle robi.
Jak to się skończyło, czy w końcu dostali kontrakt, czy nie, tego nie wiem. Ale sam fakt, że b. ważny kontrakt naprawdę wisiał na włosku z powodu problemów, których źródło ewidentnie leżało w niskiej jakości kodu, powinno dawać do myślenia.
No to produkt nie działa, proste. Tu jest mowa o sytuacji kiedy produkt spełnia swoje wymagania bezawaryjnie, ale kod to dziadostwo.
Ale nikt nie twierdzi, że jakość jest bez znaczenia. Owszem, ma ogromne znaczenie, jednak w wielu sytuacjach biznes zwyczajnie to ignoruję. Jeśli coś może zająć 1 dzień i być rozwiązaniem brzydkim, mało optymalnym itp itd vs coś co zajmie 5 dni a będzie optymalne i łatwo rozszerzalne to w wielu przypadkach biznes wybierze to pierwsze. Często jest to uargumentowane faktem, że potrzebujemy coś na teraz i z czasem to przebudujemy. Oczywiście na 90% nikt tego później nie przebuduje i worek z długiem technicznym się powiększa.
Z tego co zauważyłem, podejście drugie, czyli jakość > prędkość, jest często praktykowane w firmach produktowych. Natomiast pierwsze w typowych korpo-kontraktorniach.
Czitels napisał(a):
No to produkt nie działa, proste. Tu jest mowa o sytuacji kiedy produkt spełnia swoje wymagania bezawaryjnie, ale kod to dziadostwo.
Czy dawne Windowsy działały? I tak, i nie. Z jednej strony funkcjonalność biznesowa była dowieziona, ludzie masowo z nich korzystali. Z drugiej strony komputer co chwila walił błędami, zawieszał się, restartował się, ciągle znajdowano nowe dziury bezpieczeństwa.
Czy Visual Studio działa? Znowu, i tak, i nie. Z jednej strony funkcjonalność biznesowa jest dowieziona: deweloperzy masowo korzystają z Visual Studio. Z drugiej strony Visual Studio co chwila wali błędami, miewa problemy z podstawową funkcjonalnością, zdarza mu się zawieszać, itp. Patrz np. https://4programmers.net/Mikroblogi/visualstudiohate
Czy działa, to nie jest zerojedynkowe. Pomiędzy "działa" a "nie działa" jest właśnie to: niby działa, ale niestabilnie i awaryjnie.
Do takiej sytuacji, w mojej opinni, prowadzi właśnie niedbanie o jakość kodu i nacisk tylko na funkcjonalność biznesową. Niby działa! Niby funkcjonalność biznesowa jest dowieziona! Przy odrobinie samozaparcia można nawet korzystać! Tyle, że użytkownik co jakiś czas rzuca nieprzyzwoitymi wiązankami, kiedy pojawia mu się kolejny błąd, a obchodzenie niektórych problemów z funkcjonalnością zaczyna być sztuką samą w sobie.
Nie za bardzo można mieć szybkość bez jakości (bo ciężko dodać coś do śmietnika), ale równie ciężko jest mieć jakość bez szykość - nie jesteś w stanie dodać poprawek do kodu, jeśli jesteś wolny (bo musisz robić feature'y i nie ma czasu na poprawki).
Więc to nie jest trade-off quality vs. speed.
Przykład:
Albo masz zarówno prędkość+jakość, albo nie masz nic.