Работая последние 6 лет в ИТ-структуре большой компании, зная инсайд Заказчика и параллельно участвуя в некоторых проектах как Исполнитель, наблюдая их инсайд, подмечено - у Заказчика как правило нет спецов нужного грейда, для оценки нужности той или иной технологии при разработке.      Этим пользуется Исполнитель - разрабатывая на пейтоне, используя эджайл, куда без него, какой-то там код. С демонстрацией красоты на фронте и скрытыми проблемами бэка.   Если задать приватный вопрос, зачем так, ведь тормоза вылезут когда-то - получишь, ожидаемый ответ - главное, пользуясь отсутствием компетенций у Заказчика, выдать быстрый результат. Замазать ему глаза на демо. А потом, когда будет наплыв и понадобится производительность, все перепишем. Ведь кроме нас никто не сможет поддерживать наше ПО. Опять получив за это бабки.      Вывод - Заказчику обязательно нужно нанимать независимых экспертов из другой компании. Сталкивая потенциальных конкурентов из разных компаний в противовесе, можно получить от первых правильные и ценные советы по использованию языка и технологий, а вторых заставить изначально создавать более качественное ПО. Без перерасхода в итоге, эксперты будут способствовать его отсутствию, в итоге оплата их работы принесет только экономию.      Ну и конечно если это не изначально мыльный проект, для прокачки черного нала, под льготный НДС для ИТ-компании. Тут имелось ввиду - реальная гиковская тяга, творить..

//TODO   Как заметил Роб Пайк (Rob Pike), "сложность мультипликативна": устранение проблемы путем усложнения одной части системы медленно, но верно добавляет сложность в другие части. Постоянное требование внесения новых функций, настроек и конфигураций очень быстро заставляет отказаться от простоты, несмотря на то что в долгосрочной перспективе простота является ключом к хорошему программному обеспечению. Простота требует большего количества работы в начале проекта по определению самой сути идеи и большей дисциплины во время жизненного цикла проекта, которая поможет отличать хорошие изменения от плохих. При достаточных усилиях хорошие изменения, в отличие от плохих, могут быть приняты без ущерба для того, что Фред Брукс (Fred Brooks) назвал “концептуальной целостностью” проекта. Плохие же из менения всего лишь разменивают простоту на удобство. Только с помощью простоты дизайна система может в процессе роста оставаться устойчивой, безопасной и последовательной.