Rosnący dług techniczny w małych indyjskich firmach tworzących aplikacje i strony internetowe: kto jest za to odpowiedzialny?

Jestem w indyjskiej branży usług oprogramowania od 10 lat i przez cały ten czas widziałem, jak powstają dobre projekty i robią cuda. Widziałem zespoły szkieletów, które niestrudzenie pracują w trudnych warunkach, aby tworzyć produkty, które pokochali ludzie z drugiej połowy planety. I chociaż w tej dekadzie miałem wspaniałe wspomnienia, pracując nad kilkoma wspaniałymi projektami, byłem również świadkiem, jak projekty spadają, a produkty programowe zawodzą z różnych powodów. Zdarzyło się to więcej razy, niż bym sobie życzył wokół mnie i ludzi, których znałem przez te 10 lat.

Dużo mówiło się o projektach, które kończą się niepowodzeniem. Memy roją się w Internecie, jak cała hierarchia goni się nawzajem jak łańcuch pokarmowy w dżungli. Niektórzy obwiniają programistów za pisanie błędnego kodu, podczas gdy inni przeklinają kierownictwo za składanie niepraktycznych obietnic, których nie można spełnić. Niektórzy nawet obwiniają klientów za niezrozumienie technicznych warunków i zależności tej branży. Ale nie słyszałem prawie nikogo, kto mówił o długu technicznym lub długu Code Debt i radził sobie z tym problemem w cywilizowany sposób, bez wskazywania na siebie nawzajem palcami. Ani razu nie natknąłem się na ten termin Tech Debt od ludzi wokół mnie, z wydarzeń, w których uczestniczyłem, lub z lokalnych blogów, które czytałem.

Natknąłem się na ten termin, kiedy czytałem blogi i czasopisma z Doliny Krzemowej w Stanach Zjednoczonych. Oznacza to, że większość programistów i kierowników ds. oprogramowania pracujących w małych i średnich firmach programistycznych w Indiach do tej pory nawet nie słyszała o tym określeniu. Zacznę więc od wyjaśnienia samego terminu. Technical Debt lub Code Debt to koncepcja w tworzeniu oprogramowania, która odzwierciedla zakładany koszt dodatkowej przeróbki spowodowany wyborem łatwego (ograniczonego) rozwiązania teraz, zamiast stosowania lepszego podejścia, które zajęłoby więcej czasu.

Pozwól, że opiszę to, aby było to proste. Jest to koncepcja polegająca na obliczeniu kosztu rozwiązania problemów programistycznych i projektowych, które mogły powstać z powodu wyboru łatwej opcji zbudowania konkretnego modułu lub całego systemu, zamiast wyboru najlepszej i najbardziej efektywnej metody jego budowy. W dziedzinie tworzenia oprogramowania zjawisko lenistwa i opieszałości powracających, by ugryźć cię w tyłek, zdarza się znacznie częściej niż gdziekolwiek indziej. To prawie tak, jakby Karma otrzymała społeczną reprezentację bycia wredną przez programistów.

Proszę, nie zrozum mnie źle, nie obwiniam programistów za cały dług kodowy. Z pewnością istnieje wiele podmiotów, które są odpowiedzialne za zadłużenie kodu, które z pewnością pojawia się w ponad 90% projektów w małych firmach programistycznych w Indiach. Spróbuję krótko omówić kilka z nich:

1. KLIENCI NIECIERPLIWI I PRZEMYŚLNI

Tak, zacznę od ugryzienia samej ręki, która się karmi i zrobię to bezlitośnie. Rynek małych projektów outsourcingu rozwoju oprogramowania jest ogromny i bardzo rozdrobniony. Istnieją naprawdę dobre firmy, które doskonale usprawiedliwiają ten zglobalizowany rynek, podczas gdy inne są po prostu pasożytniczymi firmami, które żywią się tym doskonale dobrym układem tylko dlatego, że jest nieuregulowany i niekontrolowany.

