Biznes – wróg dobrego kodu

Czytając wpis Michała Bartyzela, „Czysty Kod”, wujka Boba oraz rozważając ostatnie wydarzenia w fabryce dochodzę do wniosku, że głównym wrogiem dobrego, czystego kodu jest biznes. Nie jest to dobrze widoczne ponieważ biznes zawsze będzie mówił językiem marketingu o „najwyższej jakości”, „niezawodności”, „najnowocześniejszych technologiach. Czyli ujmując prościej pierdolenie kotka przy pomocy młotka. Może to kwestia odpowiedniego uodpornienia na reklamę, a może patologiczne postrzeganie biznesu, ale jakoś nigdy to do mnie nie trafiało… Istnieją pewne wskazówki pozwalające na wskazanie biznesu jako głównego podejrzanego w sprawie o psucie kodu.

Jakość biznesowa != jakość

Ta stara prawda odnosi się do wszystkich aspektów rynkowych. Nie tylko IT. Wspominałem ostatnio, że wolny rynek ma tendencję do tworzenia rozwiązań w ramach „planu minimum”. Z punktu widzenia klienta kupującego aplikację oznacza to minimum kosztów, minimum czasu, maksymalne pokrycie wymagań. Dobry handlowiec wie o tym i takie właśnie wymagania przekaże do realizacji programistom. Ci mając na uwadze terminy i specyfikację oraz fakt, że dobry kod w przeciwieństwie do pizzy nie wyżywi czteroosobowej rodziny zaczynają popadać w bylejakość. Inaczej… zaczyna robić szybko i niedokładnie. Zaczyna ignorować zasady, które zna, ale ich zastosowanie wymaga czasu.
W pierwszej kolejności ofiarą jakości biznesowej padają zazwyczaj testy. Kod testów nie wnosi nic do aplikacji. Za kod testów klient zazwyczaj nie płaci i nie ma zamiaru płacić. Zatem jeżeli przygotowanie testów zajmie ci cały dzień, a na ich podstawie kodowanie 2 godziny i porównamy to do sytuacji gdy bez testów przygotujesz działający kod w 6 godzin to zdaniem klienta przepłaca o 4 godziny. Ty masz robić kod aplikacji, a nie testów…
Na drugim miejscu jest dokumentacja. Najlepszy rodzaj dokumentacji to kod samodokumentujący się. Jednak by takie coś było możliwe trzeba przygotować pewną przynajmniej szczątkową dokumentację. Jeżeli nasze API jest zbiorem pewnych pojęć domenowych to do ich zrozumienia i tak potrzebna jest wiedza o tym czym jest domena. Brak takiej wiedzy, którą czerpie się z dokumentacji, będzie owocował konfliktami pojęć pomiędzy elementami systemu, nieporozumieniami pomiędzy programistami i klientami, a w ostateczności nieprawidłowym użyciem API co prowadzi do budowania różnych dziwnych obejść, a te tylko wprowadzają większy burdel.
Trzecie miejsce zajmuje organizacja kodu. Paradoksalnie chcąc przyspieszyć sobie pracę zaczynamy zmieniać organizację kodu w taki sposób by „mieć pod ręką” to co aktualnie potrzebujemy. „Pod ręką” oznacza zazwyczaj w tym samym pliku. Przykładem jest wbijanie w klasy biznesowe obsługi połączeń do bazy danych. Szczególnie widać to w trochę starszych aplikacjach gdzie programiści nie mieli jeszcze do czynienia z ORMami czy frameworkami IoC/DI.

Mamy zatem pierwszą poszlakę. Biznes narzucając sztywne ramy czasowe i oczekując tylko na wynik powoduje, że produkt końcowy ma ładne opakowanie, niezłą funkcjonalność, ale stając wobec problemu wymiana akumulatora zaczynamy być bezradni. Oczywiście sztywne ramy czasowe są nieodzowne, bo inaczej programiści tworzyli by do świętej nigdy, ale niech będą to rozsądne terminy, a nie terminy najtańsze. W ten sposób mamy jakość biznesową. Jakość działa, jakość się nie wysypuje.

Biznes ślepo wierzy w „mądrości ludowe”

