Другое соображение, о котором уже знают все программисты, но которое стоит повторить в обществе паковщиков с их победителями/проигравшими, заключается в том, что страх учиться на работе, который овладевает многими профессионалами, к нам не имеет никакого отношения. Мы стоим на пороге новой культурной эры. Оглядитесь и посмотрите, можете ли вы найти какое-нибудь способ сделать общество более интеллигентным. Вы когда-нибудь пытались купить лошадь? Еще долгое время не будет недостатка в работе для программистов, а когда будет, пусть все сделают роботы, а мы просто запрограммируем забавную графику, которая будет крутиться на наших карнавалах.

Фальшивая цель деквалификации

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

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

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

Программирование — это деятельность картостроителей. Если мы на самом деле вынуждены снова и снова писать одну и ту же программу, какая-нибудь светлая голова разработает готовый продукт (COTS), и программист будет не нужен.

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

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

Фильм «Субботний вечер и воскресное утро» (Saturday Night and Sunday Morning) начинается с показа рабочего в механическом цехе, занятом массовым производством компонентов на станках. «Девятьсот девяносто восемь… девятьсот девяносто, блин, девять…», бормочет он. Безысходность в том, что на самом деле это замечательно отражает положение в наше время. В те времена менеджеры платили рабочим за произведенные детали, передавая рабочим реальную силу и инициативу оптимизировать. В контексте программного обеспечения, нам не следует пытаться контролировать каждый аспект ввода 1000 строк одного и того же кода каждый день, нам следует спросить, почему работник до сих пор не написал макрос.

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

Держа в уме недопустимость деквалифицирующих программ, мы можем исследовать ряд мифов. Даже в сфере массового материального производства трудно сравнивать похожее с похожим. Например, мы можем сравнивать производство автомобилей за этот месяц и за прошлый месяц, и посмотреть в каком из них оно было лучше. А за прошлый год? Мы использовали тогда три разных вида блоков фар и предлагали пять окрасок. А десять лет назад? Каждый аспект технологии — антиблокировка тормозов, система управления автомобилем, воздушные мешки, состав топлива — все изменилось. Требуется настоящее озарение, чтобы просто рассказать, насколько мы богаче, чем предшественники! Академические попытки сравнения отношения заработной платы к цене за большой период времени скатываются к затратам на покупку кирпичей и хлеба, поскольку на протяжении многих столетий только эти вещи можно было всегда пойти и купить! Ну что мы можем поделать с поразительным экспоненциальным ростом «улучшения производительности», связанным с каждым новым «прорывом в технологии», который позволит вам набрать в штат проекта орангутангов и получать от них по 10 миллионов строк кода (10 MLOCS) в секунду. С чем на Земле можно сравнить этот рост? Нам приходится делать вывод о том, какие ужасные кучи мусора вываливают на нас в каждой статистически убогой работе.

А что такое «дружественные пользователю метафоры», означающие, что орангутанги теперь могут делать все, что им нравится, не требуя квалификации? Мы предполагаем, что истинная ситуация заключается в том, что некоторые сегменты рынка эксплуатируют миф о том, что возможна деквалификация в управлении сложностью, и предлагают продукты, которые при поверхностном изучении в течение короткого времени на самом деле кажутся «простыми в использовании». Трагедия в том, что на самом деле пользователям приходится выполнять операции типа конфигурирования адресов IP, брандмауэров, дисков, сканнеров, принтеров, совместно используемых дисководов, бюджетов и т. д. В этом месте мы обнаруживаем, что вместо компьютера, не требующего никакой квалификации, поскольку он претендует на роль еще одного предмета мебели типа стола, у нас оказывается компьютер, к которому обычные навыки работы с компьютером не применимы, поскольку, в конце концов, столу не нужно иметь сконфигурированных бюджетов, поэтому при его использовании нет необходимости в навыках конфигурирования бюджета пользователя стола. Мы неожиданно обнаруживаем, что даже в привычных ситуациях, когда вдруг решили установить новый IP без перезагрузки всей машины, «шароварные» системы, не отказывающиеся от звания компьютеров, оказываются более дружественными пользователю, чем так называемые «дружественные пользователю» штуковины.

Пути к отступлению

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

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

Мы предполагаем, что более эффективен следующий подход:

Во-первых, правильно разбейте на уровни. Выясните суть API каждого выявленного уровня. Во-вторых, примените совет Кена Томпсона (Ken Thompson), `Если сомневаетесь, применяйте грубую силу.' Определите раздутый, дорогой, неэффективный, тяжелый в реализации и ужасный способ обеспечения функциональности на каждом уровне. Не важно, что вся система в целом может просто не работать, если реализовать ее именно таким способом, поскольку этого не будет. В-третьих, обеспечьте достижение плато качества на каждом уровне. Пересматривайте время от времени свою незрелую методику и добавляйте в нее те хорошие части, которые у вас уже есть, а остальное заполняйте по возможности различными грубыми методами. В-четвертых, когда начнутся трудности, исходя из краткосрочных и среднесрочных потребностей заказчика и имеющегося времени сделайте на свой риск оптимальный выбор, какие части будут поставлены сырыми, а какие стоит сделать максимально хорошо.

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