Уорд Кънингам измисли „метафората за „техническия дълг““. Звучи правдоподобно, може да резонира с ръководството. Но е далеч от реалността.
Нека помислим за финансовия дълг за момент. Как се задлъжнявате?
- С финансовия дълг е кристално яснокога ще влезете в него. Отиваш в банка и искаш пари. Това е много ясен момент в живота ви.
- Сумата на парите, която дължите на някого, е кристално ясна за вас и кредитора.
- Колко плащате за кредит, неговата цена е кристално ясна за вас и кредитора. Ако искате да получите заем от $10 000, ще трябва да върнете повече от това в зависимост от лихвения процент и времето, което ще ви отнеме за изплащане.
- Финансовият дълг идва с много конкретен план за това как да бъде изплатен, график за изплащане.
- Кредиторът много желае да получи парите си обратно, включително пълното лихвено плащане.
Мартин Фаулър видя основния проблем с техническия дълг в неговите „„парализиращи лихвени плащания““:
Прекалено често срещаният проблем е, че организациите за развитие позволяват дълговете им да излязат извън контрол и изразходват по-голямата част от бъдещите си усилия за развитие, плащайки осакатяващи лихви.
Но какво ще стане, ако изобщо няма дълг? Ами ако метафората е грешна?
Моля, проверете горните твърдения относно финансовия дълг спрямо реалността на софтуерните проекти:
- Знаете ли кога точно изпадате в „технически дълг“? Отивате ли при някоя кредиторка и я молите за „срочен заем“? (Тъй като техническият дълг е крайно време. Искате време да направите B сега, вместо да направите A, което би било „правилното“ нещо да направите.)
- Знаете ли точно колко сте задлъжнели, колко голям е срочният заем, който получавате от някой кредитор? (Кой все пак е кредиторът? Клиентът, архитектът, някой мениджър?)
- Знаете ли колко плащате за заема? Да кажем, че имате кредит от 2 дни, за да направите B сега, вместо да го направите по-късно и да направите A сега. Колко време ще отделите в бъдеще, когато се върнете към А, за да направите това, което сте отложили? Ще използвате ли само 2 дни или тогава ще бъдат 2,5 или 3 или 5 дни? Трябва да възстановите психическото състояние, трябва да се справите с по-еволюирали структури... И така, колко време още ще отнеме?
- Знаете ли как точно да изплатите „технически дълг“ в бъдеще? Знаете ли кога ще започнете да изплащате, имате ли график за изплащане?
- Кредиторът, от когото сте получили срочния заем, има ли голям интерес да върнете дълга? Връща ли се при вас и иска ли изплащане, както клиентът иска рефакторинг, който сте отложили преди два месеца?
Помислете за момент върху вашите отговори на тези въпроси...
Мога да ви кажа какво виждам в проектите. Виждам само Не като отговор. На всеки един въпрос трябва да се отговори с Не от онези хора, които обикновено говорят за „технически дълг“.
Никой не въвежда съзнателно „технически дълг“, никой не знае сумата му, никой не знае разходите по заема, никой няма график за изплащане и кредиторът не е много заинтересован да получи изплащане.
„Техническият дълг“ споделя само един атрибут с „финансовия дълг“: някакъв вид лихва — и то дори с неизвестен процент. Но това е всичко
Това е реалността на „техническия дълг“. И затова казвам, че няма такова нещо като „технически дълг“, защото никой не третира „да направиш Б сега, вместо да направиш „правилното нещо“ А“ като дълг, който трябва да бъде изплатен.
Става дума за пристрастяване, глупако!
След като метафората за „техническия дълг“ изчезна, какво друго би могло да бъде по-подходящо?
Съжалявам, но според мен остава само едно обяснение за това, което се случва в софтуерните проекти, които постоянно водят по пътя към изоставените индустриални зони. Трябва да се изправим пред него. Начинът, по който се правят проекти, е подобен на начина, по който живеят наркоманите. Трябва да говорим за пристрастяването.
Ето моето просто неспециализирано определение за пристрастяване:
Повтарящо се поведение, което благоприятства ритник/бърза победа в настоящето пред дългосрочно полезно поведение.
И ето някои атрибути на пристрастяващото поведение:
- Зависимите живеят в илюзия за контрол върху поведението си. Преди да се включат в него, те се кълнат, че пият само една чаша или играят само една игра на покер. Но тогава... няма ограничение за пристрастяващото поведение. Пристрастяващото поведение обикновено се свързва с неизбежност и необходимост, които граничат с естествена сила: „Не мога да помогна, трябва да го направя...“
- Рано или късно пристрастяващото поведение води до някакъв вид махмурлук. След ритника, който се чувства страхотно, зависимите страдат. Те хленчат за огромни главоболия или загубени пари и т.н. — и това води до много сериозни обещания за спиране на пристрастяващото поведение. Но, разбира се, тези обещания никога не се спазват.
- С течение на времето вредните ефекти от пристрастяващото поведение вече не са просто остър махмурлук, а сериозни здравословни/социални проблеми. Пристрастяващото поведение не е устойчиво.
- Зависимите се стремят към лесен достъп до пристрастяващия наркотик. Те се страхуват, че нямат достъп до него. Все по-голяма част от времето им се върти около пристрастяващото поведение/дрогата или подготовката за него.
- Тъй като толкова много се фокусира върху получаването или консумацията на пристрастяващия наркотик, изхвърлянето на неговите остатъци (напр. бутилки) или друг боклук или поддържането на домакинството чисто като цяло се влошава. Домакинствата на зависимите са бъркотия.
- Зависимите лъжат, за да прикрият пристрастяването си или последиците от него или да получат повече от пристрастяващия наркотик.
- Зависимите отричат състоянието, в което се намират, и всякаква причинно-следствена връзка между техните решения/поведение и тяхното състояние.
- Всяко рационално разбиране за вредните ефекти в дългосрочен план на пристрастяващото поведение не е достатъчно силно, за да го спре.
- Зависимите отказват да приемат помощ за освобождаване от пристрастяването им; те дори предполагат, че другите имат проблем, но не и самите те.
- Пристрастяващото поведение често не се разглежда като такова. Пристрастяването може да остане неоткрито за дълго време и да изглежда като нормално поведение — включително махмурлука. Защото толкова много други също го правят. Помислете за пушенето и пиенето, и двете социално приети зависимости.
Сега, какво се случва в софтуерните проекти? В един момент е ясно, че трябва да се направи А, за да се запази развитието устойчиво. Но някой казва: „Не, не, не можем да направим А сега. Вместо това трябва да направим B, защото това е, от което клиентът/пазарът се нуждае най-много сега.“ И тогава А се отлага. за неопределено време. Вместо B е готово.
Но това пристрастяване ли е? Нека сравним разработката на софтуер с атрибутите на пристрастяването:
- Разработката на софтуер не губи ли контрол върху това кога „правилното нещо в дългосрочен план“ се отлага? Това не се ли прави не само от време на време, но и редовно?
- Разработчиците на софтуер чувстват ли махмурлук? Отлагането на „правилното нещо в дългосрочен план“ причинява ли болка по-късно? Разработчиците сериозно ли обещават да не го правят отново?
- Фокусирането върху бързи печалби в настоящето причинява ли дългосрочни щети? Дали кодовата база се влошава поради поток от отлагания на „правилното нещо в дългосрочен план“ до точка, в която едва ли може да се поддържа изобщо?
- Управлението на софтуерни проекти улеснява ли вземането на решение в полза на краткосрочната удовлетвореност на клиента/пазара вместо дългосрочната осъществимост?
- Дали кодова база или хранилище и екипна стая съдържат остатъци от предишни дейности за бърза печалба, които днес вече не са от полза? Натрупва ли се всякакъв боклук в кодовите бази (напр. подвеждащи коментари, мъртъв код, код, който вече никой не разбира)?
- Разработката на софтуер пази ли преките пътища и локалните/времевите оптимизации скрити от клиентите? Управлението на софтуерни проекти крие ли как се постига повърхностно качество чрез жертване на устойчивостта?
- Управлението на софтуерни проекти отрича ли причинно-следствената връзка между фокуса върху краткосрочните резултати и дългосрочните проблеми?
- Разработването на софтуер чувства ли се безпомощно да спре желанието да се погрижи за краткосрочните очаквания на клиентите?
- Разработката на софтуер отказва ли да приеме помощ от литература/консултанти или дори вътрешни източници, за да се върне на пътя към устойчиво развитие? Разработката на софтуер обвинява ли другите, че нямат представа как работят нещата и че текущото поведение е неизбежно?
- Разработчиците посочват ли други в индустрията, които се държат и страдат по същия начин, за да обяснят колко нормално е собственото им поведение?
Помислете за момент върху вашите отговори на тези въпроси...
Мога да ви кажа какво виждам в проектите. Виждам само Да за отговор. Повечето проекти трябва да отговорят с Да на огромното мнозинство от въпросите.
Е, и това за мен безпогрешно означава: Причината, поради която софтуерните проекти се превръщат в изоставени зони, стават неподдържани, стават трудни за разбиране и променят наследения код, е пристрастяването.
Това е, с което трябва да се сблъска софтуерната индустрия. Да приеме. Да призная.
Без това подобрение не е възможно. Това е като всяка друга зависимост.
Пристрастяващото лекарство
Но какво е пристрастяващото лекарство, за какво копнее разработката на софтуер? Да се говори за „техническа зависимост“ би било погрешно.
Мисля, че пристрастяването има две страни. Две „потребности“ изглежда са основните двигатели зад пристрастяващото поведение:
- Сигурност: Разработката на софтуер се стреми към сигурност. Иска да укроти звяра на несигурността, наречен клиент/пазар. Все още вярва, че несигурността може да бъде контролирана по някакъв начин; просто трябва да се постараеш повече. Средствата за контролиране на несигурността са буфери от всякакъв вид, напр. рамка на плъгин, която да е готова за всякакви промени, някаква логика за валидиране, защото никога не знаете какви данни влизат в системата, API за обслужване само на възможни настолни/уеб/мобилни клиенти и т.н.
- Връзка: Разработката на софтуер копнее за връзка с клиента/пазара/висшето ръководство. То се чувства зависимо от тях и прави всичко, за да им угоди. То иска постоянно оценяване, подложка на гърба. Паричният поток не трябва да спира. Средството за поддържане на връзката е реактивност. Разработката на софтуер е насочена към незабавна реакция на всяка заявка, изказана от източник на пари. Отказва се от самоконтрол/автономия, за да получава постоянна оценка. Разработката на софтуер се страхува да види сълза в окото на източник на пари повече, отколкото вампирът се страхува от чесън.
Заключение
„Технически дълг“ е романтична метафора. Подхранва илюзията за контрол. Но разработването на софтуер е извън контрол. Той не може да контролира самопричиненото влошаване на кодовите бази. Защото разработката на софтуер е пристрастена.
Страда от „пристрастяване към сигурността и връзката“.
Признаците на пристрастяване са ясни и тук, за да ги видят всички. Просто трябва да преодолеем заблудите и отричането и да ги признаем.
Тогава разработката на софтуер има шанс да преодолее своята зависимост.
Благодаря, че прочетохте! Моля, споделете, ако ви е харесала статията.
Тази статия се „появява за първи път“ в един от старите ми блогове.
