Вы можете оказаться в ситуации, когда вам точно известно, что нужно сделать и как это сделать. Перед глазами возникает общий план системы, и вы осознаете, что именно так это и должно быть. Но если вы попросите разрешения на проработку аспекта в целом, то столкнетесь с волокитой и пустыми глазами. Люди будут образовывать комиссии, бюджет должен быть одобрен, и все будет усложнено. Каждый будет держаться за свое кресло. Иногда это называется "изначальной усталостью". Пора вытаскивать камни из котла. Выработайте то, о чем вы реально можете попросить. Проработайте детали. Как только вы это сделаете, покажите людям и позвольте им удивиться. Они скажут: "Конечно, было бы лучше, если бы мы добавили". Положим, что это не важно. Расслабьтесь и подождите, пока они не начнут спрашивать вас о добавлении функциональных возможностей, которые вы задумали изначально. Людям легче присоединиться к грядущему успеху. Покажите им свет в конце туннеля, и они сплотятся вокруг вас [1].

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

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

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

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

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

• Энтропия в программах

• Программирование в расчете на совпадение

• Реорганизация

• Западня требований

• Команды прагматиков

• Просматривая черновик данной книги, Джон Лакос поднял следующий вопрос: солдаты постоянно обманывали крестьян, но в результате изменений, катализатором которых они стали, лучше стало всем. Однако, постоянно обманывая лягушку, вы наносите ей вред. Когда вы пытаетесь ускорить изменения, то можете ли определить, варите вы суп из камней или же лягушку? Является ли это решение субъективным или объективным?

Существует старый анекдот об американской фирме, которая заказала 100000 интегральных схем на предприятии в Японии. В условиях контракта указывался уровень дефектности: один чип на 10000. Несколько недель спустя заказ прибыл в Америку: одна большая коробка, содержащая тысячи интегральных схем, и одна маленькая, в которой находилось десять схем. К маленькой коробке был приклеен ярлычок с надписью "Дефектные схемы".

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

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

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

Обычно вы пишете программы для других людей. Часто вы вспоминаете о том, что хорошо бы получить от них требования [2]. Но как часто вы спрашиваете их, а насколько хорошими они хотят видеть эти программы? Иногда выбирать не из чего. Если вы работаете над передовыми технологиями, космическим челноком, или низкоуровневой библиотекой, которая будет широко распространяться, то требования будут более строгими, а варианты – ограниченными. Но если вы работаете над новым продуктом, то у вас будут ограничения другого рода. Маркетологам придется сдерживать обещания, вероятные конечные пользователи могут строить планы, основанные на дате поставки программы, а ваша фирма, конечно, будет ограничена в денежных средствах. Профессионалы не могут игнорировать требования пользователей – просто добавить к программе новые средства или «отшлифовать» еще раз тексты программ. Мы не призываем к паническим настроениям: одинаково непрофессионально обещать невероятные сроки и срезать основные "технические углы" чтобы уложиться вовремя.

Сфера действия и качество создаваемой вами системы должны указываться в части системных требований.

Часто вы будете оказываться в ситуациях, когда необходимо идти на компромисс. Удивительно, но многие пользователи предпочтут использовать программы с некоторыми недоработками, но сегодня, чем год ожидать выпуска мультимедийной версии. Многие IT-департаменты, имеющие ограничения по бюджету, могли бы согласиться с этим утверждением. Хорошие программы (но сегодня) зачастую являются более предпочтительными по сравнению с отличными программами (но завтра). Если вы заранее дадите другим пользователям поиграться с вашей программой, то часто их отзывы будут способствовать выработке лучшего конечного решения (см. "Стрельба трассирующими").