Ещё об индустриализации профессий
Jan. 12th, 2013 12:14 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Комментируя мою предыдущую
запись, pigbig указала
на идеи Ритцера о Мак-Дональдизации общества (см. изложение концепции
в рецензии
на книгу Ритцера).
Книгу я ещё почитаю, но подмеченное автором стремление к воспроизводимости и предсказуемости мне кажется очень интересными наблюдением. При этом, если верить рецензенту, эта предсказуемость становится не средством, а целью: "Не надо лучше, надо по правилам!"
Это напомнило мне эпизод, про который я, кажется, уже рассказывал. В конце прошлого века судьба и воля начальства занесла меня на семинар для менеджеров программистских компаний. Ни до, ни после этого случая я этими вопросами не интересовался, поэтому я не могу сказать, насколько общепринятыми были взгляды преподавателя. Возможно, что это были его личные заморочки - а может, наоборот, так все менеджеры думают. Впрочем, это не так уж и важно.
Преподаватель начал с того, что всем присутствующим известны замечательные программисты, способные быстро писать прекрасный код, точно решающий поставленную задачу. Они на голову выше остальных сотрудников, и заменить их практически невозможно. Задача менеджера состоит в том, чтобы таких сотрудников выявить и немедленно уволить. Их наличие несовместимо с современным промышленным производством, которому нужна воспроизводимость. "В правильно организованной компании, - подчеркнул преподаватель, - вы можете дать одну и ту же задачу двум разным программистам, и получить практически одинаковый код. Именно в этом состоит ваша цель". Преподаватель не произносил слов про средневековье и шедевры, но мысль его была вполне узнаваема: программист должен, как рабочий у конвейера, стать типовой деталью стандартного механизма. Интересно, что про качество кода при этом ничего не говорилось: в полном соответствии с идеями Ритцера (как я их понял из краткого изложения), предсказуемость и воспроизводимость тут не средство, а цель.
Я не знаю, получилось ли с этим у менеджеров, но сам подход тогда поразил меня размахом, достойным сэра Томаса Мора или Угрюм-Бурчеева. Уходящие в бесконечность правильные геометрические ряды одинаковых серых кубиков, в которых сидят взаимозаменяемые программисты, пишущие стандартный код. Они едят стандартную еду в стандартных Мак-Дональдсах, лечат их от типовых болезней типовые доктора (если два врача увидят одинаковые симптомы, они должны выписать одинаковые рецепты!), а взаимозаменяемые юристы оформляют им типовые разводы.
См. мультипликационную заставку к "Иронии судьбы".
no subject
Date: 2013-01-12 05:39 am (UTC)ляхиодинаковые программисты, если важный заказчик обнаружит в продукте трудно воспроизводимую (но предсказуемую и таки воспроизводимую) ошибку в чужом коде, которую можно живьем увидеть лишь по удаленной сессии, и типичный программист просто не будет знать, с какого конца к этой проблеме подходить - и преподаватель сядет в лужу.no subject
Date: 2013-01-12 05:52 am (UTC)Другое дело, что тут диалектика - таким методом не "прыгнуть выше головы", что иногда бьется больно.
PS: Ну и да - в крупной фирме полезно держать Левшу, на случай если внезапно понадобится блоху подковать (кстати - тот самый сюжет - но все таки что "ружья кирпичом не чистят" оно важнее)
no subject
Date: 2013-01-12 06:05 am (UTC)Софтверная индустрия разнообразнее, чем пытаются представить. Кроме "производства предметов потребления", которое у всех на виду, есть еще и производство средств производства. Весь тот софт, с помощью которого вся Япония и Южная Корея, все айбиэмы, армы, мипсы, эпплы и интелы, все максторы, сигейты и сандиски, а также прочие TSMC и UMC делают то, что они для нас делают, в первую очередь не массовый.
no subject
Date: 2013-01-12 06:09 am (UTC)PS: Другое дело, что плясок с бубном и красивых слов там еще больше - но по уму там на эффективность (хоть программерскую,хоть менеджерскую) вообще всем наплевать. Хотя вслух это произносится по понятным причинам редко (хотя сталкивался)
no subject
Date: 2013-01-12 06:25 am (UTC)no subject
Date: 2013-01-12 06:36 am (UTC)PS: Обращу внимание на характерное - методов повышения надежности кода и выявляемости ошибок известна масса. Причем это в основном просто конкретные практики, не обременительные и требующие лишь соблюдения производственной дисциплины. Взаимодополняющие.
При это как правило применяется (применяется да - "надежность наше все") ровно одна - либо модная в текущий момент, либо та, на которую когда-то запали в конкретной фирме или проекте. Причем применяется хаотически и иррегулярно (что лишает ее большей части ее смысла).
Так вот это значит простое - "нам не нужна надежность - нам нужно чтобы глючило не сильно больше, чем у других"
no subject
Date: 2013-01-12 06:40 am (UTC)no subject
Date: 2013-01-12 06:46 am (UTC)PS: Понятно, что я несколько сгущаю краски - но в общем примерно так. Хотя да - иногда, очень редко, бывает что крупный клиент устраивает истерику и всем приходится вставать на уши и подковывать блоху (нередко, кстати, с тем же результатом, что у Левши - но психотерапевтические цели достигаются).
no subject
Date: 2013-01-12 07:16 am (UTC)no subject
Date: 2013-01-12 07:34 am (UTC)Случаи когда "у нас вообще ничего не работает" тоже бывают - но в общем это и есть на самом деле тот уровень качества, на который реально есть спрос в отрасли - если надо чтобы "работало всегда" - это стоит совсем других денег и сроков.
Не говоря уж о том, что и тут в половине случаев есть workarounds типа watchdog timer и его аналогов
no subject
Date: 2013-01-12 07:41 am (UTC)Это уже начинается hand-waving из серии No true Scotsman.
стоит совсем других денег и сроков
Ну да. Рынок оптимизирует всё, в т.ч. и соотношение цен, сроков и качества. На что жалуемся, собственно?
no subject
Date: 2013-01-12 07:54 am (UTC)Это просто мой опыт - обойти проблему почти всегда можно - а при дедлайне как раз - и лучше (потому как скоростные патчи в инструментарии чреваты ничуть не меньше) и этим обычно и заканчивется (если баг не совсем тривиальный). Просто дедлайн - удобный момент для истерики - программисты заказчика и так на взводе - а тут еще возможность перевалить ответственность.
Рынок оптимизирует всё, в т.ч. и соотношение цен, сроков и качества. На что жалуемся, собственно?
Результат очевидно не оптимальный - эффективность отрасли очень невелика - но она села в потенциальную ямку и выскочить оттуда без системных усилий не может.
PS: При этом это более или менее все понимают - оттуда и прожекты "города Непреклонска" или триумфа очередного "супер-языка программирования" - сами по себе решения известны (и действительно эффективны), но порог их внедрения "в отдельно взятой фирме" запретительный
no subject
Date: 2013-01-12 08:13 am (UTC)По каким критериям и по сравнению с чем?
no subject
Date: 2013-01-12 08:21 am (UTC)И в масштабах отрасли это окупится очень быстро - но в масштабах отрасли это щас никто не сделает, а индивидуально - ты огребешь большой рост издержек и рисков на пионерство при сравнительно небольшой отдаче.
no subject
Date: 2013-01-12 07:06 am (UTC)В том числе и "индивидуальный подход к клиенту", кой так любят медики и проч. - а потом зажим в животе забывают (насколько там введение формального предоперационного протокола в американской медицине количество осложнений сократило? емнимп сильно весьма)
no subject
Date: 2013-01-12 07:19 am (UTC)no subject
Date: 2013-01-12 07:45 am (UTC)Но реальная проблема imho в том, что в отрасли просто нет спроса ни на какую эффективность за редкими случаями "когда прижмет" (или когда инвестор на это решил сделать ставку)
no subject
Date: 2013-01-12 06:19 am (UTC)What else is new since Bible times? ;-)
no subject
Date: 2013-01-12 09:48 am (UTC)Не-а.
Просто "суперпрограммистов" нужно повышать - и ставить им задачи по типу метапрограммирования, разработку стандартов предприятия или обеспечивать рост по служебной лестнице.
Выкидывать только в том случае, если суперкодер действительно желает писать только личный супер-пупер код (таких Вейценбаум называл хакерами).
no subject
Date: 2013-01-12 02:30 pm (UTC)