Технічний борг вбиває жаб

У вступі до «Прагматичного програміста» є глава під назвою «Кам'яний суп та варені жаби». Автори наводять знамениту метафору про варених жаб:

борг

Якщо покласти жаб у холодну воду, а потім поступово підвищувати температуру води, жаби будуть спокійно сидіти на своєму місці, поки вони повністю не звариться, коли вода закипить. З іншого боку, якщо кинути жабу прямо у окріп, вона одразу знайде в собі сили вирватися з цього ворожого середовища.

У цій статті я використаю цю метафору для розвитку ідеї, що технічний борг, швидше за все, створить середовище, подібне до того, в якому опиняються нещасні жаби.

Спираючись на свій досвід, я зміг зауважити, що певні факти, що породжують технічний борг, мають реальний негативний вплив на психіку акторів, які стикаються з ними, і я маю на увазі, зокрема, тих, хто лежить в основі професія розвитку; самі розробники.

Поняття технічного боргу починає бути добре відомим у світі розробки програмного забезпечення, і професіонали все частіше застосовують його, щоб попередити про короткотермінові стратегії, які ми часом хочемо запровадити.

У формулі технічного боргу найсильнішим терміном є, очевидно, борг. Це справжня концептуальна знахідка цієї формули. Борг - це зобов'язання, яке доведеться погасити в майбутньому, але якого неможливо уникнути. Також визнано, що борг неминучий; це природне явище (подумайте про поняття інвестицій, яке супроводжується боргом), яке досить просто необхідно контролювати.
Технічний борг, який не буде поглинений, може навіть призвести до явища технічної переборгованості; ситуація, коли всі технічні зусилля використовуються для виплати відсотків за борг.

З огляду на це, технічний термін, зрештою, має меншу вагу в цій концепції. Всіх заспокоює думка, що техніка у нас завжди приходить до кінця. Одного разу ми знайдемо фокусника, який зберігає чудодійний рецепт, або ми все це вкинемо і все перепишемо.

Однак є один ефект технічної заборгованості, який важче врахувати, оскільки він точно не є технічним; це вплив, який він чинить на психологію, а отже, і на поведінку ключових гравців у нашій галузі. Я призначив розробників.

Отже, якщо ми повернемося до наших жаб, роль котла з гарячою водою буде виконувати технічний борг, а роль жаб - розробники.

Технічний борг робить досвід розробника більш болючим, а роботу більш важкою. Тому я схильний думати, що ті, хто раніше зазнає технічної заборгованості, - це самі розробники.

Ведення занадто старого або погано написаного коду, використання середовища розробки, яке більше не відповідає поточним потребам, відсутність відповідних інструментів, неможливість діагностувати або протестувати ваш код - це неприємні враження, які поступово спричинять розробників у дискомфортному стані.
Вплив на моральний дух є реальним.

  • Пригніченість
  • Повільність
  • Зниження мотивації (виснаження)
  • Втрата творчості
  • Ерозія навичок

Негативні почуття можуть спричинити поведінку, яка шкодить нормальному функціонуванню колективу

  • Недовіра
  • Гіркота
  • Опір
  • Індивідуалізм

Нарешті, ми побачимо, що технічний борг має тенденцію знерухомити розробників, позбавити їх будь-якої спроможності діяти, як жаби, які не можуть знайти енергію для вилучення з середовища, яке вони навіть не підозрюють, що це робить. вбиваючи їх.

Виснаження факультетів розробників посилює вплив на команду. Хоча професія розробника вимагає все більшої кількості взаємодій, обмінів та динамізму, технічний борг, як правило, вбиває командну роботу та дух співпраці.

На рівні управління ми часто знаємо про технічні проблеми боргу, з одного боку, та про людські проблеми, з іншого. Але поставити ці два явища у взаємозв’язок не так просто. Непросто потрапити в межах досяжності розробників; коли ви вступаєте в управління, ви швидко втрачаєте позиції техніки.
Крім того, технології розвиваються дуже швидко, менеджери постійно стикаються з проханнями про оновлення від розробників.

Поширено спостерігати атмосферу недовіри між розробниками та їх керівництвом; розробники підлягають технічному боргу, тоді як менеджерам важко оцінити вплив цього технічного боргу на організацію.
Ці умови перетворюють навколишнє середовище в казан з окропом; ситуація погіршується, але ми не знаємо, що робити, тому більше не докладаємо зусиль.

