Firmy nie uczą się na błędach?

0

Hej,
Odnoszę wrażenie, że mimo iż rynek bardzo potrzebuje programistów (panuje rynek pracownika) to jednak wiele firm to totalnie ignoruje i popełnia te same błędy. Zauważyłem, że zazwyczaj gdy programista chce się rozwijać, wprowadzać standardy pezy kodowaniu projektu itd to zleceniodawca/pracodawca zazwyczaj w du*** to ma... Ty masz tylko siedzieć i klepać." Testy? Po co je pisac? Za jakis czas zaczniemy pisac".... "Wzorce a po co?" Później gdy programista tego nie wytrzymuje i rzuca papierkiem wielkie zdziwienie.

5

Niestety w przypadku mniejszych firm prościej znaleźć klienta, który nie ma za dużo kasy, niż takiego, który ma jej sporo. Ten pierwszy zawsze będzie chciał mieć zrobione szybko i tanio, byle działało. Ten drugi może sobie pozwolić na większa "fanaberie" - czyli testy, większe przykładanie się do kodu, itp.

3

Teza postawiona w tytule wątku jest mniej-więcej tak samo sensowna, jak Polacy się nie myją albo każdy facet zdradza swoją żonę :P

Oczywiście, znajdzie się wiele przypadków na potwierdzenie obu w/w tez, ale nie można generalizować. Chciałem napisać, że są i małe firemki, jak i korporacje, ale chyba tutaj akurat rozmiar nie ma znaczenia. Zamiast tego napiszę więc, że są firmy porządne oraz dziadowskie. To, o czym piszesz na pewno występuje w wielu firmach, ale też istnieją takie, w których liczy się jakość kodu i które pokazują podejście wykraczające poza "ma się skompilować" ;)

A tak w ogóle to jeszcze jedna rzecz mi przyszła do głowy - piszesz o uczeniu się na błędach. Podejrzewam, że większość firm, które mogłyby się zaliczyć do opisanej przez Ciebie grupy, swojego postępowania nie uznaje za błąd. Jak są jakieś problemy, to winny jest programista, który wymyśla jakieś testy, albo który nie zdążył czegoś zrobić na czas. Winny tez jest klient, bo za wiele wymaga albo za mało płaci. Winna jest konkurencja, która podebrała pracownika lub która wypuściła konkurencyjny program, do tego 2x tańszy i 3x lepszy. Zawsze ktoś jest winny, ale nigdy nie jest to firma. Skoro więc nie ma winy po jej stronie, to o jakich błędach mówimy? ;)

4

Po pierwsze przestań pracować w firmach gdzie liczy się szybki efekt. Głównie software house. W znakomitej większości tego typu przypadków cel biznesowy to: Złapać projekt, szybko dowieżć, przejść niezauważenie przez kontrolę jakości, zgarnąć kasę i zapomnieć.

Po drugie od decyzji o tym czy pisać testy lub refaktorować kod jesteś ty i nikt inny. Pisz i refaktoruj nikogo nie pytając, ostatecznie to ty w tym szambie nurkujesz i zwykle tak głęboko, że innych wzrok już tam nie dociera. Z doświadczenia Ci powiem, że dobry kod nabiera szybkości i jest dostrzegany nawet po kilku miesiącach. A gdy zabiera Ci to większość czasu, to prawdopodobnie robisz to źle.

Jedynym wyjątkiem są firmy gdzie liczy się szybki time to market, ale gdy taka firma przeżyje to staje się zwykle firmą produktową i sytuacja się sama naprawia.

2

