Простыми словами
После успеха первой простой версии команда часто пытается вложить во вторую сразу все отложенные идеи. В результате проект становится перегруженным и сложнее исходной задачи. Поэтому вторую систему особенно важно ограничивать, проверять по частям и не путать зрелость с количеством функций.
Механизм действия
Сначала проверяют, есть ли исходное условие из определения. Затем смотрят, как оно влияет на структуру компонентов, потоки данных, ограничения и действия участников. Если эту связь не удаётся наблюдать, принцип не стоит использовать как готовое объяснение.
Пример в работе
В задаче «API» сразу применить привычное решение и назвать происходящее «Эффект второй системы», не проверив, действительно ли работает этот механизм. Так можно улучшить один симптом и пропустить основную причину.
Использовать «Эффект второй системы» как гипотезу: сначала определить границы ситуации и исходное состояние, затем менять только то, что связано с проверяемым механизмом, и смотреть на результат.
Ограничения
Эффект описывает риск перегрузить второй дизайн накопленными желаниями; он не означает, что вторая версия неизбежно хуже первой.
Источник
Frederick P. Brooks Jr., “The Mythical Man-Month: Essays on Software Engineering”, 1975.