Спостерігаючи за еволюцією світу розвитку протягом більше десяти років, вплив технічного боргу на розробників стає для мене все більш очевидним, і зараз я переконаний, що це нове явище, яке слід дуже серйозно сприймати на стратегічному рівні.

Феномен технічного боргу, звичайно, не є новим, але спосіб на який ми дивимось на нього змінюється. Технічний борг постає дедалі більше як щось, що може порушити ІТ-екосистему в цілому, і не лише з чисто технічної точки зору. На мою думку, це тісно пов’язано з двома явищами: поширенням технологічних інновацій та появою нового покоління комп’ютерних вчених.

Ринок ІТ-робочих місць тісний, оскільки цифрова революція сприяє значному зростанню, тоді як кількість розробників на ринку недостатня.
У цьому контексті технології розробки розвиваються з шаленою швидкістю, і розробники особливо чутливі до явищ застарівання своїх навичок. Як результат, технічний борг є для них фольгою.

У нинішній ситуації ігнорування технічної заборгованості відлякує творчих та мотивованих розробників, поступово виснажуючи розробників, які змогли зберегти свою лояльність. В умовах, коли попит на інновації зростає, не враховуючи фактор технічного боргу у вашій стратегії розвитку, може бути самогубством.

Деякі цифрові програвачі добре розуміли ці проблеми. Це структури, в яких ми знаємо, як підвищити якість, смак до інновацій та постійне вдосконалення навичок.

На мою думку, цілком можливо, що в найближчі десятиліття ми будемо свідками форми передачі навичок компаніям, для яких технічний борг - це концепція, яка враховується на стратегічному рівні.

Поки що ми дотримуємось дуже загальних міркувань. Для того, щоб навести деякі конкретні аргументи до цього роздуму, я пропоную вам проілюструвати суть через три явища, що породжують технічний борг.

Технологічна застарілість

Ви - далекоглядна людина, ви беретесь за абсолютно новий проект розвитку і маєте впевненість у собі. У цифровому світі все відбувається дуже швидко: перші успіхи є, ви піднімаєтеся, армія розробників вже на мосту, і всі мають голови на кермі.

Так, але все йде дуже швидко (ми вже говорили про це). Через п’ять років з’являється нове техно, що робить галас і технологічний вибір на початку застарілий. Звичайно, але неважливо: це все одно працює !
Однак що ти бачиш навколо себе ?
Конкуренти приходять, щоб побити вас пішаком більш сучасними, більш привабливими речами. Ваші розробники, які роками вкладали великі кошти, скаржаться на технологічне старіння. Ви більше не можете набирати таланти, необхідні для розвитку вашого бізнесу.

Яка невдячність! Хоча ви сумлінно вдосконалювали функціональне багатство свого програмного рішення, ви поступово втрачали свої виробничі можливості.

Що трапилось ?

Можливо, ви нехтували врахуванням необхідності технологічного оновлення.

На перший погляд застаріла технологія може не представляти великої небезпеки, але дуже поступово спричинить такі негативні наслідки:

  • Ваше рішення буде виглядати застарілим або навіть застарілим в очах ваших клієнтів або потенційних клієнтів незалежно від його внутрішньої цінності.
  • Ваше рішення буде ускладнювати інтеграцію з іншими компонентами інформаційної системи і буде намагатися відповідати новим вимогам, таким як безпека, автоматизація, доступність, стійкість, масштабованість.
  • Ваші розробники втомляться цим проектом і поступово втратять свої творчі та виробничі можливості.
  • Розвивати свої команди буде важко, оскільки ваші технології більше не будуть у фазі з перспективними на ринку праці.

Ви зрозумієте, що в контексті цієї статті мене стосуються особливо почуття розробників.

Давно розроблені розробники незадоволені, але не обов'язково знаходять у собі сили висловитися. Вони займаються давно. Вони мають голови в кермі. Вони не наважуються поставити під сумнів всю структуру.
Коротше кажучи, це не обов’язково показує, але вони поступово втрачають свою продуктивну енергію.
Вони створили газові заводи, щоб позбутися нудьги. Вони виглядають дуже зайнятими, але зрештою лише погіршують ситуацію, в якій продуктивність, інновації та цінність товару руйнуються.

З іншого боку, якщо ви спробуєте створити нових розробників для відродження творчої динаміки, вони швидко обхоплять їх ногами за шию або швидко дозволять собі готуватись, як інші (це питання темпераменту).

Дошка

