Dyktat Business Case

Przeczytałem niedawno artykuł Zasada skautów. Nie jestem programistą, ale obserwuję takowych oraz całą otoczkę związaną z wprowadzaniem zmian w systemach. Artykuł proponuje, aby programiści stosowali zasadę zawsze zostawiaj kod czystszym niż go zastałeś. Udoskonalenia mogą być drobne, ale tak jak skumulowane przez lata drobne niedoskonałości doprowadzają do erozji kodu, tak skumulowane przez lata drobne usprawnienia mogą wydźwignąć kod z bagna.

Do umieszczenia tego wpisu zainspirowały mnie komentarze pod artykułem, że tego typu podejście w realnym świecie bywa niemożliwe do zastosowania. Zupełnie się z tym zgadzam albowiem obserwuję zjawisko, które nazwałem roboczo dyktatem business case'u (BC).

W firmach skupionych na działalności biznesowej, dla których IT pełni rolę służebną, nie dewelopuje się dla przyjemności, tylko do zaspokojenia określonych potrzeb biznesowych organizacji. Decyzja o wykonaniu lub nie określonej zmiany podejmowana jest po analizie BC przez zarządzających, bywa że najwyższego szczebla (zależnie od budżetu). Na tym poziomie nikt nie wnika, czy kod jest ładny. Na słupku w arkuszu kalkulacyjnym widzimy, że wydamy kwotę X i uzyskamy z tego tytułu przychody albo oszczędności na kwotę Y w horyzoncie k-letnim - to jest coś, co przemawia.

Problem jest taki, że istnieją rzeczy, które inżynier uważa za stosowne by je wykonać, ale bardzo trudno biznesowo uzasadnić związane z tym koszty. Dokumentacja, refaktoryzacja pewnych części, przeprojektowanie API, lepsze walidacje, większa uniwersalność, lepsza integracja z systemem operacyjnym, czytelniejsze logi, itd. - z punktu widzenia użytkownika biznesowego to mogą być rzeczy "mało ważne", "ryzykowne dla harmonogramu", "możliwe do realizacji w terminie późniejszym", "na inny projekt".

I rzeczywiście jest tak, że nie powstają rozwiązania dobre, tylko wystarczająco dobre. Nie obsługują niektórych specyficznych przypadków i trzeba dane poprawiać ręcznie (tańsze to niż poprawka aplikacji). Wymagają restartu co noc (akceptowalne, w nocy nie pracujemy). Mają SQL injection (ale używają ją tylko zaufani pracownicy, którzy prawdopodobnie tego nigdy nie odkryją). Działa przy zbyt dużych uprawnieniach (ale działa, a mogłaby nie działać). Ma bardzo niestandardowe skrypty uruchamiające (uczulimy administratorów). Loguje pełno śmieci i rzuca wyjątkami na lewo i prawo (dyski są tanie). Konsumuje duże zasoby (RAM jest tani). Ale za to było połowę tańsze, dzięki czemu BC w ogóle się spiął. Z punktu widzenia klienta biznesowego to może być wręcz pełny sukces.

Te drobiazgi kumulują się w czasie, a niesmak z pracy z kodem rośnie. Rośnie również kulka hacków i workaroundów, ale póki to jakoś istotnie finansowo nie uderzy w organizację (system stanie się krwiobiegiem organizacji i zacznie być blokerem jej rozwoju ze względu na trudność wprowadzania zmian), wszyscy będą z tym żyli pchając całość do przodu. Może to trwać wiele, wiele lat...

Update - w pewien sposób ilustracja tego o czym piszę ;) Brytyjski rząd: Internet Explorer 6 jest wystarczająco bezpieczny.