Słaba jakość kodu w dużej firmie?

Hej.
Na początku roku przeszedłem do nowej firmy, ogromne korpo zatrudniające 400 ludzi z czego jakieś 150 programistów i jestem zszokowany bylejakością kodu.
Miał być Typescript, jest czysty Javascript. Zero testów. Nikt nie używa wzorców projektowych, większość projektów jest oparta o programowanie strukturalne, brak MVC. Są używane naprzemian polskie i angielskie nazwy zmiennych.

Szok. Większość programistów to seniorzy, jest nawet jakiś architekt który uj wie czym się zajmuje, bo raczej nie architekturą aplikacji. Rozmawiałem w zespole o tym, że nie do końca mi się podoba kod to mi odpowiedzieli, że takie mamy tutaj standardy. Nie rozumiem jak można siedzieć 5, 10 albo więcej lat w programowaniu i pisać takie g**no. Nigdy wcześniej tego nie doświadczyłem w innych firmach, zawsze dbało się o jakość kodu.

Jakie jest pytanie, w czym mogę pomóc?

Moim zdaniem, to jest efekt pracy pod presją czasu. Programista zrobi byle jak, byle uruchomić, myśląc, że później zrobi porządnie, zgodnie ze sztuką. Problem w tym, ze ta sama presja sprawia, że to "później" znaczy to samo, co "nigdy".

Gdyby programista pracował na spokojnie, bez presji, to ten sam programista zrobiłby tak, jak się robi, a nie byle uruchomić, napisał testy i tak dalej. To wszystko jest możliwe, tylko wymaga czasu.

Inną sprawą jest to, że w niektórych przypadkach, dorobienie jakiejś prostej funkcjonalności zgodnie z zasadami MVC, czy innego wzorca, zajmuje dużo więcej czasu niż byle jak, byle działało. Projekt wielokrotnie przerabiany wielokrotnie moze być zaśmiecony.

ogromne korpo zatrudniające 400 ludzi z czego jakieś 150 programistów

Firma zatrudniajaca 400 osób to ogromne korpo? W liczbie zatrudnionych osob to bliżej im do januszexów niz do korpo, nie mówiąc już nawet o ogromnym korpo.

No to już wiesz do jakiego zadania Cię zatrudnili i za co dostajesz swoją pensję. Za darmo tam chyba nie robisz. Pokaż innym jak się pisze czysty kod.

Nie miej pretensji do programistów tam pracujących! To nie ich wina, bo sam robiłem w tego typu środowisku na początku mojej kariery.
Zazwyczaj to się bierze stąd, że jest presja czasu, programiści zazwyczaj robią w Sprintach, gdzie zazwyczaj bierze się jakąś funkcjonalność na dany Sprint. Jeżeli pracujesz 8h dziennie, to nie ma szans byś się wyrobił i otestował wszystko, zrobił DDD, napisał testy jednostkowe, integracyjne, dodał dokumentację w README.md, zapoznał się z funkcjonalnościami biznesowymi, obgadał z biznesem wszystko + po drodze zazwyczaj jeszcze rozmawiasz z innymi ludźmi, masz pierdyliard zależności i na końcu hostujesz wszystko w nowym dla Ciebie cloudzie.

Sam pracowałem w firmie gdzie programiści pisali kod byle jak by zamknąć taska, wyobraź sobie że Seniorowi Java Developerowi dawali implementację przelewów między kontami i miał to zrobić w 2 tygodnie XD No to leci się po jakości kodu, byleby wyklepać coś jak najszybciej i zamknąć taska, a Manager z pupilkiem Scrum Masterem będą zadowoleni, bo zamknęli Sprint. Tylko to, że potem z tym taskiem się będą bujać na UATach 4-5 miesięcy to już kolejna sprawa.

To nie wina programistów, tylko firmy, zarządu w której się znajdują, po prostu jest taki model biznesowy.

kevin_sam_w_domu napisał(a):

