Каждое приложение самостоятельно определяет, какие возможности поддержать для конкретного вида работы. В итоге одна и та же функциональность реализуется многократно, зачастую проходя полный цикл разработки: анализ, проектирование, реализацию, тестирование, исправление ошибок, поддержку. Это увеличивает накладные расходы как для разработчиков, так и для пользователей, и приводит к тому, что каждую ошибку, сколь бы типовой она ни была, приходится устранять в каждой отдельной программе.
Например, каждый браузер самостоятельно имплементирует отрисовку окна, вывод диалога сохранения файла, хранение закладок, ведение истории, сетевые соединения, возможность печати, обработку ошибок и так далее. Аналогично, настройка яркости и контраста, а также открытие файлов формата Jpeg поддерживаются практически каждым графическим редактором.
В случае с малоиспользуемыми возможностями картина оказывается ещё более удручающей, поскольку такая функциональность не реализуется до тех пор, пока информация о её необходимости не окажется известной в результате сбоя или обращения пользователя. Так, многие сетевые приложения добавляют корректную обработку физического отключения используемого сетевого интерфейса (например, внешней сетевой карты) только после того, как такая аварийная ситуация будет зарегистрирована. Авторы планировщиков заданий и других программ, реагирующих на определённые события, составляют списки поддерживаемых событий самостоятельно, в результате чего редко используемые события (астрономический восход и закат, сбой связи с определённым сервером и т. п.) зачастую остаются не поддержанными. Многие офисные приложения некорректно обрабатывают сетевые сбои во время работы с файлами, находящимися на сетевых дисках, только потому, что такие ситуации не возникали во время тестирования.
Нам доводилось наблюдать проблему с внутренней системой мониторинга инфраструктуры в одной крупной организации. Агенты этой системы устанавливались на серверы, состояние которых требовалось отслеживать, после чего подключались по сети к серверам, ведущим сбор данных. При настройке подключения можно было указать адрес удалённого сервера, удалённый порт и локальный сетевой интерфейс; локальный исходящий порт выбирался операционной системой. Это работало до тех пор, пока агент не запустили в инфраструктуре, где работало приложение, использующее фиксированный номер локального исходящего порта. После очередного перезапуска агент занял данный порт, и второе приложение не смогло стартовать. Для решения этой проблемы требовалось внести изменения в агент, что с учётом накладных расходов на разработку и внедрение в контролируемой корпоративной среде привело к существенным издержкам. Если бы агент использовал ту же реализацию выбора параметров сетевого соединения, что и конфликтовавшее с ним приложение, такая ситуация не возникла бы в принципе.
В «Сивелькирии» система модулей нацелена на максимальное повторное использование кода. С одной стороны, наличие модулей, предоставляющих определённую функциональность, избавляет остальных разработчиков от необходимоти дублировать решение. С другой стороны, повсеместное использование и тестирование позволяет получить действительно качественные решения, справляющиеся с любыми типовыми или исключительными ситуациями. Наконец, опыт аккумулируется и на уровне операционной системы в целом: исключительные ситуации, зарегистрированные при использовании одного из модулей, становятся основой для тестов, которые предоставляются командой поддержки центрального репозитория всем разработчикам, выкладывающим в него свои модули.