Czy nie ma czasu na utrzymywanie dobrego kodu?

ehhhhh napisał(a):

@jarekr000000: ja pracuje dość blisko biznesu, na 80% wycen dostaje info "czemu tyle czasu? takiego budżetu nie mamy".

I co wtedy się dzieje?

@ehhhhh: Oczywiście, ze nie wiem "jakie będą zmiany" w tym logowaniu, ale to nie jest powód, żeby po usłyszeniu "Z tego będzie korzystał Ziutek, jego kot nazywa się Mruczek i chce dodawać 2 do 2" napisać coś na kształt (pomijam tutaj TDD):

int addingEndpoint(String password, String user, int a, int b){
  if(user.equals("ziutek") && password.equals("mruczek")){
    return 4;
  } else {
    throw 403;
  }
}

Skoro można sobie zrobić w 5-10 minut:

public record UserCredential(String user, String password){}

do tego

public boolean validateUserRights(UserCredential credential){}

Dlaczego w ten sposób? Bo jako istoty inteligentne, wiemy, że ten kod z samej góry trzeba będzie zmienić. Nie wiadomo jak, ale że trzeba będzie coś poprawić wiadomo. Chyba, że ktoś jest jeszcze juniorem w swoim pierwszym projekcie, to może dać się nabrać na "jeszcze tylko to zmienimy i koniec".

I dla jasności, nie piszę o:

• dodawaniu interface'ów do DTO'sów

• stosowaniu na siłę wzorców projektowych do zadań, gdzie one są niepotrzebne

• wprowadzaniu hierarchii dziedziczenia na 20 poziomów

• wielogodzinnych dyskusjach, czy wg. Wujka Boba coś powinno się nazywać X, czy Y

• innych fetyszystycznych podejściach do własnego kodu

  Serio, jestem wielkim zwolennikiem podejścia "get the shit done", tylko z mojego doświadczenia, rzekome oszczędności rzędu minut, może godzin, przekładają się w moment na straty liczone w tygodniach, lub miesiącach. To o czym piszę to akcje typu:

• publiczne pola statyczne w klasach "bo trzeba tylko przekazać jakąś wartość z warstwy A, do warstwy Ż" i "tak będzie najszybciej"

• oszczędności na liczbie kolumn w bazie, bo co szkodzi zamiast mieć imię i nazwisko, skoro można mieć jedną kolumnę "Imię, Nazwisko"

• nadawaniu id'kom z bazy danych wartości biznesowej (przez ~2 miesiące to poprawiałem na "produkcyjnym systemie, bo z jednoliterowego kodu miał się zrobić 2 literowy kod...)

-- edit
Tak, pisanie zwięzłego kodu jest ważne. Tylko "żeby go "zaorać i zmienić" on musi być sensownie podzielony, żeby zakres tego "orania i zmieniania" nie rozlazł się na cały system...

jarekr000000 napisał(a):

ehhhhh napisał(a):

@jarekr000000: ja pracuje dość blisko biznesu, na 80% wycen dostaje info "czemu tyle czasu? takiego budżetu nie mamy".

I co wtedy się dzieje?

Obcinanie architektury i mniejsza ilość testów byle dostarczyć produkt klientowi.

@piotrpo: widzisz a ja bym nic nie wydzielał bo nie wiem czy kiedykolwiek będzie ten kod zmieniany, a wydzielenie tego kodu do osobnej klasy będzie wliczone w wycenę w momencie kiedy będzie trzeba to wydzielić czyli kiedy pojawi się potrzeba rozbudowy tych kilku linii. 10min tu 10 minut tam i z estymowanych 200h robi się 300 a za nadmiarowe 100 klient nie zapłaci bo na umowie jest 200.

katakrowa napisał(a):

Jeśli jednak miałbym wskazać coś co ma potwierdzony wpływ na łatwość rozwoju systemu, nawet po wielu latach, to będzie to jego architektura.
Nie sam kod a odgórna idea narzucająca reguły i ramy, w których będą poruszać się programiści tworzący poszczególne moduły systemu.

No wg mnie niedbały kod będzie również miał słaba architekturę i odwrotnie - dobra architektura będzie się wyrażać w czystym kodzie.

Chociaż owszem, można to odróżnić i to mnie wkurza akurat, że dużo ludzi myśli bardzo przyziemnie i „czysty kod” wg nich to jest tylko formatowanie i odpowiednia liczba spacji w odpowiednich miejscach. Nie mówię, że formatowanie nie jest ważne, tylko że jednak mówiąc na poważnie o czystym kodzie jednak trzeba brać pod uwagę również architekturę i ogólne zasady programistyczne.

