Сложность при разработке software
Основной длящийся во времени вызов, который держит меня в профессии инженера/менеджера - вызов сложности. Сложность всегда наступает, иногда создавая впечатление хаоса, и только направленные усилия - мои и команды - этому противостоят.
Это чем-то похоже на тетрис: сверху падают новые хотелки и требования заказчика, баг-репорты, идеи от программистов, новые версии библиотек-зависимостей и операционных систем (и устаревание старых). Когда ты не успеваешь это всё укладывать ровными рядами, то они превращаются в нагромождение.
Когда проект разрабатывается годами, нагромождение неизбежно. Вместе с нагромождением требований, фич и кода, растёт хрупкость системы и постепенно сложность становится ключевым ограничением развития, узким местом развития. С этим приходится как-то разбираться.
Как?
Есть один очевидный, "в-лоб" способ: документировать. Документировать требования, документировать архитектуру, снабжать код комментариями. И у этого способа есть своя цена.
Во-первых, это увеличение объёма текста, информации. По мере роста объёма текста, требуются всё новые и новые введения, индексы и перекрёстные ссылки; по мере добавления комментариев в код, он становится "разбавленным". В какой-то момент возникает соблазн/необходимость составить список документов, а затем и список списков и возникает новый "фронт" нагромождения.
Во-вторых, документированный хаос остаётся хаосом; путанный лабиринт с указателями остаётся лабиринтом. Нужны способы управляться с самой сложностью; способы упорядочивать хаос.
Итак, я отправляюсь в thinking aloud поход в поиске способов конструктивно управляться с нагромождением сложности в долгосрочных software проектах.