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

Вы – великий артист. Вам также необходимо прислушиваться к внутреннему голосу, который шепчет «подожди». Если вы садитесь, начинаете набирать текст, а у вас в голове возникает неотступное сомнение, прислушайтесь к нему.

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

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

Каждый испытывает страх перед чистым листом бумаги. Начало нового проекта (или даже новый модуль в существующем проекте) может лишить вас спокойствия. Многие из нас предпочли бы отложить момент связывания себя обязательствами. Но вы же не можете заявить, что вы просто оттягиваете начало работы?

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

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

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

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

• Обсудите синдром "страха начала работы" с вашими коллегами. Испытывают ли они тот же самый синдром? Принимают ли они его во внимание? Какие приемы они используют для его преодоления? Может ли группа преодолеть сопротивление отдельной личности, или это будет давлен и ем со стороны команды?

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

Составление спецификации – это большая ответственность.

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

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

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

Проблемный вопрос для вас. Напишите короткую инструкцию по завязыванию бантиком шнурков на ботинках. Попробуйте!

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

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