Nie miej pretensji do programistów tam pracujących! To nie ich wina,

A czyja? Ktoś za nich napisał gówniany kod?
Może nie jest to wyłącznie ich wina, ale między innymi ich wina.

Wina jest tylko i wyłącznie programistów, tylko oni pracują nad kodem, kogo innego mogłaby być.

Wystarczy to porównać do innych dziedzin:

• Czy jeśli klient ubera powie kierowcy, żeby jechał całą drogę na czerwonych, czy zrobi to? Najpewnie nie.
• Czy jeśli pacjent powie dentyście, żeby nie dezynfekował narzędzi, czy zrobi to? Again, najpewniej nie.
• Czy jeśli płatnik powie księgowemu żeby ten nie robił kopii faktur, czy nie zrobi ich? Najpewnie się sprzeciwi.

Podobnie będzie w każdej innej dziedzinie. Ale teraz patrz.

• Czy jeśli PO powie programiście, żeby ten nie dbał o kod/refaktor/testy, czy on ich nie zrobi? Noi tutaj większość programistów posłusznie posłucha.

Wina leży w programistach, dlatego że myślą, że jeśli dla kogoś pracują, to ta osoba ma nad nimi władzę absolutną i jeśli PO powie "olać testy", albo "olać refaktor", albo cokolwiek innego, to większość posłusznie słucha; podczas gdy powinni się nie zgodzić.

Większość ludzi teraz powie "ale są deadline'y". Owszem. Ale czy gdybyś kierowcy taksówki powiedział "proszę jechać na czerwonym bo mam deadline" albo dentyście "proszę nie dezynfekować bo się spiesze", czy cokolwiek by to zmieniło? Oczywiście, że nie; i tak samo nie powinno u programistów.

Większość programistów ma w nawyku mówić: "jeśli zrobię by the book zajmie to 3 dni, jeśli oleję testy to dwa dni". Ale czy ktokolwiek zamawiając taksówkę słyszy od taksówkarza: "jeśli pojadę zgodnie z przepisami będę za 20 minut, a jak pojadę na czerwonym to będę za 10 minut"? Nawet by to nikomu do głowy nie przyszło; ale wśród programistów to normalka.

To jest główny powód syfu w każdym dużym projekcie.

Jw., raczej management ani PO nie zmusili ludzi, zeby nazywali zmienne po polsku. Moze ten system, to jest jakies legacy przejete po amatorach?

Widzę że co niektórzy tutaj nie trafili jeszcze na mocnych zawodników od strony biznesu i myślą, że programista zawsze ma wpływ.

Ja z jeden firmy się zwolniłem właśnie dlatego, że ostro wojowałem przy taskach, chciałem robić dobrze, z testami, dłużej niż sobie ubzdurali.
Nie zliczę godzin dyskusji na to zmarnowanych, ale to jak tłumaczyć koniowi, jak działa procesor...

Kończyło się to tak, że task zostawał przenoszony na kolejny sprint, albo wycinali 50% taska, żeby zrobić w ubzduranym okresie, a potem za jakiś czas siadał inny programista i dokładał kolejne 50% taska.

Ja mogłem albo to akceptować, albo się zwolnić... więc się zwolniłem.

Także z tym, że to zawsze wina programistów, to bym nie szalał, bo gdzieniegdzie z systemem nie wygrasz :)

urke napisał(a):

Widzę że co niektórzy tutaj nie trafili jeszcze na mocnych zawodników od strony biznesu i myślą, że programista zawsze ma wpływ.

Ja z jeden firmy się zwolniłem właśnie dlatego, że ostro wojowałem przy taskach, chciałem robić dobrze, z testami, dłużej niż sobie ubzdurali.
Nie zliczę godzin dyskusji na to zmarnowanych, ale to jak tłumaczyć koniowi, jak działa procesor...
[...]
Także z tym, że to zawsze wina programistów, to bym nie szalał, bo gdzieniegdzie z systemem nie wygrasz :)

