Средства и методы разработки

лифты уезжают на несуществующие этажи и там зависают и т.п. Нужен в первую очередь не быстрый, и не полезный результат, а управляемый процесс. Который за время T и сумму S даст что-то ожидаемое. Чтоб хотя бы множно было что-то планировать, в первую очередь сроки и стоимость. Сколько людей нанять сегодня, сколько уволить через год. Какой нужен офис, метров квадратных. Какие есть риски. А риски -- невыполняемые планы, это отладка ПО с непрогнозируемыми сроками, это баги вылезшие у заказчика. Это незаменимые специалисты и отсутствие передачи знания. И чтоб не оказаться у разбитого корыта обычно работа выстраивается по какому-то формализованному процессу. Общепринятому и используемому в других организациях: потому, что это упрощает найм людей и исключает неизвестные риски. И в рамках этого процесса приняты какие-то подходы: как управлять людьми, как учитывать время потраченное на задачи, как учитывать ошибки, как тестировать, как организовать документирование работы, как проверять работу... и ничего нового здесь не придумаешь. Разработчики: трамвай, который поставили на рельсы и остаётся только ехать вперёд. Это в продуктовой фирме. В R&D могут быть нюансы.

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

В целом, я заметил, есть несколько крайностей:

1) оверинжинеринг, обычно со стороны более-менее опытных разработчиков, причины почему -- разные: у работника и работодателя вообще разные интересы для начала, нужен очень тонкий баланс и его очень легко перекосить в любую сторону, что так или иначе негативно ударит по продукту (но качество продукта с доходами фирмы вообще мало связано, Д. Акерлов нобелевскую премию по экономике получал в т.ч. за доказательство того факта, что на рынке с несимметричной информацией выгодней продавать говно...)

2) наивное недопонимание, не способность видеть глубину всех нюансов, упрощённое представление -- начинающие разработчики, банально отсутствие опыта и надлежащей структуры руководства, как ни странно в силу указанного выше факта их деятельность может оказаться "продуктивной" для фирмы на каком-то этапе, но перспективы могут оказаться под вопросом, как и вообще конечный результат (не достижимые задачи, провальные планы, неустранимые проблемы в продукте, не гарантированный с точки зрения финансовых затрат результат);

3) не способность к абстрактному мышлению практически вообще (как из анекдота "Я же не отдам некту яблоко, хоть он дерись!") -- я не знаю откуда таких людей берут... В каких-то задачах они преуспевают, но некоторыми им лучше просто не заниматься...

Сочетание пунктов 2 и 3 обычно порождает лютую дичь. Быстро, дёшево и качественно. Всё "почти работает", но нужно немного исправить (читать как выкрасить и выбросить).

Пост ни о чём. Что я хотел сказать, в целом "упрощённый взляд" скорей следствие недопонимания. Невозможно на языке состоящем из всего 35 простых инструкций создавать "простые и надёжные" программы утверждая, что вон те балбесы со сложными языками только деньги тянут. Сложность в системе в целом она -- константа. И может только перетекать из уровня языка в прикладной уровень и обратно. Её можно где-то замести под коврик ООП, спрятать (но не исключить!), можно наоборот вывернуть наизнанку и тыкать в ужасные шаблоны в C++. Но это всё одна и та же сложность. Будь это не так, будь способ уменьшить сложность, итеративным применением этого способа любая программа, или любой технически сложный прибор превращался бы в тривиальное изделие. Но это не так. И никто такого способа не знает. Некоторые думают, что знают: "здесь всё можно сделать проще". Результат обычно негативный. Возможно, что даже и не сразу. Пример: систему управления впрыска в современном двигателе "было бы проще" заменить карбюратором, но далеко не уедешь.