Как иметь дело с внутренними структурами компании и фабриками ПО?

Основываясь на моем собственном опыте и опыте моих друзей, я вижу, что у многих компаний есть какие-то странные идеи по разработке собственных фреймворков и фабрик программного обеспечения (строят для вас скелет приложения). Эти идеи обычно основаны на убеждении, что собственная структура будет намного лучше, чем что-либо другое. Как бороться с такими идеями и как объяснить, что это не всегда хороший путь?

Почему я считаю, что внутренние структуры / фабрики не очень хороши:

• Бюджет и ресурсы - Обычно нужно создать лишь некоторый первоначальный бюджет фреймворк. Никто не думает о бюджете, необходимом для поддержания и поддержки структуры. Никто не может даже оценить бюджет и ресурсы, необходимые для обслуживания. Вначале никто не думает о поддержке нескольких версий фреймворка для поддержки уже существующих приложений.
• Отсутствие опыта - фреймворк обычно создается людьми без такого опыта или при поддержке «консультантов» - как правило, гораздо более дорогих людей с аналогичными навыками set.
• Архитектура / дизайн - любая архитектурная проблема во фреймворке влияет на все приложения, созданные с использованием этого фреймворка. Плохие дизайнерские решения во фреймворке вынуждают разработчиков кодировать приложения плохим способом.
• Технический долг - плохой код во фреймворке - это технический долг.
• Ложная вера в серебряную пулю - менеджеры считают, что собственный фреймворк / фабрика - серебряная пуля. Все приложения будут написаны одинаково, и их будет легко поддерживать. Мой опыт показывает, что это просто неправда. Даже с фабрикой ПО каждое приложение индивидуально.
• Недостаточная документация - документация - это первая часть, на которую влияет низкий бюджет. Фреймворк без документации бесполезен. Reflector (.NET) - мой лучший друг.
• Недостаточная группа пользователей - внутренняя структура имеет только небольшую группу пользователей. Маленькая группа пользователей означает небольшой опыт. Если я использую общедоступный инструмент / фреймворк и у меня проблема, Я могу задать вопрос о SO (или аналогичном веб-сайте) или просто попытаться найти ответ в Google. С внутренней структурой это невозможно.
• Политика - политика компании вынуждает вас использовать структуру для оправдания затрат на структуру. Это заходит так далеко, что фреймворк выбирается до того, как будет собрано первое требование.
• Жалобы на фреймворк запрещены.
• Использование других фреймворков запрещено.

Почему, я думаю, компании делают это:

• Высокомерие & эгоизм - кто-то в компании считает, что у него это получается лучше.
• Невежество - игнорирование существующих фреймворков / решений и того факта, что только хорошие фреймворки выживают достаточно долго, чтобы стать популярными. Игнорирование группы пользователей и уже доступной информации в Интернете.
• Неудача и некомпетентность руководства - непонимание последствий (особенно долгосрочных) этого решения. Решение основано на неверной информации. Управление без опыта разработки ПО.

Я понимаю, что иногда требуется собственное решение или фреймворк для специализированного сценария, но я устал от всех этих «отличных внутренних фреймворков» для создания веб-приложений или настольных приложений. Я ошибся? Действительно ли нужны эти фреймворки (мир .NET и Java)? Можете ли вы предоставить мне какой-нибудь пример или причину, почему хорошо иметь внутреннюю структуру / фабрику?

Изменить:

Спасибо за ответы, но я ожидал совета, как справиться с проблемой как разработчик (кроме смены работы) не как менеджер.