W sumie pasuje tu sytuacja w mojej firmie (< 50 osób) z tego tygodnia. W poniedziałek zebranie, prezes pokazuje wykresy i mówi że jest źle bo sprzedaliśmy projekt za X, a na development, testy i powstałe w developmencie bugi wyszło 120% X, czyli generalnie tracimy kase. A jak wygląda proces sprzedaży? Gość, który ma 0 pojęcia technicznego negocjuje jak najniższą cenę żeby wygrać przetarg, następnie TL dostaje ten projekt z góry wyznaczoną datą release. W efekcie wychodzi napisany byle jak, po godzinach, gniot, praktycznie bez testów, obowiązkowo w architekturze controller/service/repository. No ale przyszedł czas na zmiany, nie będziemy już zaniżać wycen i robić byle jak. Dostaliśmy coś do wyceny, wyszło nam powiedzmy 100 MD, gdzie zaplanowany był czas na testy, dobre praktyki, review, ale wszystko w granicach zdrowego rozsądku, bez wycen typu 5SP na dodanie przycisku na stronie. Wszystko było pięknie, dopóki nie przyszedł prezes i nie powiediał, że słuchajcie, ale my to już w sumie sprzedaliśmy za 70 MD i musicie się w takiej wycenie zmieścić.

7

Rynek pracownika nie polega na spełnianiu każdej fanaberii. Często testy i refaktoring to nie jest kwestia chęci firmy ale tego jak programista sprzeda to co chce robić. Każda inicjatywa techniczna powinna w sobie zawierać wartość biznesową bo inaczej to palenie pieniędzy i niestety ale żadne zapewnienie o tym, że „bedzie sie to łatwo utrzymywać” nie zmieni sytuacji gdzie bez szybkiego delivery nie będzie ZA CO tego wszystkiego utrzymywać. Powiedziałbym wręcz, że firma która jest świadoma swojej sytuacji i wie dlaczego tnie np. na testach to lepsza szkoła dla programisty niż gniazdko gdzie zawsze wolno wszystko.

Do tego dochodzi też definition of done. Jeśli dasz się przekonać że możesz dowieźć bez testów to zazwyczaj będzie to wykorzystywane przeciwko tobie. Jeśli jednak testy i kod aplikacji to dla ciebie jedna całość, to nie dajesz estymat na sam ficzur tak jak nie dowozi sie pół auta. Kultury pracy tez trzeba bronić samemu stety/niestety.

1

Testy, wzorce, dobre praktyki to moim zdaniem odpowiedzialność po stronie programisty - pracodawca/zleceniodawca nic do tego nie powinien mieć, co więcej nie musi nawet wiedzieć co tam sobie robisz w tle. Stosowanie tych wszystkich praktyk nie jest po to, żeby programista był szczęśliwy, ale właśnie żeby biznes dostawał w miarę szybko zmiany bez błędów - więc jeżeli Twój biznes tego nie chce, to może robisz to źle albo niepotrzebnie w ogóle im o tym mówisz.

0
psmyrdek napisał(a):

Rynek pracownika nie polega na spełnianiu każdej fanaberii. Często testy i refaktoring to nie jest kwestia chęci firmy ale tego jak programista sprzeda to co chce robić. Każda inicjatywa techniczna powinna w sobie zawierać wartość biznesową bo inaczej to palenie pieniędzy i niestety ale żadne zapewnienie o tym, że „bedzie sie to łatwo utrzymywać” nie zmieni sytuacji gdzie bez szybkiego delivery nie będzie ZA CO tego wszystkiego utrzymywać. Powiedziałbym wręcz, że firma która jest świadoma swojej sytuacji i wie dlaczego tnie np. na testach to lepsza szkoła dla programisty niż gniazdko gdzie zawsze wolno wszystko.

Do tego dochodzi też definition of done. Jeśli dasz się przekonać że możesz dowieźć bez testów to zazwyczaj będzie to wykorzystywane przeciwko tobie. Jeśli jednak testy i kod aplikacji to dla ciebie jedna całość, to nie dajesz estymat na sam ficzur tak jak nie dowozi sie pół auta. Kultury pracy tez trzeba bronić samemu stety/niestety.

Ten post to popadanie z jednej skrajności w kolejną nie jest rolą programisty o takie rzeczy dbać ale team leadera albo/i menadżera.