Jedna z nich mówi, że „lepiej poprawiać niż przepisywać od nowa”. Jest ona słuszna, ale tylko do pewnego etapu. Załóżmy, że odziedziczyliśmy po wujku starego malucha. Chcemy jednak mieć samochód sportowy. Ferrari najlepiej. Mamy dwie opcje, jeżeli chcemy korzystać z mądrości ludowej, jak nie to jedną. Po pierwsze możemy kupić Ferrari. Nie jest to głupie rozwiązanie, ale kłóci się z mądrością o „poprawianiu, a nie robieniu od nowa”. Zatem wybieramy rozwiązanie drugie, głupie. Kupujemy wiadro czerwonej olejnej, paczkę tazosów i zamykamy się w garażu. Dzielnie przemalowujemy naszego malucha na czerwono, a z paczki tazosów staramy się wyciągnąć tego z kucykiem. Kucyka przykleimy na maskę.
Generalnie mamy Ferrari. Silnik jest? Jest! Koła sztuk cztery są? Są! Kolor czerwony? Wedle rozkazu! Konina ma mace? No ba!!! Zajeżdżamy naszym „Ferrari” do warsztatu, mechanik otwiera maskę tył (o kurwa… nawet silnik jest z tyłu!!!) i …. albo nas wypierdoli z warsztatu, albo jeżeli jest informatykiem to nie chcąc być gorszym od pizzy zacznie grzebać w jakiejś domowej roboty instalacji gazowej.

Poszlaka numer dwa. Biznes zbyt sztywno trzyma się reguł i „złotych myśli” nawet tam gdzie jest to zbyt ryzykowne w porównaniu do pójścia w przeciwnym kierunku.

Biznes olewa zdanie programistów

Wymień trzy największe firmy/inicjatywy IT ostatnich 15 lat. Goolge, Facebook, Nasza Klasa. Co je łączy? Każda z nich jest lub była dowodzona przez informatyków. Gości, którzy wiedzą co to są wzorce projektowe, czym jest test jednostkowy i dlaczego niektóre rzeczy choć wyglądają na biznesowo dobre to w praktyce polegną.
Generalnie pracowałem już w kilku miejscach i mam porównanie. Z szefami-informatykami idzie się dogadać znacznie łatwiej niż biznesmenami dla których komputer to czarna magia.
Tacy ludzie wychodzą z założenia, że programista jest tylko zasobem. Takim samym jak ci Chińczycy, których popędzał batem w poprzedniej firmie gdzie sprzedawał jakieś cichy. W dodatku zasobem łatwo wymienialnym i nie wartym przez to uwagi. Programiści nie robią nic konkretnego (filozoficzny temat – „programista produkuje nic – czyli dlaczego upadł system gospodarczy”), są drodzy w utrzymaniu, a ich praca jest zbyt delikatna i zbyt odpowiedzialna z biznesowego punktu widzenia by mogli ją wykonywać tacy ludzie. Niestety innych nie ma, a zastąpienie programistów tresowanymi małpami też odpada (ekoterroryści). Kilkukrotnie spotkałem się z takim podejściem, że programista nic nie wie. Nie rozumie tego co ma być zrobione i generalnie jest sabotażystą chcącym zniszczyć biznes. Biznes jednak nie łapie, że programista jako z natury leniwy będzie szukał rozwiązań optymalnych, a nie oczywistych.
Przykładem jest pewien program zliczający krotki w bazie danych. Wersja oczywista dla programisty – dwa triggery jeden na insert drugi na delete. Względnie zamiast drugiego procedura usuwająca w przypadku konieczności wycofania transakcji w późniejszym czasie (takie trochę to zagmatwane, bo transakcja biznesowa składa się z kilkudziesięciu kroków – transakcji, a te mają po kilkaset transakcji w sensie RDMS) lub tak jak w moim przypadku w przypadku „przeterminowania” krotki i konieczności jej usunięcia (co jest kolejnym debilizmem systemu…), ale jednocześnie nie chcemy usuwać informacji o tym, że była (krotka to po prostu usługa biznesowa, która idzie do faktury). Rozwiązanie biznesowe… oddzielna procedura, która musi być odpalona w odpowiednim momencie i w dodatku nie ma możliwości jej powtórzenia po jakimś czasie, bo dane fizycznie wyleciały z bazy.
Ech… najlepsze jest to, że testy są prowadzone w taki sposób, że co kilka dni trzeba weryfikować warunki, by przechodziły „ilościowo”.

