Има много шеги около техническия дълг, но какво се случва, когато компаниите го оставят да изчезва? Помолих куп разработчици да споделят някои от своите ужасяващи истории за технически дълг.

Загуба на печалба

Артър Линум е технологичен консултант. Той сподели някои от своите преживявания с мен:

„Бях консултант на стартъп, който беше натрупал значителни технически дългове. Бяха се втурнали да спазят кратки срокове, за да се позиционират в челните редици на пазара, и това доведе до код, който беше бърз и мръсен.

За съжаление техният технически дълг ги настигна. Техният зле проектиран код изисква огромно количество време и усилия на екипа им за дешифриране и управление. Простите подобрения биха отнели двойно повече от очакваното време и това доведе до забавяне на техния цикъл производство-тест-пускане.

В крайна сметка удължените им графици им губят време на пазара, което води до загуба на печалба.

Трябваше да им помогнем да изплатят техния технически дълг, като преработихме цялата структура на техния код и зададохме стандарти за кодиране, за да гарантираме, че няма да възникнат проблеми в бъдеще.“

Артър Линума, съосновател и президент на ISBX

От 50 билета на ден до 1 билет на седмица

Чанинг Нортън ръководи фирма за аутсорсинг на ИТ услуги и сигурност, която помага на малки предприятия в диапазона от 25 до 75 души да се справят със своите ИТ и сигурността си. Като собственик и последна точка на техническа ескалация, той ефективно служи като CIO/CISO за всички мои клиенти.
Той сподели някои от своите ужасяващи истории с мен:

„Често започваме работа в среда, която е била пренебрегвана или зле поддържана от известно време, и когато го направим, премахването на техническия дълг и стотиците или хиляди малки проблеми е основен приоритет за нас.

Типичен акаунт от 10 души обикновено ще бъде включен с нас, произвеждайки от 3 до 50 нови билета на ден, и след нашата четириседмична програма за стабилизиране, при която изтриваме целия този дълг, същите тези клиенти средно ще се доближат до един билет на всеки няколко седмици.“

Чанинг Нортън, собственик, PC Solutions

Доброто, лошото и грозното

„Въз основа на моя опит, клиентите, които използват Salesforce CRM, натрупват много технически дългове в персонализирането на платформата с персонализиран код. Сега нуждата винаги е налице и понякога CRM платформата не успява. Решението е прекомерната употреба на персонализиран код до степен, в която се изчерпват много проблеми с по-нататъшно персонализиране, надстройки на платформата, което е самата стойност на инструмент, базиран на облак.

Виждал съм Salesforce Orgs, които са миризливи (което означава, че са надхвърлили лимита на персонализирания код и не могат да правят повече по редовете на кода), грозни (прекомерна употреба на персонализирани екрани, което го прави напълно остарял за бъдещи промени на точка и щракване) и мухлясали (използвайте на тригери и апекс класове във всичко, което е накарало импортирането на данни да надхвърли ограниченията на управителя и е ужасяващо за администраторите да променят дори един ред от страх да не нарушат целия процес и да свалят системата).“

Buyan Thyagarajan, Salesforce MVP, специализиран в Salesforce CRM и маркетинг автоматизация, Eigenx

Внимавайте за последствията от интегрирането на трета страна

„Имахме изненада в един от последните случаи, когато имахме бета функция и се заехме с някои технологични задължения около нея. Докато го правехме, открихме, че третата страна, с която се интегрирахме, НАПЪЛНО е променила публичния API и метода на интегриране, изисквайки от нас първо да се справим с него. Като разработчици всички познаваме тези ситуации, в които задачата ви е да разрешите един проблем и докато се опитвате да го направите, откривате още три (понякога по-спешни) проблема, с които да се заемете.“

Авиад Мизрачи, технически директор и съосновател на Frontegg

Изцедена производителност

„Техническият дълг намалява производителността, което води до непрекъснато намаляваща производителност. Кодът, който е лошо написан, може да отнеме повече време и усилия за декодиране и поддръжка. Ако помолите вашия екип да направи просто подобрение на кода, което обикновено отнема три седмици, ще бъдете шокирани да чуете, че ще отнеме шест седмици и може да ги принуди да забавят други задачи.

Техническият дълг не само ще забави времето за изграждане на вашия екип, но и ще забави цялостния ви цикъл производство-тест-пускане.

Ще поискате нова функционалност, но тези актуализации ще въведат нови грешки в зле написания код, правейки тестването много по-трудно за вашия QA екип. И докато навигирате в кода и сте готови да пуснете, екипът почти сигурно ще бъде стресиран от удължения график и почти сигурно ще имате загубена печалба поради загубеното пазарно време.“

Тони Кели, основател и главен изпълнителен директор в CameraGroove

Свръх обещания и прекалено компромиси

„Много организации имат културни проблеми, като търговци, които продават функции, които не съществуват, и след това има луда борба за добавянето им. Или някой създава демонстрация на доказателство за концепцията, която по някакъв начин се озовава в ръцете на клиентите и сега има това крехко нещо – това нещо, което дори не се квалифицира като MVP – което трябва да поддържате.

Но разработчиците не трябва да сочат с пръст други хора, защото споделяме част от вината.

Много от нас са работили с някой, който не се е интересувал дали кодът им може да се поддържа или броят на грешките им е висок, или по-лошо, някой, който е смятал, че писането на труден за разбиране код ще им осигури сигурност на работата.

Това са крайни примери, разбира се, но дори и най-добрите от нас понякога могат да направят компромис; ние се поддаваме на натиска на времето и използваме преки пътища, обещавайки си, че ще се върнем по-късно и ще направим кода си по-стабилен, но често никога не го правим.

Проектите с отворен код могат да избегнат част от това, защото (в идеалния случай) има компетентни хора, които пазят кодовата база и (в идеалния случай) има по-малко натиск. Но за съжаление, дори и в отворен код, техническият дълг може да се натрупа.

Джъстин Дорфман, програмен мениджър с отворен код в Reblaze

Дали техническият дълг преследва мечтите ви?

Данните са знание, когато става въпрос за създаване на план за намаляване на вашия технически дълг. Безплатният инструмент Stepsize може да помогне на вашия екип да проследи и приоритизира техническия дълг въз основа на загубеното време, морала на екипа и въздействието върху бизнеса. Тя ви позволява да наблюдавате и идентифицирате съществуващия дълг в реално време без прекъсвания на работния процес и можете да създадете своя безплатен акаунт сега.