blog.testowka.pl

Dług technologiczny

opublikowany przez 14, Lip, 2011, w kategoriach Agile, Automatyzacja, Testowanie

„Blog o jakości oprogramowania” – chyba łatwiej mi się pisze ostatnio o brakach w jakości oprogramowania niż o samej jakości.

Rozwój oprogramowania to bardzo złożony proces, na który wpływ ma wiele czynników, jednym z najważniejszych są szeroko rozumiane wymagania biznesowe. Wiadomo, jeśli nie wiadomo o co chodzi to pieniądze – po coś oprogramowanie się tworzy i przeważnie robi się to właśnie dla pieniędzy (nawet oprogramowanie Open Source jest w pewnym sensie tworzone dla pieniędzy, w mniej lub bardzie pośredni sposób ktoś na tym zawsze zarabia). W większości przypadków to tak zwany „Biznes” steruje rozwojem oprogramowania (w odpowiedzi na właśnie takie zapotrzebowanie powstały zwinne metodyki wytwarzania oprogramowania – by Biznes mógł jeszcze częściej i szybciej reagować na zmiany rynkowe). Niestety często bywa tak, że presja ze strony Biznesu jest na tyle duża, że zapomina się o tym by o wspomnianą na początku tej notki jakość dbać. Tworzy się nowe funkcjonalności zapominając o pisaniu testów, dokumentacji, refactoringu, odpowiednim projektowaniu etc. bo przecież nie ma na to czasu, liczy się tylko zwielokrotnianie zysków, dodawanie wartości do oprogramowania (testów, dokumentacji, projektowania nie da się w żaden sposób przeliczyć na wymierne korzyści finansowe) – w ten właśnie sposób tworzy się coś co nazywamy Długiem Technicznym (albo Długiem Technologicznym). Dług Techniczny (Technical Debt) swoją nazwę zawdzięcza podobieństwu do zwykłej pożyczki zaciągniętej w banku. Każdy pominięty test, nieudokumentowany ficzer, dodanie czegoś ad-hoc – bez odpowiedniego zaprojektowania prowadzi do obniżenia ogólnie pojętej jakości projektu, co w rezultacie prowadzi do widocznego spowolnienia rozwoju prac nad projektem.

Pozwolę sobie przytoczyć cytat z pewnego CTO, z którym miałem okazję kiedyś porozmawiać nt. jakości oprogramowania wytwarzanego przez podległych mu programistów: „Rok temu pracowaliśmy kilka razy szybciej, teraz wszystko jakby spowolniło – prawdopodobnie programiści się rozleniwili”. Wspomniany dyrektor był zdenerwowany tym, że rok wcześniej główny projekt firmy rozwijał się 6 razy szybciej niż obecnie. Domniemana przyczyną było „rozleniwienie programistów”,  którzy poczuli się zbyt bezpiecznie na swoich pozycjach – „przecież z tej firmy jeszcze nikogo nie zwolnili”. W odpowiedzi na domysły tego pana zadałem kilka pytań w stylu: Czy piszecie testy jednostkowe? Czy mierzycie pokrycie kodu testami? Jak wygląda wasza dokumentacja? Jak wyglądają wasze środowiska testowe? Czy możecie mi pokazać projekt architektury waszych aplikacji? etc… Na większość z tych pytań odpowiedź była negatywna (w sensie „nie, nie mamy czegoś takiego”). Przyczyną takiego stanu rzeczy była duża presja ze strony klientów, którzy wymagali jak najszybszych dostaw nowych ficzerów w celu zwiększenia zysków (co zresztą udawało im się przez dłuższy czas całkiem nieźle). Niestety nacisk tylko na wytwarzanie wartości biznesowej spowodował zanik takich praktyk jak testowanie, pisanie dokumentacji, czy nawet projektowanie – wszystko działo się ad-hoc, bez planu i spójnej wizji. W ten oto sposób powstał Dług Technologiczny, którego efektem było spowolnienie pracy. Nie wspomnę już o tym, że 80% czasu zajmowało łatanie dziur i naprawianie bugów.