Brak funduszu/czasu na testy i brak pewnego buforu w projekcie świadczy że to albo projekt do szuflady albo robi to software house dla jakiegoś janusza.
Żaden ogarnięty leader nie zgodzi się na dowiezienie czegos na szybko bo pieniazkow brakuje na dodatkowy tydzien/dwa pracy przy odpowiednim napisaniu testów i przemyślenie architektury, największy "dług" powstaje właśnie na samym początku projektu.
Zdarzyło mi się pracować w fintechu który obracał miliardami dolarów (doslownie) i CTO oraz wczesniejsi developerzy niedbali o architekturę oraz testy bo trzeba było dowieść nowy ficzer, koniec koncow po 2 latach takiego klepania dług był na tyle duży że nad dodawaniem paru nowych małych ficzerów pracował zespół 20 osób i zajmowało to tyle samo czasu co podobne ficzery wdrażane w banku kiedy w nim pracowałem (nad nimi pracował zespól 8 osób).
Wszystko to było związane z ogromnym długiem technologicznym projektu bo nie było sensownych testów oraz architektura to było dno, sam na początku miałem ten plus że pracowałem nad całkowicie nowym projektem i się o to nie martwiłem, ale trzeba było jego częsci go w końcu wdrożyć w stary system natomiast gdy zobaczyłem ten projekt i zacząłem tam dopisywać kolejne moduły ML'owe to odpuściłem pracę w tej firmie (tak jak część mojego zespołu) bo po prostu się nie opłacało marnować swojego czasu na taki syf (mimo naprawdę dobrych pieniędzy).

TL;DR z mojej strony testy i przemyślana architektura zawsze owocuje pozytywnie po pewnym czasie (najczęściej są to miesiące) i wcale nie jest to "brak wartości biznesowej" tylko wartość rozłożona w czasie -> przykładem podobnego podejścia będzie tutaj budowanie swojego bolidu w F1 jasne można zrobić to szybko bo trzeba coś dowieść albo nie masz hajsu i budujesz po łebkach ale później taki projekt kończy jak Williams. Ja tam jednak preferuje prace w mercedesie :P i radze każdemu uciekać z projektów które muszą być dowiezione na już bez tych dodatkowych tygodni* na testy i architekturę.

**Post nie dotyczy startupów w bardzo wczesnej fazie

0

Konwencja jest taka. Team leaderzy mają w D architekturę, w większości przypadków nie rozumieją podstawowych wzorców, nie wspominając o SOLID. Zwykle po roku czy dwóch latach wydajność zespołu spada o ponad połowę, a w drożenie kogoś nowego w projekt często graniczy z cudem :P. Wtedy ponowie seniorzy zmieniają firmę i dalej robią swoje, często za lepszą kasę. Zauważyłem też inną zależność im większy nacisk rekrutanci stawiają na wysoki standard wytwarzanego kodu w jakiś pytaniach, czy jakimś programing live, tym z większym szambem będziesz pracować. :D

6

Prowadzenie działalności gospodarczej nie polega na pisaniu testów czy dobrych praktykach tylko na zarabianiu pieniędzy. Zarabianie pieniędzy polega z kolei na pozyskiwaniu zleceń za możliwie wysoką stawkę i trzymaniu kosztów w ryzach. Jeżeli przykładowo klient ścina cenę, bo konkurencja próbująca wejść na rynek daje taniej to prezes czy jakiś dyrektor zarządzający widząc rosnące koszty pracy (poprzez wzrost wynagrodzeń, ZUSów, benefitów itp.) musi jakoś ograniczyć koszty. Pada na testy i dobre praktyki. Ktoś powie, że to niedobrze, bo to bardzo krótkowzroczna decyzja. Owszem, ale należy też pamiętać, że statystycznie na 100 firm założonych pierwsze 2 lata przetrwa tylko 20, a powyżej 10 lat tylko jedna, więc trzeba się skupić na tu i teraz i zarobić pieniądze, a nie myśleć o przyszłości. Sorry, za tak mało romantyczną wizję, ale tak to działa - jako zwykłe balansowanie kosztami.

1
baroo napisał(a):

