Індустрія розробки програмного забезпечення змінюється — назавжди

У 2003 році я заснував DCSL Software, яка пізніше стала One Beyond. Я вийшов у 2023 році після того, як вивів компанію на міжнародний рівень і збільшив її до понад 300 осіб. Відтоді я заснував стартап у сфері робототехніки та залучив понад 4 млн фунтів стерлінгів посівного фінансування.  

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

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

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

Як ми раніше проектували програмне забезпечення — і чому  

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

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

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

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

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

Що змінилося — і чому я знову почав будувати  

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

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

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

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

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

Чому дизайн все ще має значення — більше, ніж будь-коли   

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

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

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

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

Що це руйнує в індустрії  

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

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

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

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

Справжня зміна  

Причина, чому я впевнений, що ця зміна постійна, проста: інакше я б не будував знову.  

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

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

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