К посту про duct tape programmer: так «простые и надежные» штуки тоже сложно делать.
В крайнем случае получаем код начинающего программиста, который ещё не слышал слово «окружение», использует абсолютные пути и запускает готовые утилиты и куски баша через system() без какой-либо проверки вывода или хотя бы кода возврата.
Очень простой код. Прямолинейный, очевидный, ничего лишнего. Да и на конкретном компьютере фиг сломаешь — ну кто будет питон на убунте сносить, скажем? Вся система же ляжет.
Но код получается безумно ломучий. Запустили под другим пользователем — молчаливый fail, потому что прописан абсолютный путь до скрипта.
Создать простую систему просто. А чтобы она ещё и была надежной — сложно.
С теми же моторами: подозреваю, что «простой и надежный» дизайн прошлого века всё-таки был своего рода инженерным открытием. Лампочка накаливания в принципе тоже просто устроена, но дьявол вроде как в деталях. Когда их уже знаешь, то просто, но если не знаешь...
По-моему речь шла о другом. О том, что не нужно специально усложнять.
Многие бойцы в попытках написать типа умный код усложняют код и как следствие усложняют систему на ровном месте. Они неплохо умеют писать код, но пока еще не умеют строить системы, которые всегда работают.
Типичный пример такого типа умного кода - это когда нужно забрать файл с S3/FTP и вместо того, чтобы явно принять путь до файла, эти ребята переносят бардак из своей головы в код и реализуют неявную логику генерации путей до файла аля /opt/output/" + today.strftime(‘%Y%m%d’). Happy debugging, testing and maintenance.
Треды, локи и блокирующие очереди там где можно обойтись новым процессом. Типа умная обработка ошибок, когда со своей стороны мы ничего уже не можем сделать вместо того чтобы громко упасть. Кафки, кубернетисы, микросервисы, микрофронденты и другие слова на К и М это скорее всего усложнения там, где это совершенно не нужно.
Надежная система собирается как конструктор и базируется на простых и скучных компонентах, а не наоборот.