"The Programmers' Stone (Программистский камень)" - читать интересную книгу автора (Carter Alan, Sanger Colston)

Глава 6. Техника безопасности

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

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

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

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

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

Картостроение в целом можно рассматривать как поиск, а особенность поиска состоит в том, что неизвестно, где это искомое лежит. Поэтому необходимо продолжать поиск до тех пор, пока объект не будет найден. Это гораздо легче сделать, если есть уверенность, что объект поиска действительно существует! В противном случае нужно предусматривать некоторый искусственный ограничитель, например, лимит времени. Тут приходит упоминавшаяся в начале "вера картостроителя" -- картостроители снова и снова открывают, что мир вокруг нас всегда проще, чем он кажется, при условии, что на него смотрят правильно. Иногда приходится раскрывать и изучать огромную скрытую сложность, но простота, необходимая достаточность "плато качества" в конце концов будет достигнута. Во всех ситуациях, которые можно найти в реальном мире, инвестиции картостроителя будут небесполезными, поскольку чем глубже видится скрытое, тем более стоящим (мощным) будет результат. Ситуации, которые не включают "естественный мир" в этом смысле (в конце концов, все в этом мире "естественное") -- это те ситуации, где сознание пытается создать локальную область иррациональности. Другими словами, где вы играете против другого ума, который случайно или осознанно старается привести вас в растерянность, стараясь показать только части всей системы (которая рациональна) так, что она выглядит для вас полной, но иррациональной. Поэтому паковщики, используя тот же самый язык, что и картостроители, при разговорах о мышлении, но подразумевая нечто другое, оказываются иррациональными. Когда картинка дополняется барьером картостроитель/паковщик, то мы снова возвращаемся в естественный мир, который включает противодействующий разум, и рациональность восстанавливается.

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

Итак, если в рассматриваемой ситуации присутствует еще один ум, всегда нужно учитывать его потенциальное противодействие (капризность, извращенность), чтобы гарантировать, что ситуация остается естественной. Может показаться, что нас как компьютерных программистов это повергает в паралич паранойи, поскольку многие проблемы, с которыми мы имеем дело, включают пользователей. Но дела не настолько плохи, поскольку если бизнес просуществовал столько времени, то это полностью естественное явление, которое подвластно картостроительному анализу, даже если никто из игроков на самом деле не понимает, что же на самом деле происходит. Однако помните, что короткоживущие транзакции бизнеса, такие как выставляемые на биржах только в короткий период быстрого изменения рынка заявки, не могут быть источником существования, и потому могут рассматриваться как продукт извращенных умов. Это не означает, что такие транзакции нельзя автоматизировать, -- просто это означает, что единственное, что приходится делать в этом случае -- это кодировать с помощью 4GL, или какое там еще средство быстрой разработки (RAD) вы используете, глупость, раз уж биржевые игроки просят вас это сделать, и пусть они беспокоятся о восстановлении собственного нормального поведения по отношению к таким же извращенным коллегам. Иногда организации, занимающиеся такими вещами, просят картостроителей взглянуть на ситуацию в целом и посмотреть, могут ли они найти какую-нибудь логику, если границы достаточно широки. Эти работы могут оказаться исключительно интересными и благодарными.

Идентифицировав ситуации, где нам следует отказаться от картостроения или переопределить проблему, мы остаемся с проблемой того, как долго мы будем идти к пониманию. Опыт картостроения приносит причудливую интуицию относительно интуиции, которая дает хорошее чутье на эти вещи. Не высказывайте оценки до того, как вы сами лично не убедитесь, что набрались достаточно опыта в их получении. Запишите вашу личную оценку перед началом картостроительной работы, и посмотрите потом, правильной ли она оказалась. Вы можете ошибиться несмотря на десятилетия опыта. Если бы работа была понята, то был бы создан автоматизирующий эту работу коммерческий продукт (COTS), не правда ли?

Картостроители часто сталкиваются с проблемами за много лет до их решения -- исследования, собранные в этой работе, заняли тридцать или шесть лет, в зависимости от того, как установить границы! Важно, что хотя есть ограничение на силы, которые можно направить на решение проблемы, нет ограничения на нахождение в состоянии готовности к этой проблеме, увеличивающем продолжительность жизни картостроителя. Нет позора в осознании длительности решения проблемы и уменьшении интенсивности попыток ее решения. Эта мотивация -- один из наиболее забавных примеров коммуникационного барьера картостроитель/паковщик. Для паковщика проект состоит из последовательности действий, которые требуется выполнить. Скорость, с которой выполняются действия, индицирует эффективность работающего. Работа над проблемой, от которой приходится отказываться (оставлять в покое), есть доказательство неорганизованности части работников. Следовательно, паковщики способны посмеиваться над "курьезными проектами" картостроителей, осознавая и, тем не менее, одновременно отвергая выдающиеся творческие результаты, которые картостроители регулярно выдают, поскольку им ясно, что они не были достигнуты "правильно", хотя у паковщиков нет предположений о том, каким должен быть "правильный" подход. Плохи дела. Образование за это в большом ответе.

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

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

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

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

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

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

Все это плохо для вас. Если вы работали в команде, обменивайтесь впечатлениями. Позвольте себе поговорить о чем-то полезном, например о своем подходе к проблеме, и чему вы научились в решении этого класса проблем, о специфике, с которой вы столкнулись. Что вы узнали о своей платформе? Это круто или так себе? Во время бесед, помните о контроле за настроением. Идея в том, чтобы спланировать вниз, а не взлететь наверх. Замените удовольствие от раскалывания проблемы празднованием вашего успеха.

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

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

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

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

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

Избегайте вовлечения в дискуссии без установленных базовых правил рационального мышления. Требуйте пространства для структурного маневра.

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

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

Будьте готовы использовать фразу: "Я не знаю". Этот простой честный поступок может положить конец помпезности и принуждению паковщиков, оставляя вам ясное понимание того, где вы находитесь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Будьте внимательны к присоединяющимся к команде новым работникам. Как и во всей этой работе, мы не подразумеваем под этим сентиментальную болтовню ритуала "добро пожаловать к нашему шалашу": мы подразумеваем нечто более практичное.

Команда обладает мысленной моделью работы. Посвятите в нее новичков. Убедитесь, что они понимают, что наступает Моделирование Ситуации и пригласите их. Объясните цель проекта, затем поясните весь используемый в проекте внешний (со стороны заказчика) и внутренний (мысленная модель) язык. Дайте обзор среды разработки, включающей инструменты, средства управления конфигурацией, компиляторы и т.д. Не заставляйте их спрашивать о каждой стадии.

Никогда не совершайте ошибку, заботливо обеспечивая им стол, стул, рабочую станцию, но не предоставляя бюджет (account) и конкретного дела. Хуже всего, когда приходящий на новый проект становится похожим на лимон [в смысле киснет - С.К.], а каждая следующая минута кажется длиннее предыдущей.

На BT (British Telekom) очень эффективно использовалась очень удачная практическая идея, которая состоит в представлении новичка официальному "назначаемому другу". Этот назначаемый друг -- равный ему по должности, кто уже давно работает в команде, и явно представляется как источник информации, которого "можно беспокоить" по поводу всего, что нужно узнать новичку. Одно из замечательных свойств этого подхода в том, что будучи равным, назначаемый друг будет знать правильные ответы на вопросы новичка. Бумага обычно лежит в коричневом шкафу, а листы A3 для больших диаграмм -- в зеленом ящике внизу.