Тут есть один тонкий нюанс.

Режим работы не-промышленный является более удобным, "интеллекутальным", а не формальным, и т.п. Т.е. он является часто решением задачи в более чистом виде. Каждый мечтает свести сложность системы к такому порогу, при котором возможно разработать его малой командой (1-3 человека), получить отличную надёжность без спец. организованного контроля качества и т.п.
Но увы, в какой-то момент приходится переходить к промышленному масштабу работы - с резким скачком накладным расходов, уменьшением соотношения думание/рутина и т.п.

Роль хорошего инструментария - отдалять тот порог, за которым нужен этот переход.
Например, у Липаева чудовищная цифра производительности - 2 строки/ в день на человека отлаженного ассемблерного кода.
Т.е. если приходится работать на неадекватном инструменте, то вводить пром. методы приходится очень быстро, иначе никак.

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