Niestety często spotykam się z kodem, który jest estetyczny (ładnie sformatowany, elegancko wyglądający, sprawiający wrażenie mądrego, mający wiele różnych klas, które mądrze brzmią), ale w rzeczywistości koszmarna i nieprzemyślana architektura i coś, co ciężko utrzymywać. Cóż… nie o to chodziło w idei czystego kodu.

a kto ocenia czy kod jest dobry
-gostek który przeczytał jedną książkę albo jeden artykuł i chce wprowadzać podane tam rozwiązania NIE ROZUMIEJĄC ICH
-programista który czytając tę samą książkę o chwilę mówi "no, tak robię, nie wiedziałem że to ma nazwę" albo "kurcze szkoda że tego nie znałem pisząc xy"
ktoś tu powyżej podał przykład ze cały kod nawalony w main versus hierarchia klas, pytanie dlaczego nie kod proceduralny? Bo jak nie robimy według najnowszych wzorów to już nie musimy się w ogóle starać pisać porządnie

@LukeJL: formatowanie mozna wymusic automatycznie.

IMHO jesli pracujemy w zdrowej firmie, pomijajac przypadki gdzie mamy ekstremalne cisnienie i ludzie dopychaja kolanem przed demo, albo cos trzeba zalatac bo "wybuchlo na produkcji" i pewnei jeszcze kilka skrajnych przypadkow, ludzie przewaznie robia najlepszy kod jaki potrafia i nawet gdyby mieli na taska 2x wiecej czasu nie byloby to lepiej zrobione (moze ew. jakas kosmetyka. Zreszta polecam eksperyment na review jak cos jest slabo zrobione, zapytac:

• czemu zrobiles to akurat w taki sposob?
• bo nie mialem czasu
• a jakbys to zrobil gdybys mial kilka dodatkowych dni na to?
• yyyyyyy....

piotrpo napisał(a):

• oszczędności na liczbie kolumn w bazie, bo co szkodzi zamiast mieć imię i nazwisko, skoro można mieć jedną kolumnę "Imię, Nazwisko"

To nie widziałeś jednego pola "adres"

Po co skupiacie się na oczywistościach, każdy z nas ma kilka/kilkanaście lat doświadczenia a piszecie o jakimś formatowaniu kodu, które i tak w każdym projekcie jest wymuszone automatycznie.
Tak samo piszecie o jakichś projektach w software house gdzie takie projekty nie mają nawet 100 000 linii kodu.

Waszym zdaniem co może zrobić programista wchodząc do projektu powiedzmy 1 000 000 linii kodu (wiadome, że to nie wyznacznik ale coś może powiedzieć) i wszystko jest w jednym module a pliki mają po 20 000 linii kodu?

@anonimowy: W takim projekcie, programista niewiele jest w stanie zrobić, bo jakąś zmianę mógłby zrobić rok pracy zespołu. Tylko ten 1e6 linii spaghetti nie powstał, bo ktoś się śpieszył, a ktoś inny klepnął review, bo szybka zmiana musi iść na produkcję.

Tak zgadza się ale jesteś mimo wszystko w stanie dostarczać dobry refaktor małymi krokami tylko te małe kroki to nie 1-2h jak niektórzy tu uważają a np. 1-2 tygodnie a to też może pomóc. Tylko brak czasu w małych zespołach na to

W dużym skrócie kod projektów wygląda jak wygląda, bo jest rotacja i dopiero w pracy ludzie czegoś tam mogą się nauczyć. Ostatecznie priorytetem w pracy jest rozwiązanie właściwego problemu, a nie stylistyka czy przewidywane przyszłości. To trudne jeśli osoba nie ma wyczucia, nie zna potrzeb klienta (bo klient z innej branży), a w dodatku to nie 10 podobny system, lecz pierwszy i to z nowymi dodatkowymi technologiami.

Wtedy boję się osób, które próbują pisać na siłę "czysty kod". Czasem to jest tak, że nie widzę ich rozwiązania, a zamiast tego dostaję strzępy przez które trudniej jest ocenić poprawność rozwiązania.

PS, tak właściwie to najbardziej cenię to jeśli ktoś wpłynie na wymagania, uprości je bądź wyłączy z projektu. Moc nie pisania kodu jest największa, a zaraz za nią jest moc usuwania kodu.

Każdy cykl tworzenia programu komercyjnego jest taki sam. Tworzysz projekt jaknajszybciej, żeby sprzedać a dopiero potem jak jest kasa to go utrzymujesz i klniesz, że jakiś debil napisał g******y kod.
Tak to właśnie jest.

anonimowy napisał(a):

Waszym zdaniem co może zrobić programista wchodząc do projektu powiedzmy 1 000 000 linii kodu (wiadome, że to nie wyznacznik ale coś może powiedzieć) i wszystko jest w jednym module a pliki mają po 20 000 linii kodu?

Odejść z pracy i znaleźć inną? Ew. oddelegować robotę do iluś podwykonawców i niech każdy z nich będzie odpowiedzialny za inny kawałek kodu. To nie jest robota dla jednego człowieka ani nawet dla człowieka (w przyszłości będzie się tym zajmować AI…)

gajusz800 napisał(a):

Z punktu widzenia firmy to nie kod ma spełniać wymagania, tylko końcowy produkt ma spełniać wymagania. Rozumiane jako wymagania funkcjonalne. Czy w kodzie będą pomieszane warstwy czy nie albo czy są tam klasy po 500 linii, to menedżerów nie obchodzi. Tak długo, jak team będzie dowoził aplikacje które działają tak, jak miały działać, góry nie interesuje jakość kodu rozumiana jako jakieś arbitralnie przyjęte praktyki. Te są ustalane wewnątrz teamu przez team lidera, ale to sprawa drugorzędna tak naprawdę. Jakość kodu nie stanowi tu żadnego decydującego kryterium. Lepsza jakość kodu może przekładać się na to, że aplikacja działa lepiej, ale nie musi bo są też inne czynniki, które na to wpływają.

Możliwe że w przypadku prostych produktów o krótkim czasie życia (jakiś CRUD bez zaawansowanej logiki) faktycznie tak jest i jakość kodu jest tylko jakąś tam wewnętrzną sprawą.
Jednak w projektach systemowych, w których brałem udział (nie tylko Cassandra, ale wszelkie projekty poboczne, w tym niepubliczne komponenty infrastrukturalne działające w chmurze) dostrzegam bardzo silną korelację między dbałością o dobry stan kodu a:

• stabilnością finalnego produktu (kod słabej jakości => dużo defektów, notorycznie sypiące się testy, dziwne "wypadki" na produkcji)
• szybkością poprawiania błędów (kod słabej jakości => długi czas szukania błędu, programiści nie potrafiący określić co się dzieje w projekcie)
• szybkością wdrażania nowych ludzi (kod słabej jakości => nikt nic nie rozumie poza jednym gostkiem, który go napisał i akurat jest na urlopie zdrowotnym; ale jak wróci to i tak nic to nie da bo gość nie umie tłumaczyć i jest tzw. chodzącym chaosem)
• łatwością wprowadzania zmian (kod trudno zrozumieć i ma potencjalnie dużo defektów => strach przed zmienianiem czegokolwiek bo wybuchnie)
• łatwością dopisywania nowych rzeczy (powód jak w punkcie wyżej)

Właściwie to może nawet nie jest korelacja, a wręcz definicja dobrego kodu. Dobry kod to właśnie taki kod, który ma mało defektów, jest łatwy do zrozumienia i wręcz nudny i łatwo do niego dodać nowe rzeczy lub coś zmienić nawet przez osoby które nie pisały owego kodu. Jak ma te cechy, to nie ma znaczenia czy programiści używali metodyki TDD, Clean code, XP czy może Programming Motherfucker, to jest to dobry kod.

Pytanie jak tego dokonać?

Można przeczytać tony książek o wzorcach projektowych i clean code i to pewnie ma jakąś tam wartość, niemniej na własne potrzeby stosuję kilka heurystyk, które zwykle dość dobrze działają w dużych projektach:

1. nie zgaduję w jaki sposób mój kod będzie zmieniony, bo wiem że prawie zawsze zgadnę źle - dlatego nie robię interfejsów / extension pointów" na zapas
2. nie zakładam jak mój kod będzie użyty - dlatego nie idę na skróty przy obsłudze przypadków brzegowych a do tego bardzo skrupulatnie ogradzam kod asercjami (a gdzie się nie da dokumentacją), tak że jak ktoś go źle użyje to sie wywali w przewidywalny i łatwy do analizy sposób
3. staram się ograniczać liczbę zależności i kontekstu który trzeba znać aby zrozumieć kod
4. staram się ograniczać funkcjonalność - niech robi mało a dobrze
5. paradoksalnie dość często korzystam z abstrakcji, ale robię je tak, aby abstrakcja była osobnym bytem dającym się zrozumieć niezależnie od reszty projektu - i dzięki której jest potem MNIEJ kodu do analizy; bo np. cała skomplikowana rzecz jest schowana w jendym miejscu i nie wylewa się na resztę projektu
6. duży nacisk kładę na sprawy takie jak: logowanie, metryki, obsługa błędów, testy będące równocześnie dokumentacją
7. dużo komentuję, szczególnie wyjaśniając po co dany kod jest a nie tylko co robi

Jjest pewnie tuzin innych rzeczy, ale na razie lecę na lunch.

@Krolik: ale to zawsze będzie kwestia sporna, jedna osoba może twierdzić, że kod jest dobry, a inna może być odwrotnego zdania. No i właśnie po to powstało mnóstwo mądrych teorii, metodyk i książek, które próbują to usystematyzować.

Możemy przyjąć, że senior będzie tworzył dobry kod nawet jeśli nie używa żadnej znanej metodyki oprócz swojej własnej. Ale może to być kod zrozumiały tylko dla niego, a inni będą mieć problemy z jego zrozumieniem.

gajusz800 napisał(a):

Możemy przyjąć, że senior będzie tworzył dobry kod nawet jeśli nie używa żadnej znanej metodyki oprócz swojej własnej. Ale może to być kod zrozumiały tylko dla niego, a inni będą mieć problemy z jego zrozumieniem.

Zauważyłem, że czasem gorszy kod może być lepszy, jeśli zapewnia standaryzację. Tak jakby w pełni fajny i efektywny kod można było osiągnąć w 1 osobowych projektach, a w wieloosobowych lepiej mieć gorszy i mniej efektywny kod, ale taki standardowy, bez niespodzianek, w który da się wejść szybko.

Stąd popularność frameworków, które narzucają architekturę i sposób pisania kodu. Stąd też popularność wzorców pisania, które są dość niewygodne czasem, ale jednak na tyle rozpowszechnione, że stają się lingua franca dla różnych programistów.

Trochę taki najmniejszy wspólny mianownik, coś co wszyscy znają i umieją stosować. Tak jak na weselu "Jesteś Szalona" będzie lepszym wyborem niż jakaś bardziej ambitna piosenka, którą mało kto zna.

gajusz800 napisał(a):

Ale może to być kod zrozumiały tylko dla niego, a inni będą mieć problemy z jego zrozumieniem.

Po to robi się CR i recenzent na CR powinien zgłosić, jak czegoś nie rozumie.

Potat0x napisał(a):

Dlaczego, w imię szybszego dowożenia, tworzony jest marnej jakości kod - skoro przecież wiadomo, że w przyszłości będą z tego problemy?

Na dłuższą metę firmom to się opłaca patrząc jedynie na rachunek zysków i strat? Czy może działa tu zasada "jakoś to będzie"?

Są różne modele biznesowe. Software House, banki i januszsofty chcą tanio i szybko, więc na kodzie im nie zależy, bo kod jest kosztem.
Firmom produktowym z kolei bardziej zależy na jakości wytwarzanego softu, bo kod dla nich jest źródłem dochodu.

ehhhhh napisał(a):

Zależy co masz na myśli. Bo cześć programistów mając na myśli "dobry kod" ma na myśli kod przeinżynierowany z 20 warstwami które nic nie znoszą teraz ale może za 50 lat coś wniosą, a jak nie to bedą chociaż mogli usiąść przed lustrem i powiedzieć "zrobiłem zajebisty kod" to nic że nie ma on sensu i nigdy mieć nie będzie.

Kod przeinżynierowany, to nigdy nie jest dobry kod.
Dobry kod to taki, który się łatwo czyta, modyfikuje, i usuwa.

adamo51 napisał(a):

To chyba nie pracujesz w IT albo masz tyle szczęścia, że pracujesz w jakimś korpo gdzie się robi release raz na 3 lata.

Ja pracuję w IT, releasów mamy setki dziennie. I coś tak czuję, że gdybyśmy tworzyli kod marnej jakości, to byłoby to parę rzędów wielkości mniej.

somekind napisał(a):

Firmom produktowym z kolei bardziej zależy na jakości wytwarzanego softu, bo kod dla nich jest źródłem dochodu.

Kod nigdy nie jest źródłem dochodu a jedynie funkcjonalność stworzona w oparciu o ten kod.

Ale tak można się przerzucać w nieskończoność. Ktoś może powiedzieć, że to nie funkcjonalność jest źródłem dochodu, tylko "obietnica wartości" albo "marka".

Ale pomijając marketingowe sprawy, to na czysto technicznym poziomie mamy tu więcej rzeczy:

1. input: zmieniające się wymagania biznesowe
2. know-how i umiejętności programistów.
3. kod, czyli środek służacy do zrealizowania celu.
4. kontrola jakości (jakakolwiek), testy itp.
5. output: końcowy działający program

i wszędzie może coś nawalić:

1. Jeśli biznes ma chu*owe wymagania albo sposób zarządzania, to będą puszować chu*owiznę dalej i całość rozwiązania będzie słaba.

2. Jeśli programiści są słabi (albo nie mają know-how), to będą słabym ogniwem i nie przetłumaczą sprawnie wymagań biznesowych na kod.

3. Jeśli kod będzie słaby, to programiści może będą chcieli zrobić działający program, ale słaby kod zastany będzie ich powstrzymywać i spowalniać

4. Jeśli kontrola jakości zawiedzie, to pozornie ładny kod nie przełoży się na działający program, bo będą jakieś bugi, których nikt nie wyłapał

5. dalej ktoś powinien coś zrobić z działającym programem, więc jeśli deploy jest zje*any to też nie będzie dobrze.

Natomiast wiele firm:
2. zatrudnia słabych/przeciętnych programistów (bo lepsi są drodzy)
3. pozwala im pisać kiepski kod ("nie ma czasu" refaktorować, piszcie spaghetti)
4. nie dba dobrze o testowanie swoich rozwiązań (bo na testy "nie ma czasu". Ew. "od testów jest QA" - spotkałem się też z tym, że obecność zewnętrznego działu QA sprawiało, że programiści mieli wyje*ane, czy ich kod w ogóle działa...)

więc między punktem 1 a 5 mamy jeden wielki burdel.

Potat0x napisał(a):

Dlaczego, w imię szybszego dowożenia, tworzony jest marnej jakości kod - skoro przecież wiadomo, że w przyszłości będą z tego problemy?

Na dłuższą metę firmom to się opłaca patrząc jedynie na rachunek zysków i strat? Czy może działa tu zasada "jakoś to będzie"?

Mało programistów wie, że na deadline można się niezgodzić.

• Manager: "potrzebujemy paginację dla czterech widoków za 4 dni"
• Programista: (myśli...) "4 widoki... logika, front, testy, refactor, to będzię jakieś 7 dni"
• Programista: (na głos): będzie gotowe tak za 7-8 dni.
• Manager: "ale ja to potrzebuję za 4 dni".

I teraz uwaga.

• Co robi większość programistów: "dobra, to skipnę refactor i testy"
• Co powinna robić większość programistów: to trzeba było przyjść trzy dni temu, teraz to będzie za 7 dni.

dodatkowo może wyjść taka sytuacja:

• Manager: "ale ja to potrzebuję za 4 dni, TO JEST DEADLINE".
  • Dobry programista: "ale to po prostu nie będzie gotowe za 4 dni, będzie za 7 dni".
  • Zły programista: "dobra, to się zrobi" # i tutaj powstaje shitcode

ehhhhh napisał(a):

Kod nigdy nie jest źródłem dochodu a jedynie funkcjonalność stworzona w oparciu o ten kod.

Nie wiem, czego nie zrozumiałeś. Są firmy, w których software jest produktem. One bez softu nie zarabiają. Soft tworzy się pisząc kod.

Nie tak jak np. banki czy sklepy monopolowe, które mogą jakiegoś softu sobie używać, ale bez niego dalej będą prowadziły działalność, bo źródłem ich dochodu nie jest soft, który sobie tworzą.

Riddle napisał(a):

• Co robi większość programistów: "dobra, to skipnę refactor i testy"

Nie wiem, czy większość. Pewnie sporo zareagowałoby tak: powiem managerowi, że zrobię to w 4 dni dla świętego spokoju, mimo że wiem, że nie dam rady. No ale a 3 dnia powiem, że jednak trzeba kilka dni więcej i wyjdzie na moje, tylko że będę serwował prawdę powoli kawałkami. W końcu wszyscy wiedzą, że deadline'y lubią się przesuwać. Nie ma terminu, którego nie można byłoby nagiąć i powiedzieć, że dajcie nam jeszcze trochę czasu.

@Riddle @LukeJL Ja to wam zazdroszczę że wiecie że coś będzie trwać 7 dni i to trwa 7 dni. U mnie to albo przestrzelę estymatę dwukrotnie, albo niedoszacuje dwukrotnie XD

KamilAdam napisał(a):

@Riddle @LukeJL Ja to wam zazdroszczę że wiecie że coś będzie trwać 7 dni i to trwa 7 dni.

No wiadomka że nie wiem haha :D Nie wiem czy 7, 11 czy 13. Ale wiem że na pewno nie 4. I jeśli dostaję jakis deadline z góry, który wiem że jest niemożliwy (albo możliwy, ale musiałbym nie refaktorować i nie testować), to po prostu mówię że termin niewykonalny i podaję inny.

KamilAdam napisał(a):

U mnie to albo przestrzelę estymatę dwukrotnie, albo niedoszacuje dwukrotnie XD

Mam podobnie, ale ja się staram jednak w 90% "przestrzelić dwukrotnie". Wolę pierwszego dnia dostać konfrontacje i niezadowolenie PO, i potem dowieść szybciej niż się ustaliło, niż dostać piąteczkę od PO pierwszego dnia za dobry estimate a potem się spóżnić.

somekind napisał(a):

Nie wiem, czego nie zrozumiałeś. Są firmy, w których software jest produktem. One bez softu nie zarabiają. Soft tworzy się pisząc kod.

Nie tak jak np. banki czy sklepy monopolowe, które mogą jakiegoś softu sobie używać, ale bez niego dalej będą prowadziły działalność, bo źródłem ich dochodu nie jest soft, który sobie tworzą.

Ktoś płaci za kod dlatego, że robi coś konkretnego czego potrzebuje a nie dlatego, że ma fajne abstrakcje zrobione. Klienta nadal gunwo obchodzi jak to tam pod spodem jest zrobione.

@KamilAdam: @Riddle za mało robiliście w firmach gdzie trzeba dobrze wyceniać to nie potraficie :) Ja przy przy wycenach na 200h potrafię się machnąć max o 20h. A przy wycenach do 50h zawsze trafiam idealnie czyli z delikatnym zapasem.

