Про искусство системного управления
Заметка "Op/Ed: Applying Science to the Art of Systems Management" в Dr.Dobb's (www.ddj.com/architect/218100703) в очередной раз перепевает проблему роста сложности программных проектов.
Да, современные софтверные системы, в десятки миллионов строк кода, наиболее сложные, чем когда-либо -- в них все шире интегрируются существующие наработки, которые сами по себе живут собственным циклом, число взаимосвязей между подсистемами достигает немыслимых ранее значений, и при этом в проектные требования во время разработки все активнее и все чаще вносятся изменения, которые надо учитывать на лету.
ИТ-менеджеры реагируют обычно так: решают проблемы по мере их возникновения (самый плохой способ в софт-проектах), автоматизируют и формализуют коллективную работу на организационном уровне (само по себе это важно, но если нету качественной модели реализуемой системы, хорошая организация труда не поможет; тому пример Microsoft, в которой работается прекрасно, и процессы разработки эффективно поставлены, а продукты все время получаются сырыми), или же создают системы, которые "конструктивно корректны" -- то есть допускают неограниченное развитие и быструю модификацию без возникновения внутренних конфликтов, а главное, сама модель системы является ядром проекта и "управляет" всеми остальными процессами.
Автор заметки склоняется к последнему варианту, только не уточняет, как его реализовать на практике :)

Продуктов, методологий, стандартов и технологий, "управляемых моделью", уже немало, но проблема в том, что уровень входа в них весьма высок. Подрядчику психологически проще потратить два года в режиме "как можно быстрее взялись за разработку -- получили некий сырой результат -- исправили баги -- переделали львиную долю -- исправили баги -- переделали львиную долю -- исправили баги -- ... -- получили нечто удовлетворительное", нежели израсходовать полгода на абстрактное моделирование, -- пусть даже спустя вторые полгода будет получен надежный, качественный и масштабируемый продукт.
Многие agile-методики (реально же -- эвристики) в основном и нацелены на обходное решение этой проблемы -- поскорее удовлетворить нервничающего заказчика и при этом сохранить хорошее качество продукта. Но стабильно работающую и повторяемую в разных проектах технологию они не предлагают. Между организационными фишками обобщенного успешного опыта (которые, например, позволяют довольно точно спрогнозировать сроки, но не способны снизить сложность модели в разы, хотя это почти всегда возможно) и непосредственно программистской деятельностью (которая, подчиняясь давлению проектных требований, снижением этой сложности практически не занимается), пока существует явный разрыв.
Его можно сократить развитием метамодельных средств, что хорошо, когда реализуется поток более-менее схожих проектов (но все равно неясно, как снизить порог входа -- уже на этот метамодельный уровень). Или же движением в другую сторону -- развитием индивидуального мастерства экстремальных-agile-программистов, но тогда каждый проект получается штучным. Интересно, где в среднем выигрыш будет заметно больше.

UPD. Иногда кажется, что идеи действительно витают в воздухе, -- почитал чужие посты, и наткнулся на пост по схожей теме, написанный примерно в это же время. Тогда наши мозги -- типа приемника-телевизора, который транслирует либо более-менее полезные идеи (изредка :), либо случайный бессмысленный шум.