Po prostu rób swoje. Dostajesz task na zrobienie rzeczy X, to robisz rzecz X, piszesz testy, refaktorujesz, oddajesz zrobione w całości. Kiedy ktoś pyta, jak idzie, mówisz że nie gotowe dopóki kod nie będzie w porządku i nie będzie otestowane. W momencie w którym napiszesz ostatni test, i jesteś zadowolony z jakości swojej pracy wtedy mówisz że skończone.

Nie ma sensu być wokalnym z tym i robić wojen (bo najpewniej skończy się na długich godzinach rozmów i shitów); po prostu robisz swoje.

Kończyło się to tak, że task zostawał przenoszony na kolejny sprint, albo wycinali 50% taska, żeby zrobić w ubzduranym okresie, a potem za jakiś czas siadał inny programista i dokładał kolejne 50% taska.

Ja mogłem albo to akceptować, albo się zwolnić... więc się zwolniłem.

No czyli co w tym złego w sumie? Jeśli wynikowo był refaktor, były testy i było zrobione dobrze, to chyba git.

OFFTOP
BEGIN

QUOTE
BEGIN
większość projektów jest oparta o programowanie strukturalne
END

Czyli ta lepsza mniejszość jest pisana w jakimś starym basicu, fortranie lub asmie? Druga możliwość jest taka, że w dwudziestym pierwszym wieku programiści nie wiedzą co to programowanie strukturalne.

END

Brzmi jak Januszsoft a nie korpo, w korpo to 5 ludzi przez tydzień myśli nad nazwą jednej zmiennej :)

mortadelek napisał(a):

Szok. Większość programistów to seniorzy,

Bo senior to tylko taka nazwa, nie musi to świadczyć o umiejętnościach. Ew. ten projekt był przejęty po jakichś juniorach. Chociaż tak naprawdę często "senior" to jest po prostu "junior z wieloma latami doświadczenia" (ktoś o małych skillach, ale z dużym stażem pracy).

Nie rozumiem jak można siedzieć 5, 10 albo więcej lat w programowaniu i pisać takie g**no

Może się na tym projekcie uczyli? Weszli jako juniorzy, napisali g**no, ale przepracowali 5-10 lat i już są seniorami, a ich kod, na którym się uczyli, dalej działa?

kevin_sam_w_domu napisał(a):

Nie miej pretensji do programistów tam pracujących! To nie ich wina, bo sam robiłem w tego typu środowisku na początku mojej kariery.

"na początku kariery". Myślę, że postawa osoby z doświadczeniem ("seniora") powinna być jednak nieco inna niż osoby, która dopiero wchodzi w branżę.

Sam pracowałem w firmie gdzie programiści pisali kod byle jak by zamknąć taska, wyobraź sobie że Seniorowi Java Developerowi dawali implementację przelewów między kontami i miał to zrobić w 2 tygodnie XD No to leci się po jakości kodu, byleby wyklepać coś jak najszybciej i zamknąć taska, a Manager z pupilkiem Scrum Masterem będą zadowoleni,

No to był to senior tylko z nazwy. Senior prawdziwie seniorski spełniający kryteria senioralności:

• powinien mieć na tyle silną pozycję na rynku pracy, żeby nie bać się postawić szefowi. Jak ktoś się boi Managera i Scrum Mastera, to znaczy, że jest juniorem (nie chodzi o skille, tylko że junior więcej ryzykuje stawiając się przełożonym, bo dla juniora samo znalezienie pracy to sukces, a senior może sobie złożyć wypowiedzenie z JanuszSoftu i znaleźć lepszą firmę). No ale tak jak @TomRiddle napisał Nie ma sensu być wokalnym z tym i robić wojen (bo najpewniej skończy się na długich godzinach rozmów i shitów); po prostu robisz swoje.
• powinien mieć w sobie minimum odpowiedzialności, a nie działać na zasadzie "wyklepać coś jak najszybciej".