ehhhhh napisał(a):

Ktoś płaci za kod dlatego, że robi coś konkretnego czego potrzebuje a nie dlatego, że ma fajne abstrakcje zrobione. Klienta nadal gunwo obchodzi jak to tam pod spodem jest zrobione.

W firmie produktowej nie ma żadnego klienta na kod. Firma sama używa tego kodu do ciągłego zarabiania na siebie. A skoro kod jest źródłem zysku, to trzeba o niego dbać.

Co Ty masz za manię z tymi abstrakcjami? Już któryś raz o nic wspominasz, nawet jeśli nikt o nich nie wspominał.

@KamilAdam: @Riddle za mało robiliście w firmach gdzie trzeba dobrze wyceniać to nie potraficie :) Ja przy przy wycenach na 200h potrafię się machnąć max o 20h. A przy wycenach do 50h zawsze trafiam idealnie czyli z delikatnym zapasem.

A może Ty za długo w takich miejscach pracowałeś, skoro nie możesz zrozumieć, że mogą istnieć firmy, którym zależy na jakości?

IMO to nie kwestia "czasu dowożenia". Kod pisze się słaby albo dobry. Tak samo testy - Sensowne otestowanie przynajmniej podstawowych funkcji kodu zajmuje chwilę.

Ludziom po prostu nie chce się starać, bo i tak za rok pójdą do innego projektu. Liderzy techniczni też wychodzą z założenia, że póki "jakoś" działa i pokrywa się z AC z jiry to jest dobrze. Niestety jest to domena projektów w dużych korpo - Miałem okazje doświadczyć i szybko z takich znikałem z powodu burdelu tam panującego (który był standardem).

Oczywiście powyższe jest skorelowane chociażby z tym co napisał @LukeJL czy @Riddle .

@ehhhhh: A co jeżeli jakieś zadanie w projekcie ma trwać 14 miesięcy pracy kilkuosobowego zespołu? Mi też udawało się wycenić np. aplikację mobilną na parę ekranów z całkiem dobrą dokładnością. Ale zdarzyło mi się też uwalać projekt wyceniony na 30 roboczogodzin (!), po kilku miesiącach pracy pytaniem "czy ktoś wie, co w tym, projekcie ma być zrobione, żeby móc go zamknąć?".

@piotrpo: przy projektach tak długich wyceniasz najbliższe sprinty/etapy i wtedy powinieneś być w stanie dokładnie wycenić.