Певно усі експерти чи “експерти” сходяться у думці що, боротьба зі складністю є одним із основних завдань розробників програмного забезпечення, та й не тільки.
З цим важко не погодитися, адже складність сповільняє розвиток, ускладнює розуміння системи та прийняття рішень щодо неї, сповільняє роботу самої системи, що збільшує видадки та зменшує здатність до конкуренції та врешті решт робить системою неповороткою та навіть нездатною до змін, а отже призводить до її смерті.
Це все виглядає інтуітивно зрозумілим і з цим, здається, не можливо сперичатися, але я хочу посперичатися не зі шкідливими властивостями складності, а зі здатністю розробників на неї суттево впливати.
Складність предметної області
Кожна предметна область має власну складність і цієї складності неможливо позбутися у інформаційній системі,що обслуговую ту чи іншу предметну область. Погане знання розробниками предметної області також додає складності за рахунок необхідності трансляції з однієї моделі (експертної) в іншу (інформаційну).
На останне (відповідність інформаційної моделі предметній) розробник наче має вплив, але у більшості компаній процеси влаштовані так, що розробники лише поверхнево знайомі з предметною областю, адже збір вимог перекладається на менеджерів продуктів та бізнес аналітиків. Від розробників вимагається просто закривати задачі з розробки. Таким чином розробники мають не так багато можливостей для зменшення складності, успадкованої із самої предметної області.
Складність організаційної структури
Згідно закону Конвея, будь-яка організація, що розробляє інформаційну систему, відтворює у ній структуру власних коммунікацій. Це очевидно і може бути продемонстровано через просту метафору: коли Ви босоніж гуляєте по пляжу, то залишаєте на вологому піску відбитки власних стоп, а не відбитки стоп сніжної людини. До чого ми торкаємося – на тому залишається наш власний відбиток і це справедливо і для розробки інформаційних систем.
Якщо компанія велика – складною буде і інформаційна система, що облуговує її процесси. Якщо коммунікації всередині компанії та процесси налаштовані погано, то це необдмінно буде відображено додатковою складністю і в організації самої інформаційної системи. Оскільки розробники не мають впливу на структуру компанії, то й пов’язану складність вони подолати не здатні.
Завищені архітектурні та інфрастуктурні вимоги через запозичення, наприклад, у FAANG
Дуже багато компаній орієнтуються на FAANG (Facebook, Apple, Amazon, Netflix, Google) та інші потужні компанії й запосичують у них підходи та інструменти, які ті розробили під себе. Компанії типу FAANG мають власні можливості, обмеження, проблеми та ресурси, яких не мають інші, а отже їх рішення з великою долею вірогідності будуть занадто складними, дорогими та не зовсім релевантними для інших.
Використання чужих технологій через хайп навколо них (культ вантажу), а особливо в умовах відстутності відповідної експертизи, тільки збільшує складність в усії її проявах. Наприклад, для більшость нових продуктів, які ще не мають і одного користувача, вже не стоїть питання про використання т.з. мікросервісної архітектури (насправді, стратегії розгортання). Для них мікросервіси – це сучасний індустріальний стандарт і плювати на те, що з проблемами, які вирішують за допомогою мікросервісів, вони, можливо, ніколи не зустрінуться. Один тільки підхід з мікросервісами замість старого доброго моноліту здатен погіршити продуктивність розробників в рази.
Крім того, популярні готові рішення намагаються сподобатися якомога більш широкій аудиторії, покриваючи максимальну кількість use-case’ів й тим самим додаючи рішенню 50-90% складності, яка нічого не дає бізнесу, а лише слугує шкідливим баластом.
У більшості випадків розробники не обирають технологічного стеку компанії, та навіть коли обирають – ведуться на типовий маркетинговий bullshit від тих самих FAANG. Таким чином і тут у розробників є не так багато можливостей поборотися зі складністю.
Відсутність чіткої спеціалізації
Більшість бізнесів конкурують і не бажають користуватися т.з. стратегією синього океану. Вони не бажають працювати в одній вузькій ніші й бути у ній найкращими, натомість вони бажають необмежено масштабуватися для подальшого продажу. Ця відсутність чіткої спеціалізації призводить до великого різномаїття, яке, зрозуміло, ми відносимо до складності.
Розробники також не здатні впливати на це.
Висновки
- Складність є одним з найбільших викликів й здатна знищити проєкт, продукт чи бізнес взагалі.
- Боротьба зі складністю є завданням кожного, але що стосується розробників, то їх вклад у загальну складність зовсім не значний й на рівні своєї відповідальності вони не здатні приборкати справжню складність.
- Найбільший влив на складність мають т.з. С*-levels, але переважна їх більшість ігнорує проблему складності.
Залишити відповідь