Zatem kolejna poszlaka. Biznes nie słucha programistów, ignoruje ich doświadczenie i umiejętności sprowadzając ich do roli łatwo wymienialnego zasobu. Powoduje to stawianie dziwnych celów, które owocują jeszcze dziwniejszymi rozwiązaniami. Jeżeli dodamy do tego poprzedni punkt to otrzymujemy ciekawą mieszankę… coś jak młotek do śrub.

Korporatyzacja innowacyjności

CepeliaW jest najlepszym przykładem tego co kryje się pod powyższym pojęciem. PRL był zbudowany z różnych absurdów. Moim zdaniem duża część z nich wynikała w dużej mierze ze zwykłej ludzkiej złośliwości, a nie z jakiegoś „ducha komunizmu”. Niektóre jednak były ucieleśnieniem idei państwa kontrolującego wszystko. Cepelia była czymś takim. Państwo zaczęło kontrolować coś co jest spontaniczne – twórczość ludową. To tak jak mówienie rzeźbiarzowi z Leska, że diabeł bieszczadzki ma mieć równe rogi.
We współczesnych korporacjach mamy do czynienia z podobnym podejściem do innowacyjności. Innowacyjność, a szerzej pomysłowość jest z natury swojej dość spontaniczna. Czasami jest wynikiem pracy, ale najczęściej objawia się w momencie gdy trzeba coś zrobić i nie za bardzo wiadomo jak. Tego nie da się wyłapać. Artysta tym różni się od rzemieślnika, że tworzy pod wpływem impulsu, a nie na rozkaz.
Firmy IT, a im większe tym silniej, mają dziwną tendencję do tworzenia mechanizmów kontrolujących pomysłowość. Często jest to bardzo komiczne, ponieważ przy okazji nieudanej „sesji pomysłowości” ludzie tworzą rozwiązania, które są na prawdę dobre, ale umykają „oficjalnej linii”, przez co albo trafiają do społeczności OS albo giną gdzieś w jakimś zapyziałym repozytorium CVS. Dodatkowo powoduje to frustrację twórców i zabija w nich poczucie misji.

Poszlaka ostatnia. Biznes stara się kontrolować rzeczy niepodlegające kontroli. Tworzy sobie złudne wrażenie, że ma na coś wpływ, a w praktyce tylko ogranicza rzeczywiste możliwości.

Podsumowanie

Jeżeli zapytasz programistę jaki kod jest dobry to usłyszysz coś w rodzaju opinii zamieszczonych na początku „Clean Code” wujka Boba.
Jeżeli zapytasz programistę dlaczego nie stosuje tego w praktyce to zapewne usłyszysz jakąś wariację wymienionych przeze mnie przyczyn. W różnej skali i sile, ale niosących ten sam sens.

Biznes zabija dobry kod ponieważ nie potrafi dostrzec wartości dodanej takiego kodu. Patrząc tylko przez pryzmat pieniędzy nie dostrzega, że dysponuje znacznie większymi zasobami, ale ich odpowiednie użycie nie jest tak proste jak w innych gałęziach przemysłu.

Smutne…

