Nie lenistwo, a strach. Prawdziwe źródło długu technicznego

Zaczynam mieć teorię co jest źródłem "prawdziwego długu technicznego". 

Nie chodzi o lenistwo, jako "za dużo roboty ze zrobieniem tego", a chodzi o chęć uniknięcia obciążenia poznawczego i "nie chce mi się o tym myśleć". 

Spojrzenie na problem, dostrzeżenie złożoności i świadoma decyzja o tym, że się rozwiąże mniej ogólny problem nie generuje długu technicznego jako takiego, to jest nadal tylko przycinanie scope'u.

Dług techniczny się bierze z udawania, że problemu nie ma, nadziej że jakoś to będzie.

Czym innym jest sytuacja która objawia się tak samo, czyli np. "mamy w bazie danych niezaszyfrowane credentiale do OAuth", bo raz powodem może być "bo tak było prościej", a innym "bo to upraszcza implementację i jak dojdziemy do dobrego mechanizmu rotowania kluczy to po prostu zmienimy kod tak by umiał działać z obecnym formatem rekordu i dodamy do odczytu kod który będzie robił update dla rekordów w starym formacie".

To jest jak z przechodzeniem ulicy w niedozwolonym miejsce ;-)
Inny przypadek jest gdy przechodzimy w niedozwolonym miejscu, ale się dokładnie rozglądamy (i to nie głównie za policjantem) i oceniamy ryzyko, a co innego gdy leziemy bez patrzenia. 
Takie świadome przejście w niedozwolonym miejscu jest nawet bezpieczniejsze niż bezkrytyczne zaufanie przejściu dla pieszych ;-)

Kluczem jest to, że decyzja powinna być świadoma. Wiemy czemu to robimy.

Chociaż trzeba przyznać, że ten świadomy dług techniczny też ma swoje wady, bo wiedza o tym czemu to tak zrobiliśmy, a nie inaczej staje się wiedzą instytucjonalną, która się trzyma w głowach osób zaangażowanych, może czasem w ticketach albo commit message'u, jak developer był lub była bardzo ostrożny/ostrożna to może być komentarz w kodzie czemu tak to robimy (chociaż na 100% na code review ktoś się do tego przyczepi, bo to przecież łamie zasady ;-)), więc z czasem się rozpłynie i zniknie. 

A Product ma krótką pamięć do takich rzeczy.
Sam pamiętam przypadek gdy na krótko przed produkcją okazało się, że "oj, jest problem" (Internet Explorer + DLL + działanie w jednym procesie + ActiveX i parę innych) i trzeba było zrobić workaround... który działał, chociaż to było zrobione z info do Product Managementu, że robimy hacka, ale trzeba tutaj popchnąć sprawę od strony produktowej i rozwiązać root cause... i po roku PMowie nawet nie wiedzieli, że jest ten problem ;-)

Chociaż i na to jest sposób, ale trudny, bo trzeba kilka razy zaimplementować w kodzie wyraźnie obsługę rzeczy, które urosły... W sensie jak w kodzie są już miejsca gdzie np. odczyta z bazy danych jest w stanie czytać kilka formatów rekordu to developer tam kiedyś dotrze i ustawi to ją lub jego na odpowiedni sposób myślenia (choć będą tacy, którzy będą chcieli "to przepisać bo to jest dług techniczny", co jest IMHO tylko powrotem do "square one" czyli "to jest zbyt skomplikowane by o tym myśleć").
Inaczej mówiąc jak w kodzie widać, że kod ewoluuje to zespół pracujący z kodem powinien mieć odpowiedni mindset. Wtedy np. zaczynasz widzieć, że np. enumy są świetne, do czasu jak przychodzą do Ciebie w JSONie i nagle masz zależność do schemy (której nie ma, bo schema dla JSONa to też tylko hack) i okazuje się, że może warto ten cały schemat patrzenia na kod jako coś co ewoluuje przenieść też od razu na dane.

Podobne posty^beta
2011 zaczęty ;-)
Spóźnialskie Google Latitude ;-)
Idioci
W tworzeniu softu droga od tego jak jest do tego jak ma być jest ważniejsza od tego jak ma być
Cukierki, radosny chaos i takie tam, czyli Przemkowe rojenia ;-)