Prowadzenie działalności gospodarczej nie polega na pisaniu testów czy dobrych praktykach tylko na zarabianiu pieniędzy. Zarabianie pieniędzy polega z kolei na pozyskiwaniu zleceń za możliwie wysoką stawkę i trzymaniu kosztów w ryzach. Jeżeli przykładowo klient ścina cenę, bo konkurencja próbująca wejść na rynek daje taniej to prezes czy jakiś dyrektor zarządzający widząc rosnące koszty pracy (poprzez wzrost wynagrodzeń, ZUSów, benefitów itp.) musi jakoś ograniczyć koszty. Pada na testy i dobre praktyki. Ktoś powie, że to niedobrze, bo to bardzo krótkowzroczna decyzja. Owszem, ale należy też pamiętać, że statystycznie na 100 firm założonych pierwsze 2 lata przetrwa tylko 20, a powyżej 10 lat tylko jedna, więc trzeba się skupić na tu i teraz i zarobić pieniądze, a nie myśleć o przyszłości. Sorry, za tak mało romantyczną wizję, ale tak to działa - jako zwykłe balansowanie kosztami.

HAHAHA :D No bo przecież budowanie i odpalanie za każdym razem monolitu tylko po to, aby znaleźć przyciski w ntefejsie, które trzeba przeklinać, to mniej kosztuje niż poświęcenie 2 minut na napisanie testu automatycznego, a klient i tak dzwoni i powie, że mu to nie działa, tak jak powinno, no w uj to zmniejsza koszty. :D Wasz problem nie leży w ekonomii tylko w braku kompetencji do zarządzania ludźmi, którego fach jest wam obcy oraz problemu dobierania tych ludzi. A koszty testowania rosną, ale wtedy kiedy ludzie nie potrafią tworzyć architektury prostej w testowaniu i to wynika, bezpośrednio z braku kompetencji a nie z jakiejś strategi zarządzania biznesem, bo co to za biznes, który dostarcza nieprzetestowany soft. Hahaha. :D

3

Z moich obserwacji wynika że hipoteza rynku pracownika w IT jest w znacznej mierze mitem, podtrzymywanym przez dziennikarzy ze względu na sensacyjność tematu i szkoły programowania. Może kilka lat temu kiedy firmy masowo migrowały z Indii do Europy wschodniej chwilowo był drastyczny nadmiar popytu nad podażą, ale teraz sytuacja wyraźnie okrzepła. Przykłady: Sabre regularnie odwala maniany z falowym zwalnianiem pracowników, jakimiś dziwacznymi aneksami niezgodnymi z polskim prawem, rezultat: właśnie przenoszą się do większego biura na 1000 osób. Moja aktualna firma, żadna wielka marka, w ciągu kilku tygodni zatrudnili około 10 programistów zapełniając większość wakatów, i to są ludzie z z doświadczeniem a nie jacyś juniorzy po studiach. Oczywiście mistrz z wieloletnim doświadczeniem znajdzie pracę bez problemu ale to dotyczy obecnie praktycznie każdej branży, sytuacja IT nie jest pod tym względem wyjątkowa.

1

@Czulu:
Bo Sabre to było, jest i będzie Sabre.

0

Nie mam jeszcze odpowiedniej szkoły, ale w programowaniu staram się być zbyt dokładny, nie lubię pisania w stylu hindusów, czyli na odpier...się! Taki trochę idealista jestem, mój kod musi ładnie wyglądać i być dopieszczony. Czy mam szansę w firmie?

3
vin napisał(a):

Nie mam jeszcze odpowiedniej szkoły, ale w programowaniu staram się być zbyt dokładny, nie lubię pisania w stylu hindusów, czyli na odpier...się! Taki trochę idealista jestem, mój kod musi ładnie wyglądać i być dopieszczony. Czy mam szansę w firmie?

Każdy normalny programista nie pisze na odp***, więc sorry Winnetou, ale nie jesteś jakiś unikalny, takich jest masa. Zresztą ciężko stwierdzić jak Twój kod wygląda, bo nikt go nie widział.

5

Odnoszę wrażenie, że mimo iż rynek bardzo potrzebuje programistów (panuje rynek pracownika) to jednak wiele firm to totalnie ignoruje i popełnia te same błędy.

tak samo jak wielu programistow zamiast pisac porzadnie odwala fuszerke i tylko placze ze brak awansu/podwyzki a przeciez sie nalezy.

Zauważyłem, że zazwyczaj gdy programista chce się rozwijać, wprowadzać standardy pezy kodowaniu projektu