12 myśli na temat “Biznes – wróg dobrego kodu

  1. To wszystko w sporej mierze prawda i wiele z tego na codzień oglądam ale ja coraz mniej lubię to obciążanie biznesu winą za wszelkie zuo. Bo sam wiem, że często to ode mnie zależy, jakie w ogóle alternatywy dostaną do rozważania. A już mocno mnie wkurzają sytuacje, gdy najpierw programiści robią wrażenie niezbornych osób niezdolnych podjąć jakąkolwiek decyzję i wziąć za nią odpowiedzialność, czy choćby wyraźnie wyartykułować swój pogąd, a potem płaczą jak to ten czy inny nietechniczny zmusił ich do głupoty.

  2. @Mekk, ale takie zachowanie programistów ma pewne korzenie. Nie spotkałem się jeszcze z sytuacją by za fail projektu po łbie dostał manager. Zawsze dostają programiści. Jeżeli będą pyskować to może się to skończyć nie tylko odebraniem premii, ale i koniecznością aktualizacji CV…

  3. Trzeba po prostu uświadamiać biznes o Technical Debt. Aplikacja biznesowa zwykle wymaga utrzymywania i rozwoju. Jeżeli biznes tego nie uwzględnia, to w dłuższym terminie traci. Także spokojnie, prędzej czy później biznes to zrozumie 🙂

  4. @Paweł, ale biznes o tym wie. Tylko, nie potrafi zmienić sposobu myślenia o utrzymaniu. Niestety nadal traktuje się kod jak maszynę, którą wystarczy posmarować i pieprznąć młotkiem.

  5. Z tym failem bym nie przesadzał, jeśli jest poważny to po łbie dostają wszyscy którzy nie zdołają się wystornować. A programistom tak naprawdę bywa łatwiej przesiąść się gdzie indziej niż „menedżerom”, których wartość nieraz głównie w układach pobudowanych w instytucji.

    Między posłusznym robieniem głupot a pyskowaniem jest duża, duża warstwa pośrednia. I przynajmniej jeśli w biznesie pracują ludzie, którym ogólnie zależy na sukcesie firmy i projektów, to z czasem można budować odpowiednią świadomość. Gorzej gdy trafiasz na ludzi rozgrywających czysto taktyczne własne interesy ale w takim kontekście ciężko w ogóle rozmawiać o sensowności, celowości etc.

  6. „a z paczki tazosów staramy się wyciągnąć tego z kucykiem. Kucyka przykleimy na maskę”
    i
    „o kurwa… nawet silnik jest z tyłu!!!”

    Panie Koziołku, jest wać Pan zaiste satyrykiem wielkim a i zacnym.
    Nie mogę sobie wyobrazić jakie to procesy myślowe musiałby zajść w moim mózgu aby połączyć te tazosy z ferrari. Przekutaśnie!

    Co do jakości to drzewiej była ona wpisana w rzemiosło. Aktualnie mamy odrodzenie tej idei w postaci Software Crafsmanship. Ale to jednak nie to samo: różnica polega na tym, że rzemieślnik był sam sobie szefem. Natomiast w IT jest tak jak napisałeś.

  7. @Sławek S. a dziękuję. Jako, że moim ulubionym bohaterem literackim jest Zagłoba to metody pozyskiwania konceptu stosuję podobne tylko zgodne z przepisami prawa pracy 😀

    „rzemieślnik był sam sobie szefem” – co do tego się nie zgodzę. Rzemieślnik podlegał prawu cechowemu i miejskiemu. Ono wymuszało dbanie o jakość jak i ograniczało ilość. Dopiero później manufaktury i fabryki wykończyły to podejście.

  8. Tak, chodziło mi o to że nikt nie zmuszał go pracy poniżej standardów. Mało tego, jakieś minima była ustalone przez cechy, o których piszesz.

  9. @Sławek S, tru. Nie załapałem pierwszej myśli. Tylko, że zasadnicza różnica pomiędzy cechem, a firmą leży w osobie kadry. W cechu władze mieli, przynajmniej teoretycznie, wybrani rzemieślnicy – mistrzowie. Względnie starszym zostawał ktoś z nadania możnowładcy. W firmach jest to niestety rzadko spotykane by spec od IT awansował na poganiacza.

  10. Z tą „Nasza Kasa” to pojechałeś, nie dość że to był straszny chłam informatyczny (Pan Gąbka przy 20 userach) to raczej nie sądzę że jest ona w pierwszym milionie firm/incjatyw IT a napewno nie na miejscu numer 3 😉

  11. @pedro, http://www.idg.pl/news/328683/Nasza.klasa.w.pierwszej.dziesiatce.globalnych.top.wyszukan.Google.html NK to fenomen na skalę światową. Nie tylko ze względu na ilość użytkowników, ale też pewien wpływ na rynek. Zobacz, że dzięki niej „zinternetyzowało się” pokolenie naszych rodziców. Ciężko porównywać ją do Googla, ale jeżeli zobaczysz, że jej target jest bardzo ograniczony to proporcjonalnie FB jest nawet mniejszy… 11mln NK na 14mln internautów w PL i 500mln FB do około 1mld internautów na świecie.

    Poza tym NK miała w pewnym momencie problem z wydajnością ze względu na trochę skopany pomysł (w końcu to tylko magisterka!!!) w architekturze. Jest zbyt uzależniona od mySQLa, który przestał się skalować. Zresztą chłopaki zrobili kawał niezłej roboty przepisując część kodu mySQL na coś co działało. Dodatkowo chłopaki nie nadążali z dostawianiem serwerów. Taka operacja pochłania czas i pieniądze (o które było z tego co mówią twórcy na początku trudno).

Napisz odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax