13 lut 2009

Jakość nie ma znaczenia

Ostatnio wśród speców od programowania rozgorzała dyskusja nad jakością kodu/designu versus czas rozwijania.  Rozpoczął ją Joel Spolsky wypuszczając podcast w którym pada zdanie: 
And I find, sadly, to be completely honest with everybody listening, quality really doesn't matter that much, in the big scheme of things...
W tym samym podcast'cie Joel mówi tak:
Last week I was listening to a podcast on Hanselminutes, with Robert Martin talking about the SOLID principles. (...)It's object-oriented design, and they're calling it agile design, which it really, really isn't. It's principles for how to design your classes, and how they should work. And, when I was listening to them, they all sounded to me like extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code, frankly.
No więc co znaczy agile w kontekście oprogramowania? Mniej więcej to samo co w kontekście prowadzenia projektów: reagowanie na zmiany. I z tego punktu widzenia zasady SOLID (o których było parę postów temu) są bardzo zwinne, bo pozwalają z dużo większą łatwością dodawać nowe funkcje do systemu i modyfikować istniejące. Nie bardzo wiem z czym można tu dyskutować. Programowanie które nie jest w tym sensie "biurokratyczne" to programowanie chaotyczne. 
A mówienie o Robercie C. Martinie, Martinie Fowlerze, Kencie Becku i innych ludziach stojących za zwinnością w sensie technologicznym, że nie napisali wiele kodu jest po prostu żenujące.


Pierwszy cytat dotyczący jakości to jasny dowód na to, że jego autor jest PMem...  Dba o TEN projekt, o TĘ kasę, o TE terminy. Dług techniczny zaciągnięty w tym czasie nie jest dla niego ważny, bo przecież później się to posprząta.  Z resztą ten cytat mówi sam za siebie:
The way real software works is that you create these very imperfect things, and they work great. They really do. And then you have a little problem, and you go and you fix the little problem, because it's code, and you have an editor, and you edit it. 
Taaak. Przykładów oprogramowania, które works great jest faktycznie wiele... 
Dług techniczny nazbierany przez lata powoduje, że właśnie nie da się po prostu otworzyć edytora i poprawić kodu. Z resztą zwrot little problem też pokazuje nastawienie pana Spolsky'ego. No ale on robi soft do rejestrowania błędów, więc zależy mu na tym, żeby było ich jak najwięcej - wtedy więcej kopii sprzeda :)

Straszne, że ktoś tak wpływowy w świecie oprogramowania pisze takie rzeczy.


Takie krótkowzroczne spojrzenie jest ze stratą dla wszystkich. Programiści się frustrują i nie chcą potem pracować z takim kodem. Klient dostaje coraz dłuższe terminy (a więc i większe kwoty), albo te co są są niedotrzymywane. PM ma zmarnowane życie prywatne i wrzody żołądka (choć na to to akurat sobie zasłużył :)). 
Jedną z podstawowych wartości ruchu agile jest transparentność i szczerość. I dotyczy to procesów (wiadomo kto, co i kiedy robi), efektów (ukończonych zadań), kosztów. Ale mało kto mówi, że dotyczy to również kodu. I to nie tylko w zespole programistów. Kto informuje swojego klienta o powstającym na skutek jego presji długu technicznym? Kto mówi, że żeby robić release'y na czas wprowadził do systemu taki shit, że robienie nowych funkcjonalności zajmie 20% czasu więcej (a więc 20% więcej będzie kosztować, co może przekona klienta)?
Odpowiedzialny zaspół zgłasza swojemu Product Owner'owi (a ten klientowi) informacje o wpływie jego decyzji na jakość. Jakość jest wartością biznesową a nie techniczną i jako taka powinna być uświadamiana klientowi. Jeśli twój PM nie pozwala Ci dbać odpowiednio o jakość (ciśnie terminami, siedzisz po godzinach, nie testujesz kodu itp.) to działa na szkodę klienta (to on ostatecznie dostanie shit) i na szkodę Twojej firmy. Warto więc uświadamiać w tym zakresie osoby niezaangażowane bezpośrednio w projekt, a mogące podejmować decyzje.

1 komentarz:

Paweł Szulc pisze...

Czesc Pawel, tu Pawel :) a na potwierdzenie twoich slow wpis innego Pawla ktory tylko potwierdza towjego posta

http://pbadenski.blogspot.com/2009/02/joel-i-jeff-czyli-o-dwoch-takich-co.html

polecam kazdemu kor zaintrygowal sie tym postem

Joel przeraza mnie czasami, bo takich postow jest coraz wiecej