Z tematu dług technologiczny zrobił się całkiem spory cykl. Mimo, że nie wszystkie aspekty zostały poruszone, to myślę, że poruszone zostały wszystkie najważniejsze jego aspekty zatem nadszedł czas na odpowiedzenie sobie czy da się realizować projekty bez długu.
Odpowiedź krótka brzmi NIE.
Jeśli w każdym aspekcie będziemy korzystali z wszystkiego NAJ to przy dzisiejszym tempie rozwoju okaże się, że nie robimy nic oprócz zmian wersji narzędzi, bibliotek, framework-ów, wrzucaniu coraz to nowych lepszych języków i innych tego typu wynalazków. Projekt sam w sobie nie będzie szedł za bardzo do przodu – o ile w ogóle. Cała sztuka z długiem technologicznym polega na tym, że po pierwsze primo MUSIMY być świadomi takiego zjawiska a po drugie primo MUSIMY nim jakoś rozsądnie zarządzać. Tak jak banki zarządzają długiem, tak jak kraje zarządzają długiem tak i my programiści powinniśmy zarządzać swoimi długami.
Nie wszystko co najlepsze na rynku możemy wykorzystać, podstawowy hamulec to nasi klienci. Jeśli kilku strategicznych klientów korzysta ze starych systemów operacyjnych, na których nasze nowe zabawki nie będą działać to chcąc nie chcąc nie przeskoczymy tego.
Jeśli goni nas termin (czy to prezentacji czy wdrożenia czy też po prostu kończą się pieniądze na projekt) to nie ma sensu wrzucać nowych wynalazków.
Jeśli nie mamy odpowiednich ludzi, którzy są wstanie w miarę rozsądnie rozpoznać nową technologię, to nie ma sensu w nią wchodzić.
W każdym momencie projektu warto natomiast wiedzieć gdzie jesteśmy do tyłu i wiedzieć dlaczego. W każdej chwili powinniśmy być również przygotowani na zmianę jeśli znikną nasze hamulce.
W przypadku bibliotek zewnętrznych i kontrolek oraz wszelkich kanałów komunikacji (programu) ze światem zewnętrznym wydaje się idealnie sprawdzać architektura a ’la Robert Martin. Mianowicie, co nie zależy w 100% od nas powinno być odizolowane – zapakowane w odpowiednie pudełko. To pozwoli nam zmienić zawartość tych pudełek w sytuacji gdy elementy blokujące nas znikną. Myślę, że zarówno nasz klient jak i kierownik czy prezes będą woleli usłyszeć że wymiana bazę danych na inną będzie wymagała miesiąca pracy zamiast 2 lat – lub w skrajnej sytuacji przerobienia całego projektu od nowa.
Wiedza o długu pozwala nam również go zaciągać świadomie. Moim zdaniem nie wolno, pod karą chłosty klawiaturami, iść na skróty w częściach korowych systemu ale już w detalach np. interfejsu użytkownika (KTÓRY NIE POSIADA LOGIKI APLIKACJI I LOGIKI BIZNESOWEJ!!!), możemy sobie czasem pozwolić na gorszą jakość. Pójście na skróty w pierwszym przypadku będzie miało brzemienne skutki dla całego systemu, w drugim bardziej lokalne. Jeśli w obu sytuacjach pójście na skróty oznacza zysk 5h to gdzie lepiej zostawić małe lokalne piekiełko?
Od tej pory bardziej świadomi powinniśmy podejmować bardziej świadome decyzje. Jeśli macie jakieś przemyślenia na ten temat, zapraszam do dyskusji.
