Over-engineering, будь он неладен!

НАБОЛЕЛО! Доколе, я вас спрашиваю, доколе разработчики будут заниматься этими гнусностями? Можете не отвечать - думаю, что это будет вечно! Вы еще не понимаете, о чем я? Over-engineering - чрезмерное усложнение технических решений. Практически на каждом шагу встречаю. Но если с продуктами, к которым я не прикладывал руку, я могу найти оправдание (начальные требования, поддержка старых версий и прочее), то в своей команде хочется руки за такое отрывать! Поясню на примере.
Представьте себе, что есть две программы. Одна умеет дроби готовить, а вторая - американская. Первая знает, что может быть пол пачки таблеток "Антижопонеболина", а вторая - нет. Эти программы обмениваются данными. Как быть? Решение напрашивается само собой: в процедурах выгрузки данных из первой программы для каждой карточки товара выгружать дублирующую с каким-то признаком, отражающим, что это "часть пачки". Например, если мы знаем, что "Антижопонеболин" может быть пачками и "половинками" и в остатке имеем 3.5 пачки, выгружаем:
Наименование: Антижопонеболин, Количество: 3
Наименование: {D} Антижопонеболин, Количество: 1
При обратной загрузке опять включаем математику дробей.
Знаете, как в таких случаях поступают зараженные over-engineering'ом? В первой программе для каждой карточки товара создается дубль в базе данных. Чтобы он не был виден пользователям (карточка создается только для того, чтобы зафиксировать уникальный код), необходимо пару месяцев работы, куча ресурсов для (внимание!!!):
1. Сделать как написано выше (пару часов работы).
2. Внести изменения в 50% отчетов и документов, чтобы эти "виртуальные" карточки не отображались пользователю.
Четверг мгновенно перестал быть томным!