Вопрос в том, ограничен ли выбор этими вариантами... и если ограничен ими, то почему.
Чем работа по найму противоречит развитию? 😕
Если заниматься разработкой программного обеспечения с гарантированной надёжностью, то это всё придётся делать.
И стандарты писать (и контролировать их соблюдение).
И проверяющих назначать.
И много чего ещё.
Почему пережитки? 😕
А Вы сомневаетесь в том, что у Микрософта вообще может быть плохо поставлен процесс разработки? 😕
А я и не собирался дискутировать в стиле "сам дурак" :p.
Есть такая штука - модель зрелости программирующего коллектива. Разработана она была не помню кем по заказу министерства обороны США для оценки подрядчиков оного министерства (кому оно может доверить свои заказы, а кому - нет). Но штука оказалась дельная и распространение получила далеко за пределами американского военного ведомства, да и за пределами Соединённых Штатов.
Так вот, зрелость программирующего коллектива оценивается на основании множества критериев интегрально по пятибалльной шкале.
Первый уровень зрелости (самый нижний) характеризуется тем, что успех проекта зависит от конечных исполнителей и уход конечного исполнителя может порушить проект.
Второй уровень характеризуется таким состоянием, что смена конечных исполнителей не способна порушить проект, но смена руководителя проекта - способна.
А на третьем уровне зрелости (кстати, он у министерства обороны США - минимальный для допуска претендентов на получение от этого ведомства заказов) уже проект живёт независимо от смены как конечных исполнителей, так и руководства.
А есть и четвёртый и пятый...
Типа a3434858 - неугрожаемый, а типа "чего" - угрожаемый?
А почему похожие на простеньких дизайнах Вы делали псевдо? 😕
А это зависит от постановки процесса разработки в фирме.
Процесс может быть поставлен и так, чтобы программный продукт было невозможно сделать "говном, в котором никто, кроме его автора, не пожелает разбираться".
И где это Вы такое читали? 😕
А можете изложить эти соображения?