Nazwa „Dług” nawiązująca do kredytu bankowego jest jak najbardziej adekwatna. Wyobraźmy sobie sytuacje w której w celu rozbudowania naszego przedsiębiorstwa i zwiększenie jego zysków zaciągamy kredyt w banku. Za uzyskane w ten sposób pieniądze inwestujemy w nowe maszyny, czy też zatrudniamy więcej ludzi co w pewnym stopniu zwiększa nasze zyski. Po jakimś czasie decydujemy się na jeszcze większe rozbudowanie naszego przedsiębiorstwa, więc bierzemy kolejny kredyt. Znowu zyski rosną. Robimy tak jeszcze kilka razy i nagle okazuje się, że owszem – mamy całkiem pokaźne przychody, ale większość zysków konsumują odsetki z zaciągniętych kredytów.

Sama świadomość tego, że taki dług zaciągamy jest już całkiem pozytywna – jeśli tylko WSZYSCY zdają sobie sprawę z konsekwencji takich a nie innych decyzji. Niestety z moich obserwacji wynika, że w większości organizacji z którymi miałem do czynienia ludzie nie mają pojęcia o czymś takim jak Technical Debt, lub nawet jeśli coś o tym, kiedyś słyszeli to nie potrafią wskazać u siebie miejsc w których taki dług jest zaciągany. Prawdę powiedziawszy to w każdej, nawet najlepiej zorganizowanej firmie zawsze znajdą się miejsca, w których w jakimś stopniu taki dług się nawarstwia.

Podobnie jak normalny kredyt, także Dług Techniczny trzeba w końcu spłacić. O tym jak można to robić napiszę następnym razem.


2 Comments for this entry

  • chroom

    Z tą spłatą to nie koniecznie. Podejrzewam że często kierownicy liczą na ‚umorzenie’ długu poprzez akceptacje projektu przez klienta i zakończenie w tym momencie wszelkich prac (i kosztów). W sytuacji kiedy dalszy rozwój systemu jest niewiadomą, spłacanie długu nie jest biznesowo opłacalne.

  • streser

    @chroom Z punktu widzenia zewnętrznego podwykonawcy jak najbardziej zgadzam się – można liczyć na umorzenie wraz z zakończeniem kontraktu. jest to jedna z wielu poważnych (z punktu widzenia klienta) wad kontraktów fixed price/budget/scope.

    W zasadzie ciężko mi jest sobie wyobrazić w dzisiejszych czasach produkt, który nie będzie dalej rozwijany i zmieniany. Bez zmian i reakcji na potrzeby rynku za chwilę znajdzie się ktoś, kto skopiuje nasze rozwiązanie i zrobi je lepiej oraz taniej. Klienci uciekną do konkurencji.

    Jedyną sytuacją która przychodzi mi do głowy, w której to co napisałeś ma prawo zaistnieć są niektórzy klienci instytucjonalni, państwowi – w naszym kraju niestety dalej świadomość w tych instytucjach jest dosyć niska. Na świecie powoli się to zmienia. Np. w kilku resortach rządowych w skandynawskich krajach w przetargach publicznych wymagana jest praca inkrementalna i przetargi te nie mają z góry określonego budżetu – jest przetarg na stawkę za iterację i określony zakres minimalny, który powinien się w niej znaleźć. Zwycięzca przetargu gwarantuje dalszy support i rozwój produktu więc w jego interesie jest także zrobienie tego jak najlepiej.

    Projekty informatyczne, które miały jakikolwiek koniec odchodzą do lamusa…

    Oprócz długu technicznego istnieje coś takiego jak dług technologiczny (o którym wkrótce napiszę więcej), który narzuca konieczność stałego i nieustannego rozwoju oprogramowania – rozwój przeglądarek internetowych, czy systemów operacyjnych oraz ich niekompatybilność wstecz jest tutaj dobrym przykładem. Pamiętasz „tryb zgodności” z Win XP? To właśnie była próba obejścia tego problemu…

2 Trackbacks / Pingbacks for this entry

Skomentuj