ITRampage

Говорять про дві основні проблеми у програмуванні:

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

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

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

Моя думка може бути не очевидна. Як це з двох технічних (насправді філософської/онтологічної та інженерної/фізичної) проблем слідує проблема, що розробники не орієнтовані на бізнес?! Все досить просто! В 2001 році зібралися експерти та сформулювали Agile Manifesto в якому нічого немає про патерни, підходи до архітектури, нормальні форми чи ефективне використання кешу процесора.

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

Також значною мірою тему бізнес-оріентованості розвиває методологія Domain Driven Design / Development, в якій воно, правда, губиться серед технічних патернів та тактик. Крім того, Domain-Driven Design переоцінює знання експертів у предметній області.

Більшість із них, наприклад, вчорашні користувачі MS Excel і продовжують думати у таблицях та формулах. Вони не здатні організовувати інформацію, проєктувати UI/UX, рефлексувати про свої підходи до роботи і таке інше. Більшість експертів у тій чи іншій предметній області самі погано її розуміють. Із власного досвіду можу сказати, що особливо це справедливо щодо бухгалтерів, але я працював не в такій великій кількості предметних областей, аби сказати, що бухгалтери – найгірші.

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

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

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

Якщо Netflix’у, взірцю і піонеру т.з. “мікросервісної архітектури” необхідно задіяти декілька команд, та переписати декілька сервісів аби просто змінити порядок слідування серій у четвертому сезоні серіалу Чорне Дзеркало, то хіба Netflix дійсно може похвалитися великою пропускною здатністю у перерахунку на одного розробника?

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

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

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

Подумайте самі, хіба людей не демотивує виконання роботи, сенсу якої вони не розуміють і в результати якої не вірять? Хіба не від цього так багато вигорань в ІТ?