Zgadzam się ze wszystkim co napisał @LukeJL wyżej, tylko dodam jedną rzecz.

Nie rozumiem jak można siedzieć 5, 10 albo więcej lat w programowaniu i pisać takie g**no

Gównie dlatego, że nie jesteś oceniany ani rozliczany przez innych programistów - jesteś oceniany i chwalony przez PO, Scrum Masterów, Managerów i innych niekompetentnych ludzi (w dziedzinie programowania). Wystarczy że nabijesz 50 story pointów co miesiąc robiąc największe g**no w kodzie i staniesz się super gwiazdą każdego korpo. Łatwo jest się wpasować w takim środowisku: nie musisz się uczyć, nie musisz nic poprawiać, nie musisz pisać testów ani refaktorować. Nabij 100% niezdrowego coverage (czyli testy które nigdy nie failują, nawet jak są bugi); dostań dużo approve'ów PR'ów mimo że nikt nie robi review; jak są bugi to przedstaw to jako plus QA'ów, że tak dużo bugów znajdują; i po co stres związany z poprawnym utrzymaniem projektu, skoro możesz siedzieć w swojej strefie komfortu. Nie musisz nigdy się uczyć o Clean Code, TDD, prawdziwym Agile (a nie tylko z nazwy), DDD, etc. Jeśli ktoś nie czyta książek, nie robi coding katas, coding dojos, nie rozwija się w innych bibliotekach i językach; to jak mógłby poszeżyć swoje kompetencje? Będzie dopisywał kolejne linijki do już nieutrzymywalnych projektów, jednocześnie będąc chwalonym za kolejny dobry sprint.

Natomiast kiedy na prawdę chcesz zrobić dobry kod, to na 99% jedyne uznanie jakie dostaniesz to jest swoje własne, po tym jak odwalisz kawał dobrej roboty; albo nieliczne firmy jeszcze mają drugiego takiego który to doceni; ale raczej nie. Ludzie w Twoim zespole i nad Tobą nie docenią że poprawiłeś testy, że usprawniłeś rozwiązanie, że sprawiłeś że jest bardziej usable, bardziej loosly-coupled, mniej podatne na bugi czy defekty. To jest jeszcze dodatkowo frustrujące, bo nawet jak usprawnisz jakiś moduł, tak żeby był dobry; to nie Tobie się zwróci inwestycja za ogarnięcie go; tylko przyjdzie ktoś inny, i korzystając z tego że kodzik już jest dobry znowu dostarczy szybko task, nabijając więcej punktów reputacji u swojego PO; najpewniej pogarszając produkt znowu.

Także możesz zostać w strefie komfortu i zostać takim "senior juniorem" (czyli junior ze sporym stażem), albo możesz się rozwijać nadal, ale walcząc z przeciwnościami.

Zapraszam do korpo z hindusami. Tutaj zobaczysz dopiero "jakość kodu" i poziom ludzi. Junior/mid tutaj to osoba, która nie wie jak dodać plik do gita, a senior co prawda wie, ale robi często typowe błędy juniorskie.
Ale za to każdy z nich potrafi ładnie pisac maile, klikać w Jire, ładnie mówić na daily o problemach, itd w taki sposób, że klient patrząc na to z boku ma wrażenie że pracuje z profesjonalistami.

Jaki kierownik budowy, taka budowa. Tak samo jest w IT, nie zwlałbym winy na programistów.

smieszekheheszek napisał(a):

Brzmi jak Januszsoft a nie korpo, w korpo to 5 ludzi przez tydzień myśli nad nazwą jednej zmiennej :)

No i wtedy masz czysty kod. Pomyśl, że przez te 5 dni mogliby nawalić kodu, który wypalałby oczy i mózg :-)

