модОднозначно система должна разрабатываться на каком-либо инструментарии (framework) более высокого уровня чем языки программирования. Тогда и внедрение и сопровождение и модификация проходят относительно безболезненно и быстро. А если система в тупую написана на ..., то тогда конечно... Это, мягко говоря, очень спорно.

Просто программисты сами очень любят писать фреймворки (потому что интересно) и очень не любят писать функционал(потому что скучно)

softwarerСкажем, если опустить излишние подробности - считанные дни назад меня убеждали в крутоте следующего подхода: для документа описывается XML с со списком-типами полей, динамически строится его ввод итп. Добавилось новое поле - клиенту отправляется новый XML, не надо пересобирать exe-шник. Согласен, круто. Правда, на вопрос "а как добавить проверку дата_начала < дата_конца", чтобы ругалась - сказали "ну, наш exe-шник так не умеет". Я видел реализацию такого "фреймворка". Хорошую. Умеет многое.
2 подробности
1 на то, чтобы более-менее вылизать этот движок ушло 3 (!!!) года.
(Ждем высказываний "руки кривые были")

2 программировать в нем ну никак не проще, чем "в лоб". Фактически надо правильно описать огромный XML с настройками. Ребята стали гуру в работе с XMLSpy, они в нем живут.

А обоснование когда-то было как раз такое же "Добавилось новое поле - клиенту отправляется новый XML, не надо пересобирать exe-шник"

lockyА вот это пишет еще один программер, который не умеет писать фреймворки,
зато умеет писать функционал. Я уже не программист, я ими руковожу. Но спасибо за комплимент.

softwarerНу а что касается автоматизации стандартных решений, узконаправленных фреймворков, сколь помнится, мы с Вами беседовали на эту тему и не обнаружили принципиальных расхождений во взглядах. Совершенно верно.
Я еще могу добавить, что с моей точки зрения, написание подобного рода механизмов ДЛЯ ПРОГРАММИСТА, который их пишет, полезно. Это интересно, развивает, повышает его уровень, наконец он становится незаменимым. Я сам через это прошел.
Однако как руководитель, отвечающий за результат вцелом, я не могу позволить тратить время и ресурсы на подобные экзерсисы.

softwarer ОдинОднако как руководитель, отвечающий за результат вцелом, я не могу позволить тратить время и ресурсы на подобные экзерсисы.
Именно здесь я с Вами не согласен, во всяком случае не согласен со столь глобальной формулировкой. softwarer, мне кажется мы говорим об одном и том же. Я совершенно не против смягчить формулировку до ваших слов "уместные экзерсисы оказываются очень даже полезными. Но для того, чтобы это было возможно и правильно, необходимо... хорошее чувство меры, назовем так." Я просто считаю, что у меня это чуство меры есть.

Стараюсь следовать простому правилу - там где можно и уместно делать универсально, нужно делать универсально. Где именно можно, я определяю исходя из своего опыта и здравого смысла. Набор таких мест на самом деле устоявшийся и не так чтобы очень большой.
Но.
Там где я не уверен , что нужно делать универсально, я не делаю универсально Это принципиальное отличие от обратного варианта: не уверен, но на всякий случай сделаем универсально, вдруг понадобится.

Я уже кажется писал, что я стараюсь использовать эмпирическое правило трех раз. Если 3 раза делаем одно и тоже, то на четвертый пишем общее решение и по возможности переводим на него первые 3.