Правильная ссылка на эту страницу
http://az-design.ru/Support/SoftWare/l/GlassRob/04h2123.shtml

12.3. Творчество и стремление к упрощенности

       Несомненно, все исторические творческие вехи в программировании, перечисленные в предыдущем разделе, были действительно творческими. Но интересно: о чьем именно творчестве мы говорим?
       Эта книга посвящена, в основном, творчеству в программном инжиниринге. Больше всего меня волнуют проблемы, решение которых поможет создателям программного обеспечения делать свое дело лучше и более творчески. Но все ли отмеченные вехи этому способствовали?
       Этот важный и интересный вопрос несколько десятилетий назад имел яркую политическую окраску. Но прежде чем говорить о том, какими печатями отмечены эти вехи, обратимся собственно к вопросу.
       Первый ответ, который пришел мне в голову, это “разумеется, все эти события послужили развитию творчества программистов”, — думаю, вы автоматически ответите так же. В конце концов, разве все эти языки высокого уровня, различные методологии и инструменты программирования не внесли внушительный вклад в наше умение выполнять свою работу?
       Но после некоторого размышления у вас могут возникнуть некоторые сомнения, как они возникли у меня. Да, все эти нововведения очень помогли программистам. Но способствовали ли они развитию творчества?
       Прежде чем браться за этот вопрос, нужно объяснить, где происходил первичный творческий акт. Очевидным образом, творчество, связанное с этими вехами, происходило в головах тех, кто их породил. Представьте первого человека, который изобрел язык высокого уровня (ЯВУ) и компилятор как необходимый для этого инструмент. Чтобы придумать ЯВУ+компилятор, необходимо было увидеть “компьютер” в совершенно ином свете, как обработчик символьной информации. На самом деле, примерно в это время термин “компьютер” (вычислительная машина) начал устаревать, потому что применение этой машины перестало ограничиваться арифметическими действиями над числами и распространилось на сложные логические операции над нечисловыми символами. Комбинация ЯВУ+компилятор стала революцией — “серебряной пулей”, затронувшей, огромное число уровней.
       И все же — усилило ли это изобретение творческие возможности программистов? Глубоко поразмыслив, я по-прежнему отвечаю на этот вопрос утвердительно. С учетом легкости написания программы на ЯВУ по сравнению с ассемблером программист освободился от деталей, относящихся к конкретной машине, и смог направить свой ум исключительно на решение прикладной задачи. А если это не усилитель творчества, то я не знаю, что вам еще нужно. Правда, это иной вид творчества, чем у создателя оригинальной идеи.
       Надо сказать, что почти все первые серебряные пули явно стимулировали творчество программистов, по той же логике, что я привел для ЯВУ+компилятор. Операционные системы давали программисту возможность сконцентрироваться на задаче, не вдаваясь в машинную архитектуру. Модульное программирование позволило программисту работать с компактными понятиями, вместо свободно (порой самовольно) распространяющихся на все пространство задачи/решения.
       Спор по поводу творчества начинает проясняться, когда мы переходим к теме методологий. Дают ли методологии вроде структурного или объектно-ориентированного программирования больше возможностей для творчества или они лишь предоставляют среду, в которой программисту труднее совершать ошибки? Можно найти аргументы в пользу обеих сторон, но в данном случае мне меньше хочется быть “за”, чем в случае ЯВУ+компилятор. Думаю, поддерживая применение методологий, руководители — тогда и сейчас — стремились к ужесточению контроля над процессом программирования. А если так, то методологии вообще не имеют отношения к творчеству.
       Теперь мы готовы к обсуждению политического аспекта, обещанному выше. В конце 1970-х проблема значения крупных исторических событий в истории программирования вызвала довольно острую полемику. Два автора, политически скорее левацкого толка, высказали мнение, что все крупные исторические события в программировании, о которых мы говорили, в целом представляют собой хитрость руководства, заговор с целью не повысить творческий уровень своих работников, а “деквалифицировать” их! А зачем руководителям деквалифицировать своих рабочих? Чтобы было проще управлять ими и контролировать создаваемые ими продукты.
       Вот эти два автора, которые тогда вышли на компьютерную сцену, чтобы смешать политические и компьютерные понятия:
       — Филип Крафт (Philip Kraft) [Kraft 1977], социолог, рассматривавший компьютерную область преимущественно с точки зрения трудовых отношений (“Я не скрываю, — пишет он в указанной книге, — что сталярым сторонником партии программистов”).
       — Джоан Гринбаум (Joan Greenbaum) [Greenbaum 1979], бывшая программистка, исповедовавшая радикальные взгляды на общественные системы и часто цитировавшая Карла Маркса в подкрепление своихвысказываний.
       А идея, излагавшаяся в этих двух книгах, заключалась в том, что все эти важные вехи, о которых мы говорили выше, особенно методологические, имели целью сделать работу программистов рутинной и “деквалифицировать” их.
       Какие же аргументы они приводили?
       Прежде всего, оба автора в своих книгах опирались на исследование, в котором проводился опрос программистов и их начальников по поводу происходящего в мире программирования. Крафт усмотрел в результатах этих опросов ряд современных технических тенденций, которые он счел преднамеренными попытками начальников понизить квалификацию работников: структурное программирование, модульность и готовые программы, а также бригады под руководством главного программиста (метод организации, в чем-то сходный с медицинским, когда в хирургической бригаде есть один главный хирург). В каждом из этих случаев, по мнению Крафта, вместо роста производительности труда (который отмечали почти все работники отрасли) происходило усиление контроля руководства над процессом программирования (например, сокращение логических структур, разрешенных к использованию программистами, если это было структурное программирование; максимизация объема готового кода, используемого вместо написания новых программ, если речь шла о модульности; бригадная организация, которую он считал самым структурированным, иерархизированным и сословным типом организации из всех существующих в промышленном мире).
       Любопытно, что Крафт также рассматривал закрытость вычислительных залов (в те времена программистов не подпускали к компьютерам — на них работали профессиональные операторы) как очередную попытку администрации деквалифицировать своих работников — на этот раз, путем разделения “умственного” и “физического” труда.
       Поскольку сегодня компьютеры везде, даже если закрытые машинные залы действительно были попыткой руководства усилить контроль, то она явно закончилась полным провалом.
       Крафт мельком отметил, что сами создатели средств повышения производительности не стремились деквалифицировать программистов, но своей позиции при этом не изменил.
       Гринбаум в свой книге (позже) разделила точку зрения Крафта на структурное программирование, но обошла вниманием другие его тревоги вроде модульности и бригадной организации. Однако она тоже уверяла, что так называемые средства повышения продуктивности в действительности представляют заговор руководителей с целью усилить контроль программистов “под видом эффективности”, как гласило название книги.
       В дополнение к разоблачению заговора руководителей с целью деквалификации своих работников Крафт и Гринбаум с удивлением обнаружили, что программисты, хоть и жаловались на руководителей, вовсе не пытались сопротивляться или возражать им. Например, Крафт писал, что он был “поражен тем, что программисты регулярно принимали точку зрения своего руководителя, даже если она была очень далека от точного описания реального положения программиста”.
       Оба автора отметили тенденцию к утрате увлекательности процесса программирования (тема, к которой мы уже обращались в этой книге) и усилению контроля со стороны руководства — по их словам, опросы программистов систематически выявляли эту тенденцию. Гринбаум отметила, что “в 1960-е программистами были люди бунтарского склада — умные и творческие первопроходцы; сегодня они другие — технически подготовленные и усидчивые”. Крафт во многом вторит ей: “Еще не выросло второе поколение программистов, как программирование перестало быть сложной работой для творческих людей. Разделенное на части, упрощенное, оно стало массовым производством”. (Обратите внимание: здесь снова проявляется тревога о творчестве. Крафт и Гринбаум явно считали творческое начало необходимым для программирования).
       Конечно, легко судить задним числом, и сейчас мы понимаем, что большинство предсказаний Крафта и Гринбаум не сбылись. (Не стану хвастать, но кое-кто из нас понял это сразу!)
       — Структурное программирование — “средоточие усилий руководства подеквалификации программистов” — в целом исчезло с горизонта, вовсяком случае, теоретически, уступив место объектно-ориентированному программированию, которое никто не называет “деквалифицирующим”.
       — “Мало сомнений в том, что процесс фрагментации работы и деквалификации программистов будет продолжаться и усиливаться” — это утверждение выглядит смешным в сегодняшнем мире все болеесложных программных систем.
       — “Бюрократические формы управления особенно легко применить длярегламентации и контроля сопровождения программного обеспечения” — это заявление было неверным тогда и остается неверным сегодня, поскольку сопровождение по-прежнему не укрощено.
       Несмотря на все заблуждения Крафта и Гринбаум, нужно признать, что они подняли ряд интересных и важных вопросов, сделав это достаточно рано — больше тридцати лет назад. Любые попытки деквалифицировать программистов, несомненно, контрпродуктивны (и вредят творчеству) в мире программирования, каким мы его знаем сегодня (хотя едва ли кто-то может гарантировать, что руководители неспособны на такую уловку). Но их основная идея о том, что все творческие достижения в программировании в действительности были нацелены на деквалификацию и против творчества, довольно легко может быть опровергнута: достаточно лишь взглянуть, насколько сложной и по сей день остается задача создания программного обеспечения.
       Однако политическую проблему, поднятую Крафтом и Гринбаум, стоит запомнить. Если когда-либо руководители задумают сделать процесс программирования неквалифицированным, все творческие технические специалисты должны быть готовы дать им отпор.

Ссылки
       Greenbaum 1979 — “In the Name of Efficiency”, Temple University Press, 1979; Joan M. Greenbaum.
       Kraft 1977 — “Programmers and Managers”, Springer-Verlag, 1977; Philip Kraft.




<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:55 MSK


Постоянный адрес статьи:
http://az-design.ru/Support/SoftWare/l/GlassRob/04h2123.shtml