aagимхо, одна из особенностей общих решений та, что первый проект никогда не может окупится (считая стоимость разработки общего механизма + проекта). В принципе.
Я бы еще понял точку зрения "не должна окупиться". Но "не может"... имхо это утверждение, которое не имеет шанса быть верным. Простой пример: возьмите общее решение и десять похожих проектов, для которых оно окупилось. Теперь представьте себе, что это десять этапов одного проекта. По Вашей логике, оно тут же должно стать неокупающимся.

aagПотому что общий механизм разрабатывается для класса задач. Для одного проекта его возможности должны быть излишни.
Никто не заставляет разрабатывать излишние возможности раньше, чем они понадобятся. С моей точки зрения, самое большое искусство разработчика - делать свою работу так, чтобы с одной стороны не создавать самому себе проблем в будущем, чтобы сделанное можно было легко развивать в любом направлении, а с другой - чтобы это не приводило к заметному удорожанию сегодняшней работы.

В моем случае разработка этого общего механизма оказалась весьма растянутой по времени. То есть я делал достаточно маленькое, быстроокупающееся нечто, оно распространялось, накапливался опыт применения этого нечто, и это позволяло сделать следующий эффективный шаг. По сути автоматизировалось то, что назрело, что было очевидно (по крайней мере для меня).

aagА самая большая сложность в его разработке - угадать этот класс задач, его требования и ограничения и соблюсти баланс между возможностями механизма/сложностью его использования. Это, безусловно, зависит от таланта проектировщика, но еще все равно требуется что-то типа удачи, таланта предвидения...
Со многим согласен, хотя у меня сложилось впечатление, что Вы говорите о более глобальном и жестком решении, нежели имею в виду я. Однако, я бы хотел обратить внимание на другой момент.

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

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

PVPПринцип модульнусти Вы признаете только в автомобилестроении? Или еще и в разработке процедур? Может следует распространить его и базы данных?
Насколько я понимаю, Вы говорите о "базах данных" в mssql-ном смысле, аналоге ораклового "схема". Если так - принцип модульности в плане разнесения разных подсистем в разные схемы имеет право на существование, но в то же время имеет ряд практических неудобств, главное из которых - нет возможности легко менять названия схем (баз), в которых лежат модули. А это допустимо только для самописной системы, но не для [человеческой] тиражируемой. Сразу представляется, как гениальный разработчик распихивает свое приложение по схемам [common], [buh], [store], и как это начинает конфликтовать с приложением другого разработчика в той же БД.

Да, согласен, можно сделать нормально. Но... знаете, сколько в мире существует независимо написанных файлов, например, OraQuery.pas?