Duże korpo rządzi się swoimi prawami. Tam przede wszystkim jest ciśnienie na szybkie dostarczanie, bo klient się niecierpliwi i excele z KPI muszą się zgadzać. Można oczywiście na siłę forsować dobre praktyki tym samym spowalniając proces, ale trzeba liczyć się z łatką osoby, która dowozi wolno w porównaniu do programisty Zenka, która stworzył jakiś wysryw, ale za to szybko.

Był kiedyś taki kawał:

"Na rozmowie rekrutacyjnej rekruter pyta kandydata o jego umiejętność szybkiego liczenia, która podał w cv.

• rekruter: Proszę powiedzieć ile to 8923/4
• kandydat: 1760
• rekruter: To zła odpowiedź
• kandydat: Ale szybka :D"

Są dwa wyjścia. Albo się podporządkowujemy pod ten system, albo szukamy miejsca, gdzie na rzeczy jak refactor/testy/dobre praktyki zwraca się uwagę. Jeśli ktoś płaci (często nie mało) i chce taka a nie inną kolej rzeczy to droga wolna - business is business. Stąd nie oczerniałbym samych programistów a raczej cały system, który takie ramy narzuca.

@mortadelek: to jest Software House, prawda?

kiedyś dostałem się do najlepszej korpo w mieście - wtedy mój ówczesny pracodawca cieszył się wielka estymą i wielu tam chciało pracować, podejście było takie, ze jak tam się dostaniesz to będziesz robił z mega wymiataczami mega rzeczy

rzeczywistość

• owszem byli tam też i koledzy wybitni (cytowani nawet w książkach o danym języku programowania) ale większość to zwykłe chłopaki klepaki, ani dobre ani złe
• nikt nie dbał o techniczną stronę projektu tylko o biznesową - czyli coś miało być zrobione na dany termin, a jak, to już nie ważne, byle by klient wziął
• kod to była narośl na narośli naroślą poganiająca
• dużo było słów a mało czynów
• co nowa miotła to nowe zajebiste pomysły - z których niczego nie było
• gdzieś - na poziomie +/- dyrektora czuć było ścianę o którą wszystkie inicjatywy tzw techniczne się rozbijały

dużo się wtedy nauczyłem

• jest mało firm czysto technicznych, a sporo firm, które dla swoich celów wykorzystują i piszą soft
• w Polsce generalnie robisz to czego nie chcą robić koledzy z zagranicy
• praca to nie olimpiada czy nawet zaliczenie na studiach, nawet nie kurs doskonalenia zawodowego, gość od sprzedaży nie doceni, że użyłeś tego czy tamtego - jego to wali, on już twoją pracę sprzedał :)
• firma ma zarabiać kasę a gdzieś ma poczucie estetyki przez programistę - nawet jak na tym traci to i tak nie traci - bo naprawę buga czy ficzera można "sprzedać" a refaktor itd już nie
• tzw rozwój spowalnia dewelopment, chociażby to była inwestycja która zwróci się za rok czy dwa, to kto da głowę czy menago, VP czy inny na górze będzie za rok czy dwa na swoim stołku - on musi mieć sukces teraz, już
• często firmy kupują małe firmy, które coś klepnęły, żeby to sprzedać - potem duża firma "inwestuje" to znaczy każde dodawać nowe ficzery, a nie podbijać np wersję języka
• na nic nigdy nie ma czasu - zapieprz taki, że nie ma kiedy taczek załadować :)

Po prostu w życiu trzeba mieć trochę szczęścia - tyle co ja się nasłuchałem o innowacyjności, rozwoju, czego tam nie ma w projekcie
a potem okazywało się że TDD - oznacza że są testy jednostkowe :D

zresztą nigdy nie widziałem projektu który by się zaczął od napisania testów - ale jakie to testy ważne itp itd to management już nauczył się mówić :)

ref napisał(a):

• jest mało firm czysto technicznych, a sporo firm, które dla swoich celów wykorzystują i piszą soft