Prowadzi to klientów do popełnienia błędu przy wyborze odpowiedniej firmy do współpracy w oparciu o ich potrzeby. Chociaż brak odpowiednich umiejętności weryfikacyjnych nie jest ich winą, nie można winić ich za to, że nie mają podstawowej sprytu ulicznego w identyfikowaniu firmy śmieciarskiej z autentyczną. Teraz, gdy zgodzą się na kontynuowanie pracy z niedostatecznie utalentowanym zespołem, dławią się swoimi nierealistycznymi oczekiwaniami i harmonogramem. Mało tego, niektórzy z nich nawet przesadzają i pokazują, jak sprytni są, przynosząc własne sugestie w zakresie projektowania i programowania. (#notallclients )

Jeśli kiedykolwiek jesteś klientem firmy zajmującej się tworzeniem oprogramowania, pokornie proszę, abyś pozwolił im być i pozwolił im wykonywać swoją pracę. Spróbuj udać się do lekarza lub prawnika i powiedz im, co wygooglowałeś i co powiedział o twoim problemie, i zobacz reakcję na ich twarzach. Żaden ekspert w swoich dziedzinach nie lubi, gdy noob doradza mu w swojej dziedzinie. Inżynierowie oprogramowania nie są wyjątkiem.

Jeśli znajdziesz dobry zespół programistów, który wydaje się obiecujący, daj mu miejsce, a nie będzie miał ochoty iść na skróty, co skutkowałoby zmniejszeniem zadłużenia kodu w Twoim projekcie. I zgadnij co, przez większość czasu to wy, klienci, którzy spłacają ten kod długu. Słyszałeś kiedyś słowa: „Prośba o zmianę”? Założę się, że większość z was ma! W idealnym scenariuszu nigdy nie powinieneś słyszeć tych słów w swoim życiu. Ale to rzadko się zdarza. I najczęściej słyszysz te słowa, tym bardziej schrzaniłeś, będąc klientem firmy programistycznej.

2. LENIWI I PRZEBIEGNI MENEDŻEROWIE

Kiedy mówię tutaj o menedżerach, to każdy, kto zajmuje stanowisko zarządzania projektami ze strony firmy programistycznej. Czy to kierownik projektu, kierownik zespołu, kierownik ds. dostaw, czy właściciel firmy, jeśli kiedykolwiek próbowałeś szybko umyć ręce przy projekcie, tylko po to, by go zamknąć i odebrać płatność, jesteś imprezą również winić za ten dług technologiczny w swoich projektach.

Chociaż najsmutniejsze jest to, że nigdy nie macie płacić za wysoki dług technologiczny. Albo to klient płaci za to, używając produktu niespełniającego norm, albo płacąc więcej pieniędzy za jego wyczyszczenie. A jeśli nie jest to klient, to biedni programiści płacą za to, pracując nieskończenie wiele godzin poza tym, do czego są zobowiązani. Ale prawie nigdy nie są to ci średni faceci, dlatego według mnie powinni być najbardziej odpowiedzialnymi podmiotami w tym temacie zadłużenia technologicznego.

Jeśli kiedykolwiek zatrudniasz jednego z nich, największą cechą, jaką powinni mieć, jest moralność. Jeśli ich kompas moralny wskazuje właściwy kierunek, wezmą na siebie odpowiedzialność i podejmą właściwą decyzję na korzyść projektu, co ostatecznie doprowadzi do zmniejszenia kompilacji zadłużenia technologicznego. Przypomina mi to słynny cytat Jacka Ma, w którym mówił o wyborze pracy dla właściwego lidera. Bardzo trafny w tym scenariuszu tutaj.

3. PROGRAMATORZY

O tak, nie kończyłbym tego tematu obwiniając was też! Ale hej, #notallprogrammers, prawda? No tak, ale prawie 94% programistów. Przynajmniej tak myśli CP Gurani, dyrektor generalny Tech Mahindra, kiedy kilka lat temu dokonał szokującego odkrycia, że ​​94% absolwentów IT nie nadaje się do tej pracy. Nie wiem dokładnie, w jaki sposób doszedł do tej liczby, ale będąc produktem indyjskich uczelni inżynieryjnych i będąc świadkiem całego ekosystemu inżynierii IT przez ostatnie 10 lat, mogę powiedzieć, że zwykle zgadzam się z tym, co powiedział pan Gurani.

Nie próbuję dyskutować, czy jest to 94%, 90%, czy 80%. Ale żeby dać wam analogię, prawie każdy z nas wie, że potrzebujemy mąki, wody i szczypty soli do zrobienia ciasta i wałka do ciasta, aby zrobić czapati. Ale bardzo niewielu z nas potrafi zrobić jadalne chapati. Jest to śmiertelnie prosty proces, ale nadal wymaga odrobiny talentu i mnóstwa praktyki, aby się w nim osiągnąć. To samo dotyczy programowania. Wszyscy znamy przepis, ale bardzo niewielu faktycznie zakasało rękawy, ubrudziło sobie ręce i ćwiczyło to tak długo, jak opanowanie tego rzemiosła.

Dlatego nawet gdy przeciętny programista otrzymuje zlecenie na projekt, nieświadomie pisałby kod z wbudowanym długiem technologicznym, z którego nie zdawał sobie sprawy dopiero później. A jeśli zastanawiasz się, w jaki sposób branża ogólnie funkcjonuje pozytywnie, gdy większość programistów nie nadaje się do pracy, to jest to spowodowane ich skutecznymi menedżerami i doświadczonymi seniorami, którzy nauczyli się rzeczy na własnej skórze. Pomagają tym świeżym rękom i umysłom w poruszaniu się po zdradliwych ścieżkach pisania optymalnego kodu i sprawiają, że wysyłka projektu jest możliwa i wolna od obciążającego długu. I w końcu po odpowiednim przygotowaniu i przeszkoleniu tych nowicjuszy, aby stać się dobrymi w swojej pracy, lub w końcu licytują się z branżą IT.

Podsumowując, uważam, że wszystkie 3 główne strony tej współpracy ponoszą winę za kompilację długu kodowego. Ponownie, nie traktuj tego fragmentu jako elementu usuwającego wszystko, co jest nie tak z branżą. Jest jak każda inna branża na świecie, ze sporym udziałem horrorów i bohaterów. Nawet po 10 latach robienia tego nadal nie zrobiłbym nic innego ze swoim życiem. Uwielbiam tę pracę, uwielbiam być małą firmą pracującą nad ekscytującymi projektami od klientów na całym świecie.

Celem było uczynienie wszystkich 3 interesariuszy bardziej odpowiedzialnymi i zaznajomienie ich z tą podstawową stratą miękką, która spadła na nich przez niewłaściwą współpracę. Jeśli zespół programistów chce dokładnie obliczyć i zmierzyć swój dług technologiczny, może postępować zgodnie ze ścisłym modelem procesu opartym na metodologii Agile, a nawet metodologii Waterfall. Stosując się do tego zdyscyplinowanego podejścia, będziesz w stanie oznaczyć te sprinty weryfikacyjne i naprawcze osobno, a na końcu fazy będziesz w stanie dokładnie obliczyć, ile z nich potrzebujesz, i łatwo przejść do powód tego.

Zakończę to tym końcowym cytatem Samuela Becketta: