scholar_vit: (Default)
[personal profile] scholar_vit

Комментируя мою предыдущую запись, [livejournal.com profile] pigbig указала на идеи Ритцера о Мак-Дональдизации общества (см. изложение концепции в рецензии на книгу Ритцера).

Книгу я ещё почитаю, но подмеченное автором стремление к воспроизводимости и предсказуемости мне кажется очень интересными наблюдением. При этом, если верить рецензенту, эта предсказуемость становится не средством, а целью: "Не надо лучше, надо по правилам!"

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

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

Я не знаю, получилось ли с этим у менеджеров, но сам подход тогда поразил меня размахом, достойным сэра Томаса Мора или Угрюм-Бурчеева. Уходящие в бесконечность правильные геометрические ряды одинаковых серых кубиков, в которых сидят взаимозаменяемые программисты, пишущие стандартный код. Они едят стандартную еду в стандартных Мак-Дональдсах, лечат их от типовых болезней типовые доктора (если два врача увидят одинаковые симптомы, они должны выписать одинаковые рецепты!), а взаимозаменяемые юристы оформляют им типовые разводы.

См. мультипликационную заставку к "Иронии судьбы".

Date: 2013-01-12 05:39 am (UTC)
From: [identity profile] spamsink.livejournal.com
Подобные преподаватели - идиоты, которые или никогда не работали в индустрии, или с треском вылетели оттуда за непроходимую тупость. Спросить такого преподавателя, помогут ли ему его ляхи одинаковые программисты, если важный заказчик обнаружит в продукте трудно воспроизводимую (но предсказуемую и таки воспроизводимую) ошибку в чужом коде, которую можно живьем увидеть лишь по удаленной сессии, и типичный программист просто не будет знать, с какого конца к этой проблеме подходить - и преподаватель сядет в лужу.

Date: 2013-01-12 05:52 am (UTC)
From: [identity profile] kouzdra.livejournal.com
На самом деле все эти проблемы решаемы как раз - и именно на этом пути. И в общем индустрия именно так и устроена (софтверная индустрия кстати сейчас как раз одна из самых косных отраслей - она как раз в пользу массовости, стабильности и предсказуемости отвергает даже очевидно эффективные решения - "надо не хорошо, а как у всех")

Другое дело, что тут диалектика - таким методом не "прыгнуть выше головы", что иногда бьется больно.

PS: Ну и да - в крупной фирме полезно держать Левшу, на случай если внезапно понадобится блоху подковать (кстати - тот самый сюжет - но все таки что "ружья кирпичом не чистят" оно важнее)
Edited Date: 2013-01-12 05:54 am (UTC)

Date: 2013-01-12 06:05 am (UTC)
From: [identity profile] spamsink.livejournal.com
На самом деле все эти проблемы решаемы как раз - и именно на этом пути.

Софтверная индустрия разнообразнее, чем пытаются представить. Кроме "производства предметов потребления", которое у всех на виду, есть еще и производство средств производства. Весь тот софт, с помощью которого вся Япония и Южная Корея, все айбиэмы, армы, мипсы, эпплы и интелы, все максторы, сигейты и сандиски, а также прочие TSMC и UMC делают то, что они для нас делают, в первую очередь не массовый.

Date: 2013-01-12 06:09 am (UTC)
From: [identity profile] kouzdra.livejournal.com
Я в курсе (как раз даже лучше чем в плане ширпотреба), там вообще ужас в этом плане. На массовом рынке все-таки немножко бежать приходится.

PS: Другое дело, что плясок с бубном и красивых слов там еще больше - но по уму там на эффективность (хоть программерскую,хоть менеджерскую) вообще всем наплевать. Хотя вслух это произносится по понятным причинам редко (хотя сталкивался)
Edited Date: 2013-01-12 06:11 am (UTC)

Date: 2013-01-12 06:25 am (UTC)
From: [identity profile] spamsink.livejournal.com
Там не наплевать на эффективность продукта, выражаемую в сокращении time to market для заказчика, потому что деньги платят именно за это.

Date: 2013-01-12 06:36 am (UTC)
From: [identity profile] kouzdra.livejournal.com
На это обычно тоже наплевать. Исключения бывают в редких случаях, когда вдруг реально начинает поджимать конкурент - но это бывает очень редко, а наука о том, как привязывать к себе клиентов построена в основном на другом вовсе - в первую очередь важно, чтобы клиент "подсел" - чтобы ему было трудно (и дорого) соскочить.

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

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

Так вот это значит простое - "нам не нужна надежность - нам нужно чтобы глючило не сильно больше, чем у других"

Date: 2013-01-12 06:40 am (UTC)
From: [identity profile] spamsink.livejournal.com
C учетом этого возникает важный дополнительный параметр: чтобы глюки оказывались исправлены быстрее, чем у других - и для этого одного Левши на компанию недостаточно, нужна хотя бы парочка на отдел.

Date: 2013-01-12 06:46 am (UTC)
From: [identity profile] kouzdra.livejournal.com
Быстрее - не нужно, в половине случаев вообще не нужно, чтобы они были исправлены хоть когда-то. Нужно, чтобы клиент был happy - а для этого куда важнее изображать деятельность (для чего есть отдел саппорта и всякие хитрые процедуры перекидывания багов с извещением клиента), чем реально ее осуществлять.

PS: Понятно, что я несколько сгущаю краски - но в общем примерно так. Хотя да - иногда, очень редко, бывает что крупный клиент устраивает истерику и всем приходится вставать на уши и подковывать блоху (нередко, кстати, с тем же результатом, что у Левши - но психотерапевтические цели достигаются).