Noi bardzo dobrze; po to wszyscy robią soft.

• praca to nie olimpiada czy nawet zaliczenie na studiach, nawet nie kurs doskonalenia zawodowego, gość od sprzedaży nie doceni, że użyłeś tego czy tamtego - jego to wali, on już twoją pracę sprzedał :)

No i again bardzo dobrze. Ty robisz swoje a on swoje.

• firma ma zarabiać kasę a gdzieś ma poczucie estetyki przez programistę - nawet jak na tym traci to i tak nie traci - bo naprawę buga czy ficzera można "sprzedać" a refaktor itd już nie

Jeśli Tobie się wydaje że refaktor się robi po to żeby zaspokoić poczucie estetyki to jesteś częścią problemu.

Refaktor to nie jest jak zmiana lakieru na samochodzie, to jest bardziej jak wymiana oleju, zmiana klocków, włożenie nowych wycieraczek, dolanie płynu chłodniczego, zrobienie przeglądu. Jeśli myślisz że refaktor to np przetarcie szmatką kurzu z felg, to myślę że tutaj leży też Twoja wina.

Refaktoru nie robi się po to "żeby było ładnie", tylko po to żeby dało się szybko wprowadzać zmiany, bez dodawania defektów.

• tzw rozwój spowalnia dewelopment, chociażby to była inwestycja która zwróci się za rok czy dwa, to kto da głowę czy menago, VP czy inny na górze będzie za rok czy dwa na swoim stołku - on musi mieć sukces teraz, już

Tak samo jak wymiana oleju sprawi ze nie pojedziesz gdzieś teraz, tylko za chwilę. Ale jak długo można jeździć bez wymiany oleju? ;) I innych czynności okresowych.

• często firmy kupują małe firmy, które coś klepnęły, żeby to sprzedać - potem duża firma "inwestuje" to znaczy każde dodawać nowe ficzery, a nie podbijać np wersję języka

Czyli rozumiem że jak kupisz nowe auto, to nie dolejesz do niego płynu chłodniczego? :D

• na nic nigdy nie ma czasu - zapieprz taki, że nie ma kiedy taczek załadować :)

Again, analogia do saamochodu.

@TomRiddle: historia z mojego życia
kiedyś aby nam "pomoc" zatrudniono konsultanta, prze dzika, super ogara, doświadczonego, który miał nam zrobić 2 czy 3 ciężkie taski
zrobił - zebrał laury, pochwałki oficjalne itp itd

+/- rok po tym wreszcie pozbyliśmy się (jako zespół) jego rozwiązań z kodu bo to była masakra (robiliśmy to w ramach tasków) - ale to była masakra dla nas nie dla niego
jak myślisz ile osób poza naszym zespołem wiedziało, że generalnie koleś koniec końców nie pomógł a dołożył roboty

ref napisał(a):

@TomRiddle: historia z mojego życia
kiedyś aby nam "pomoc" zatrudniono konsultanta, prze dzika, super ogara, doświadczonego, który miał nam zrobić 2 czy 3 ciężkie taski
zrobił - zebrał laury, pochwałki oficjalne itp itd

+/- rok po tym wreszcie pozbyliśmy się (jako zespół) jego rozwiązań z kodu bo to była masakra (robiliśmy to w ramach tasków) - ale to była masakra dla nas nie dla niego
jak myślisz ile osób poza naszym zespołem wiedziało, że generalnie koleś koniec końców nie pomógł a dołożył roboty

Za mało info podałeś żeby to ocenić.

Oczywiście, mogło być tak zrobił na odwal się szyko, i dołożył długu technicznego; ale mogłobybyć też odwrotnie.

Za mało szczegółów żeby to ocenić.

@TomRiddle: nie zrozumiałeś przekazu - moja wina jako nadawcy
oczywiście masz rację - refaktor, spłacanie dług, pokrycie testami - długofalowo się spłaca
ale jak powiesz dyrektorowi albo wyżej - ze teraz będziemy robić refaktor przy okazji ficzerów przez co szybkość spadnie przez dwa lata np o 50% ale za dwa lata wzrośnie o 200% albo i więcej