gdy firma chce wprowadzac innowacje czy standardy to wiekszosc programistow sie burzy bo oni juz 10 lat robia swoje i sa mistrzami i jak to im ktos bedzie mowil co maja robic...

Ty masz tylko siedzieć i klepać.

e tam, wielu programistow to by tak chcialo siedziec i klepac. a tu kaza na spotkania chodzic i dyskutowac o glupotach... albo robic devopsy czy inne supporty

Testy? Po co je pisac? Za jakis czas zaczniemy pisac

hmm programisci tez maja takie cos "ja pisze kod ktory dziala, niech testerzy testuja" :)

Później gdy programista tego nie wytrzymuje i rzuca papierkiem wielkie zdziwienie.

ach te delikatne weny i charaktery programistow. nikogo juz chyba nie dziwi to ze programisci to dosc ulotny zasob. po prostu rozne sa priorytety biznesowe, takie a nie inne podejscie wynika z oplacalnosci. tobie wydaje sie to "bessesu", a firma wlasnie w ten sposob wiaze koniec z koncem, tu nie ma miejsca na sentymenty i dyskusje o wzorcach

3

Korpo-Rynek łyka każdego kto albo jest OK albo rokuje na OK. Kiedy nie ma na polskim rynku nikogo "z tym warunkiem bycia OK albo z tamtym warunkiem bycia OK", to korpo lokuje poszukiwania w Meksyku, Mołdawii, Wietnamie, na Białorusi itp.

Chcieliście globalizacji to ją macie :)
Jest praca programistów (zdalna) dla firm z całego świata. Jest dla równowagi lokowanie pracy przez międzynarodowe korporacje w dalekich krajach.
To ssanie działa na okrągło na całym świecie, może poza Koreą Północną, Iranem i paroma krajami.
Kto się łapie na zapotrzebowanie tego zasysa. Kto się nie łapie to ten narzeka na mit niedoboru specjalistów. Przy czym pojęcie "Łapie się" nie za bardzo zależy od samej liczby lat "spędzonych przed klawiaturą".

Zasada działania jest prosta: Płacimy tobie programisto dużo, dlatego że dzięki twojej pracy zarabiamy znacznie więcej.
To wszystko, żadnych cudów, mitów, sensacji medialnych.

7

Przecież napisanie kodu z testami zajmuje mniej czasu niż bez nich, chociażby dlatego, że nie trzeba wielokrotnie uruchamiać aplikacji i klikać w celu sprawdzenia każdej drobnej zmiany.

Więc pytanie powinno brzmieć - co jest nie tak z programistami w tych firmach, że zamiast ułatwić sobie życie pisząc testy, narzekają, że "nikt im nie daje czasu na pisanie testów"? I po co w ogóle pytać o to zleceniodawcę? Jak jadę wymienić koła, to mnie mechanik nie pyta, czy ma odkręcać koła kluczem ręcznym czy pneumatycznym, bo to w jego interesie jest zrobić to jak najszybciej.

1

Przecież każda drobna zmiana może polegać właśnie np. na dodaniu albo usunięciu przycisku, pola tekstowego, pola wyboru albo jakiegoś diva do wyświetlania jakiegoś tekstu, kalendarza, komponentu do wyświetlania wykresów itd. dodanie nowego kodu AJAX albo po stronie serwera innych rzeczy czyli co? Do tego trzeba dodawać, usuwać albo modyfikować testy? Ja nie wiem czy to zajmie tak mniej czasu bo jakoś nie wyobrażam sobie żeby zleceniodawca sam ręcznie nie przetestował tych zmian albo nie zrobiliby to zatrudnieni do tego testerzy.

Co do samych testów, ja nie wiem, Wy uważacie że mają jakąś rolę gwarancyjną? No przecież same testy można nie do końca poprawnie napisać, bo nie uwzględnione są jakieś warunki ekstremalne. Mógłbym tu podać niejeden przypadek, w którym same testy automatyczne by nie wystarczyły, np. jak coś się czasem sypie na jakimś serwerze i są czasem problemy z zapisem do sesji albo problem z połączeniem z MySQL (miałem już takie przypadki), możliwe infekcje wirusowe plików PHP (też miałem taki przypadek), zmiana PHP z 5 na 7 nawet bez wiedzy programisty a np FW nie był do tego przygotowany (miałem kilka razy takie przypadki). I wszystko było możliwe do wykrycia przez automatyczny system powiadomień o awariach na email wraz z pełnym Stack Trace i nawet fragmentami kodów w PHP, który od dawna mam jako system kontrolny i dzięki temu wiem pierwszy, zanim nawet sam zleceniodawca by się zorientował.