Ніколи не дозволяйте спати думці, що технологічне старіння вашого рішення не має ніякого відношення до його внутрішньої цінності.

Переконайтеся, що це рішення змінюється у часі, і довіртеся розробникам, щоб забезпечити це оновлення. Немає сенсу намагатися замінити приготовлених жаб на свіжих жаб, які так чи інакше не залишаться такими довго в уже киплячій воді; радше уникайте вбивства своїх розробників на роботі.

Поганий дизайн та низька якість коду

ПОЦІЛКУЙ, Будь простішим дурним !

На мій погляд, цей принцип застосовується до початку проекту. Ми керуємось творчістю. Ви повинні швидко переконати. Нам потрібно щось конкретне. Але як бути, коли вашому рішенню кілька років і кілька сотень тисяч рядків застарілого коду? ?

За відсутності надійного, добре розробленого дизайну, ваші розробники в довгостроковій перспективі витратять свій час, пробираючись надлишковим, багатослівним, не дуже масштабованим кодом, і в кінцевому підсумку випікаються в середовищі розробки, де цього вимагає найменший рядок коду багато часу. інтелектуальної енергії, щоб вони забули, для чого саме.

Якщо через деякий час ви насправді усвідомите це, ви будете шукати рішення в "редизайні". Це коли ви справді принесете газову установку до себе додому. У вас не залишиться розчарованих розробників, які пояснять вам, що він розроблений з їхніх ніг з самого початку і що все потрібно переписати, але це може зайняти деякий час, що зараз неможливо оцінити.

Дошка

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

Зверніться до архітекторів, експертів, досвідчених розробників. Навіть якщо вони лякають вас концептуальними промовами, або створюється враження, що ви витрачаєте занадто багато часу на роздуми, вони є гарантами основи вашого рішення.

Постійно практикуйте належні практики розвитку факторизація та огляд коду.

І перш за все, підвищити якість коду. Розвиток - складна дисципліна що вимагає великих інтелектуальних зусиль.

Незважаючи на те, що ця спрощена аналогія застосовується занадто часто, розробка програмного забезпечення не полягає у складанні цегли. Розвиток не є завданням, як це розуміється в організації роботи з використанням тейлору.
Оскільки програмне забезпечення по суті є абстракцією, його якість важко оцінити, а наслідки низької якості можна відчути пізно.

Відсутність або відсутність автоматизованого тестування

Все ще є занадто багато організацій, які досі впевнені, що розробка автоматизованих тестів є надмірною вартістю, яку можна легко пощадити.

Звичайно, автоматизовані тести є складними для впровадження та вимагають реальних інтелектуальних інвестицій. Однак їх реалізація є ключовим фактором поглинання технічного боргу.

Розробник, який не може легко протестувати свій код, виробить поведінку самоцензури. Механізм простий: якщо ми не можемо перевірити, ми не ризикуємо вдосконалювати код, переробляти або переробляти та розробляти структуру та інструменти.

Ризики регресу занадто великі, природніше залишатися в комфорті. Однак у міру накопичення технічного боргу розробники поступово втрачають свою здатність діяти; що означає подвійне покарання за ваше програмне забезпечення.

Дошка

Розробити автоматизовані тести !

Тестування - одна з найскладніших дисциплін у розробці. Це досить парадоксально, оскільки тести, мабуть, нічого не дають і вимагають значних зусиль.

Технічний борг - це гангрена розробки програмного забезпечення.

Хоча концепція технічного боргу зараз досить часто висувається в організаціях, все ще важко врахувати вплив людини. Однак світ розвитку швидко змінюється, і управлінська практика зазнає кардинальних змін. Наш погляд на професії, що розвиваються, починає змінюватися. Тому мені здається важливим довести роздуми про технічний борг до управлінського рівня.

Явище боргу неминуче, і вам доведеться навчитися жити з ним. Зі свого боку, я переконаний, що в галузі розробки програмного забезпечення структури, які виживуть, будуть ті, які це усвідомили і змогли реалізувати реальну стратегію поглинання технічного боргу на основі наступних стовпів:

  • Поліпшення продовжується.
  • Впевненість у творчих можливостях розробників.
  • Вимога щодо якості.
  • Тестування.

Нарешті, щоб закрити цю статтю, дозвольте мені просто процитувати Прагматичного програміста:

Не будь як жаба. Слідкуйте за великою картиною. Постійно переглядайте те, що відбувається навколо вас, а не лише те, що ви особисто робите.