Date: 2013-01-12 07:16 am (UTC)
From: [identity profile] spamsink.livejournal.com
Нет-нет, когда у клиента срываются сроки, он никогда не бывает happy, как бы ему лапшу на уши перекидыванием багов с извещениями не вешали. Уж будьте уверены.

Date: 2013-01-12 07:34 am (UTC)
From: [identity profile] kouzdra.livejournal.com
Ну что значит "срываются сроки" - почти всегда есть какой-нибудь workaround, которым проблема реально и решается. Истерика - да - обычно связана с тем, что под какой-нибудь дедлайн программист заказчика "которого все это вконец достало" возгоняет проблему к начальству.

Случаи когда "у нас вообще ничего не работает" тоже бывают - но в общем это и есть на самом деле тот уровень качества, на который реально есть спрос в отрасли - если надо чтобы "работало всегда" - это стоит совсем других денег и сроков.

Не говоря уж о том, что и тут в половине случаев есть workarounds типа watchdog timer и его аналогов

Date: 2013-01-12 07:41 am (UTC)
From: [identity profile] spamsink.livejournal.com
почти всегда есть какой-нибудь workaround

Это уже начинается hand-waving из серии No true Scotsman.

стоит совсем других денег и сроков

Ну да. Рынок оптимизирует всё, в т.ч. и соотношение цен, сроков и качества. На что жалуемся, собственно?

Date: 2013-01-12 07:54 am (UTC)
From: [identity profile] kouzdra.livejournal.com
Это уже начинается hand-waving из серии No true Scotsman.

Это просто мой опыт - обойти проблему почти всегда можно - а при дедлайне как раз - и лучше (потому как скоростные патчи в инструментарии чреваты ничуть не меньше) и этим обычно и заканчивется (если баг не совсем тривиальный). Просто дедлайн - удобный момент для истерики - программисты заказчика и так на взводе - а тут еще возможность перевалить ответственность.

Рынок оптимизирует всё, в т.ч. и соотношение цен, сроков и качества. На что жалуемся, собственно?

Результат очевидно не оптимальный - эффективность отрасли очень невелика - но она села в потенциальную ямку и выскочить оттуда без системных усилий не может.

PS: При этом это более или менее все понимают - оттуда и прожекты "города Непреклонска" или триумфа очередного "супер-языка программирования" - сами по себе решения известны (и действительно эффективны), но порог их внедрения "в отдельно взятой фирме" запретительный
Edited Date: 2013-01-12 08:05 am (UTC)

Date: 2013-01-12 08:13 am (UTC)
From: [identity profile] spamsink.livejournal.com
эффективность отрасли очень невелика

По каким критериям и по сравнению с чем?

Date: 2013-01-12 08:21 am (UTC)
From: [identity profile] kouzdra.livejournal.com
По сравнению с достижимым даже не идеалом, а реально проверяемыми вещами. Скажем смена языка действительно может сократить объемы кода в 2-3 раза, вероятность логических ошибок и стоимость их поиска в несколько раз (ну и соответственно снизить затраты и требования к квалификации - но при это понадобится другая квалификация - а предложения на рынке нет).

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

Date: 2013-01-12 07:06 am (UTC)
From: [identity profile] kouzdra.livejournal.com
PS: Кстати, это как раз та причина, почему я скептически отношусь к "культу Мастера" - бо в софтверной индустрии как раз цеховщина и кустарщина цветут буйным цветом (хотя и не на средневековый лад) и в реальности это все выглядит вовсе не так привлекательно, как это расписывают.

В том числе и "индивидуальный подход к клиенту", кой так любят медики и проч. - а потом зажим в животе забывают (насколько там введение формального предоперационного протокола в американской медицине количество осложнений сократило? емнимп сильно весьма)

Date: 2013-01-12 07:19 am (UTC)
From: [identity profile] spamsink.livejournal.com
Одно другому мешать не должно. Я утверждаю, что посылка "надо стричь всё под одну гребенку" неверна, но это вовсе не значит, что на голове должен быть "взрыв на макаронной фабрике". Хватит и чубчика кучерявого.

Date: 2013-01-12 07:45 am (UTC)
From: [identity profile] kouzdra.livejournal.com
Ну да - согласен, но реально проблема им озвученная есть - и взаимозаменяемость важна (и если нужны "крутые программисты" это надо сразу в проекте закладывать - чтобы были и тоже были взаимозаменяемы), и предсказуемость.

Но реальная проблема imho в том, что в отрасли просто нет спроса ни на какую эффективность за редкими случаями "когда прижмет" (или когда инвестор на это решил сделать ставку)

Date: 2013-01-12 06:19 am (UTC)
From: [identity profile] nms.livejournal.com
Замени "компьютер" на "автомобиль" и почитай Ли Якокку.

What else is new since Bible times? ;-)

Date: 2013-01-12 09:48 am (UTC)
From: [identity profile] asox.livejournal.com
На самом деле все эти проблемы решаемы как раз - и именно на этом пути.

Не-а.
Просто "суперпрограммистов" нужно повышать - и ставить им задачи по типу метапрограммирования, разработку стандартов предприятия или обеспечивать рост по служебной лестнице.
Выкидывать только в том случае, если суперкодер действительно желает писать только личный супер-пупер код (таких Вейценбаум называл хакерами).

Date: 2013-01-12 02:30 pm (UTC)
From: [identity profile] agasfer.livejournal.com
В биотехе американском то же самое де факто. Не знаю, учат ли этому на курсах, но такова политика. Так что преподаватели--не идиоты, а продают то, что продается.

Profile

scholar_vit: (Default)
scholar_vit

January 2019

S M T W T F S
  12345
678 9101112
13141516171819
20212223242526
2728293031  

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated May. 21st, 2025 10:51 pm
Powered by Dreamwidth Studios
OSZAR »