Są jeszcze inne rzeczy np. implementacja płatności kartą, gdzie nawet zanim Wam pozwolą na przełączenie z sandbox na realne konto to i tak wszystko musi przejść przez weryfikację poprawności czy tam bezpieczeństwa, więc nie wszystko takie proste jakby się wydawało.

2

@somekind: nie jesteś już przecież taki młody, nie mów ze nie widziałeś takich akcji :P Ja np. widziałem sytuacje z serii QA ma zakaz zgłaszania nowych bugów, bo jesteśmy przed releasem i issue tracker ma być czysty w chwili releasu albo Wiemy że jest bug XYZ, ale releasujmy mimo wszystko i wrócimy do tego buga dopiero jak klient nam go zgłosi, a zanim się do niego dokopowie to minie trochę czasu :D

3
Shalom napisał(a):

@somekind: nie jesteś już przecież taki młody, nie mów ze nie widziałeś takich akcji :P Ja np. widziałem sytuacje z serii QA ma zakaz zgłaszania nowych bugów, bo jesteśmy przed releasem i issue tracker ma być czysty w chwili releasu albo Wiemy że jest bug XYZ, ale releasujmy mimo wszystko i wrócimy do tego buga dopiero jak klient nam go zgłosi, a zanim się do niego dokopowie to minie trochę czasu :D

Pierwszego nie rozumiem, przecież klient nie patrzy w issue tracker, a jak patrzy to wystawia mu się jakiś fake'owy

Drugie jak najbardziej ma sens jeśli to jest jakiś mało istotny bug. Lepiej żyć że znanym bugiem niż stworzyć criticala próbując naprawić pierdółkę

0

@Shalom: no różne malowanie trawy na zielono widziałem. Ale ja o testach pisałem, a nie o zgłaszaniu bugów i pracy QA. :)

4
drorat1 napisał(a):

Przecież każda drobna zmiana może polegać właśnie np. na dodaniu albo usunięciu przycisku, pola tekstowego, pola wyboru albo jakiegoś diva do wyświetlania jakiegoś tekstu, kalendarza, komponentu do wyświetlania wykresów itd. dodanie nowego kodu AJAX albo po stronie serwera innych rzeczy czyli co? Do tego trzeba dodawać, usuwać albo modyfikować testy? Ja nie wiem czy to zajmie tak mniej czasu bo jakoś nie wyobrażam sobie żeby zleceniodawca sam ręcznie nie przetestował tych zmian albo nie zrobiliby to zatrudnieni do tego testerzy.

Pisałem o pracy programisty, nie o frontendowca.

Co do samych testów, ja nie wiem, Wy uważacie że mają jakąś rolę gwarancyjną? No przecież same testy można nie do końca poprawnie napisać, bo nie uwzględnione są jakieś warunki ekstremalne.

Można. Ale można też je napisać dobrze, trzeba tylko rozumieć jak ma działać to, co się testuje.
A rola gwarancyjna polega na tym, że łatwo i szybko można sprawdzić, czy zmiana nie powoduje błędów w istniejącym kodzie, a nie czy zmiana jest w pełni poprawna.

Są jeszcze inne rzeczy np. implementacja płatności kartą, gdzie nawet zanim Wam pozwolą na przełączenie z sandbox na realne konto to i tak wszystko musi przejść przez weryfikację poprawności czy tam bezpieczeństwa, więc nie wszystko takie proste jakby się wydawało.

Ja nie pisałem o tym, żeby nie testować integracyjnie, ani o tym, że QA nie są potrzebni. Ja pisałem o testach w pracy programisty.

1 użytkowników online, w tym zalogowanych: 0, gości: 1