Jakoś(ć) to będzie…

Ostatnio zdałem ostatni egzamin ustny z zarządzania jakością. Przy tej okazji miałem pewne przemyślenia co do jakości w naszych projektach. Tymi przemyśleniami dzielę się poniżej.

Dużo krzyczy się w ostatnim czasie o SOLID, o Clean Code, o Clean Architecture, DDD, TDD, XP i inne ciekawe skróty i skrótowce oraz angielskie słówka, które są zrozumiałe dla pewnej (oby większej) części programistów. Oprócz tych powyższych, będących głównie technicznymi sformułowaniami, mamy jeszcze Agile, Scrum, Kaizen, Lean. Te są bardziej stwierdzeniami typu „soft”, znanymi menegmentowi. 

Te stwierdzenia w pewnym sensie składają się na jakość. Składają w takim sensie, że obecne i dobrze wdrożone w organizacji pozwalają tę jakość wprowadzić i utrzymać. Niestety z moich obserwacji wynika, że to głównie programiści wołają o jakość, biznes zaś wydaje się być głuchy na ten krzyk. Spróbuję przyjrzeć się temu bliżej.

Czym jest ta mityczna jakość?

Dla programisty jakość to na pewno aplikacja, która jest podatna na rozwój, łatwo się utrzymuje, nie wymaga opieki 24 godziny na dobę, czyli jakichś nocnych dyżurów. Po prostu działa. Poza tym kod takiej aplikacji jest czytelny, nie trzeba wertować tysięcy linijek kodu, żeby cokolwiek usprawnić. Programista pracując przy kodzie wysokiej jakości nie będzie miał obaw, że jeżeli coś dotknie, to zepsuje pół aplikacji. Kod w końcu jest modularny i pokryty testami wzdłuż i wszerz. 

Problemem ludzi biznesu często jest to, że albo nie rozumieją czym jest jakość kodu i co daje, albo świadomie nie pozwalają o nią dbać, bo nie takie są priorytety, albo idą na znaczne kompromisy w tym temacie, bo devsi narzekają i trzeba im rzucić trochę mięsa. Nie żeby to tylko biznes był winny, o nie. Inna opcja, to też nieumiejętność programistów . Sądzę, że nie jednokrotnie programiści zaciągają dług techniczny „bo nie ma czasu zrobić teraz lepiej”, gdzie w wielu przypadkach jest to tylko wymówka, aby nie robić tego teraz. W ten sposób sami sobie i na własne życzenie, produkują piaskownicę z odchodami, w której potem się bawią. 

Programista pracuje
Programista jakby tu nie zepsuć…

Jakość jest vs jakości nie ma

Zastanówmy się jednak, co daje jakość. Jakość kodu, to mniej bugów i krytycznych problemów oraz dobrze zaimplementowana logika biznesowa. To sprowadza więcej użytkowników (klientów), a to oczywiście implikuje pieniążki, które można zainwestować w dalszy rozwój. A, że mamy wysokiej jakości skalowalny i rozszerzalny kod, nie ma problemu, aby inwestować w nowe funkcje. Co więcej, wszystko w dużo krótszym czasie, niż gdyby tej jakości nie było. Programiści są zadowoleni, chcą się rozwijać, dają o tym świadectwo na zewnątrz więc chętnych do pracy w firmie trochę jest. Klienci zadowoleni, programiści zadowoleni, management zadowolony. Mamy win-win.

Co jednak jak jakości nie ma. Kod jest kiepski, programiści źli, gubią się we własnym bałaganie. Motywacja leci na łeb na szyję, to powoduje sporą rotację. Ilość błędów jest duża, jeden powoduje drugi. Logika nie do końca działa jak trzeba, klienci się skarżą, składają dużą ilość reklamacji albo odstępują od zakupu. Firma traci pieniądze, bo klientów nie ma, a trzeba płacić programistom zamiast za rozwijanie, to za łatanie aplikacji. I tak w koło. Klienci wściekli, programiści wściekli, management wściekły. 

Ktoś może powiedzieć, że jak chce się dbać o jakość, to trzeba poświęcić temu dużo czasu, a co za tym idzie pieniędzy. Owszem. Jakość kosztuje. Ale tylko na początku. Wynika to z prostej zależności – na wdrożenie jakości trzeba poświecić czas na planowanie, dobre rozwiązania, przemyślenie szczegółów. Potem ten koszt znika, bo rozszerzanie aplikacji jest proste. Co więcej wdrożenie nowych programistów jest też dużo łatwiejsze!

Poza tym – ile kosztuje brak jakości? Niejednokrotnie czas developmentu wydłuża się wielokrotnie w stosunku do przemyślanego i dobrze napisanego systemu. Co to znaczy? Ano, że dostaniemy mniej nowych funkcjonalności bo trudniej je napisać a i trzeba błędy ponaprawiać w tak zwanym międzyczasie. Pamiętając, że godzina pracy programisty nie należy do najtańszych. Łatwo sobie wyobrazić, że w dłuższym okresie jakość może okazać się ogromną oszczędnością! Poza tym zmniejsza niezadowolenie developerów, czyli zmniejsza rotację, a to rzutuję na rekrutację. Zatrudnienie i wdrożenie nowego programisty to również koszty. 

A wy jakie macie przemyślenia na temat jakości?