to taki dyrektor powie - za dwa lata to może mnie tu nie być
ja potrzebuję czegoś na bieżący rok obliczeniowy aby dać dobrze zrobić akcjonariuszom inwestorom itp itd

refaktor to jest koszt dla firmy
a utrzymanie nawet dev na 3 linii wsparcia to zysk - bo za to już płaci klient

gadałem o tym z menago, ze dla mnie to jest bez sensu, nie poświęcimy teraz czasu aby potem było lepiej - ale on mi wytłumaczył korpy dogadują się między sobą na warunki i nawet jak błąd będzie robiony 2 tygodnie zamiast dnia to w ramach kontraktu i tak firma na swoje wychodzi

pieniądz rządzi i to ten bieżący a nie przyszły

@TomRiddle: przez nieznajomość biznesu było to zrobione fatalnie - kraszowała się aplikacja, nie było możliwości podpiecia obsługi innych zdarzeń itp itd
chodziło o to aby pokazać jakiś happy path klientowi i tyle
byle by ktoś tam widział że "działa" że to co było zapowiedziane że będzie do danej daty jest

@mortadelek: trafiłem na podobną mine, uciekłem po okresie próbnym

ref napisał(a):

refaktor to jest koszt dla firmy

Poza tym; kurde; ile można jechać na tym samym. Jak ja robię refaktor to mi to zajmuje kilka sekund albo minut max, i back commit. Więcej Ci zajmie czasu żeby napisać post o tym żeby nie refaktorować niż ten faktyczny refaktor.

@TomRiddle: kolejna historia z życia
na początku roku szefostwo ogłasza że mamy w tym, roku 10k godzin na inwestycje techniczne

akurat trafiłem na taska, gdzie trzeba byłoby przerobić walidację tak aby działała ona na tabelce i na widoku graficznym
jako że sama przeróbka i podłączenie walidacji pod różne akcje/kontroli to spore zadanie, większe niż bieżący task - rozmowa z manago i architektem czy w ramach tych 10000 h nie przeznaczyć części na takie zadanie

odpowiedź - 10000 h już się skończyło, nie ma czasu, zróbcie 2 osobne walidacje

był to początek kwietnia, przed Wielkanocą

no i pogadane

ale ty myślisz ze duza liczba osób w firmie implikuje dobrą jakosc?

to tak nie działa.

duze firmy interesują duze pieniadze, nikogo nie interesuje jakość kodu

jeśli da sie zarobić dużą kase tanim softem to tak będzie

wyjątek pojawia sie wtedy gdy spotkają sie odpowiednie osoby (pasjonaci, zdolni) i posiedzą w firmie kilka lat i będą kod i "cieniasów" trzymać za mordę

jesli masz w firmie samych cieniasów to kod jest kiepskiej jakości, to nie kwestia gonienia deadlinów - dobry dev umie napisać dobry kod szybko

zly dev nie napisze dobrego kodu ile czasu bys mu nie dał.

@marian pazdzioch: soft ma tą cechę że bebechów nie widać
kupujesz samochód otwierasz maskę i widzisz czy tam jest "ładnie" potrafisz to ocenić nawet patrząc pobieżnie, kolejny przykład pralka - niemalże każdy zdaje sobie sprawę, że jak bęben klejony to raczej jednorazówka
a kto potrafi tak ocenić soft, komu na tym zależy?
ważne żeby było ładnie i żeby działało
soft to jest bardziej jak parówka - ma smakować, czasami lepiej nie wiedzieć jak i z czego jest robiony ;)

a programista - ot zwykły pracownik i czym większa korpo tym mniej od niego zależy, nikt nie będzie płakał jak komuś nie przypadnie do gustu wygląd kodu, nie ten to następny