Давным-давно, когда я глотал фантастические книжки стопками, в одной из них была такая идея об уровнях развития цивилизации:

  1. Простые технологии/механизмы для решения простых задач (палка стукать).
  2. Сложные технологии/механизмы для решения сложных задач (двигатель внутреннего сгорания, атомная станция).
  3. Простые технологии/механизмы для решения сложных задач (это у более развитых цивилизаций, чем наша).

Было это в контексте того, что кто-то посмотрел на двигатель высокотехнологичного транспорта, а там внутри все просто и понятно, и элементарно починить.

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

Похожие идеи про простоту всплывают повсеместно, взять хотя бы тот же KISS и его вариации). Но конкретно в этой интерпретации важен аспект эволюции и сравнения, как может быть по-другому. Увы, встречаются кодовые базы, когда используется 4 вариант, дополняющий остальные три: сложные технологии/механизмы для решения простых задач. Я не помню точно, но вряд ли фантаст мог помыслить об энтерпрайзном fizzbuzz, а я с таким работаю.

В тему эволюции подходов к решению задач есть неплохой доклад от архитекторов языка Java, основная идея которого заключается в том, что когда вы наконец рассмотрели задачу со всех сторон и учли все нюансы, надо потратить еще время, чтобы упростить решение. Автор предостерегает от того, чтобы развертывать первое решение, приводя в пример сериализацию в Java (которая очень сложная и имеет кучу проблем). Тут есть нюанс контекста: он рассуждает в контексте платформенного решения, на основе которого строятся другие, а свое уэб-приложение можно и перезалить. Но еще важный момент — отношение: “раз работает, то все, задача выполнена, да и бизнес давит” — так и рождается техдолг и/или переусложенное решение.