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

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

Поставка достойного программного обеспечения вовремя — это именно то, что в конечном итоге имеет значение для делового и профессионального успеха. Разработчикам никогда не следует принимать как данность нереалистичные сроки исполнения. Для выполнения своих истинных обязанностей перед работодателями им нужно научиться вести переговоры о сроках на основе компромиссов по объему работы и ее качеству.

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

Из журнала Software Development, том 2, № 7, июль 1994 г.

Городок Лорн (Lome) в Австралии — это ворота на Великую океанскую дорогу (The Great Ocean Road), которая вьется вдоль одного из самых прекрасных побережий в мире, под звуки оглушающего прибоя волн, мимо крутых обрывов и белоснежных морских берегов, по которым можно идти и на протяжении многих миль не встретить ни души. Когда я жил в Австралии, Викторианское отделение Австралийского компьютерного сообщества пригласило меня в Лорн на свою ежегодную конференцию. Я должен был помочь в судействе на их первом конкурсе по разработке программного обеспечения Software Challenge. Это был 6-часовой марафон по разработке приложений, на котором с помощью новейших инструментов быстрого визуального проектирования создавалось приложение для взвешивания грузовиков, работающих на переработке отходов. Это было третье соревнование по быстрой разработке, в котором я участвовал в качестве судьи, поэтому у меня уже был какой-то опыт в этом деле (см. главу 30). Например, я научился не издавать стоны в тех случаях, когда система вызывала исключения GPF,[38] и сдерживать свое волнение, когда соперники приближались к финишной ленточке, на больших оборотах завершая отладку. Кроме того, я узнал, что во время соревнований и сам смогу чему-то научиться, даже не соревнуясь.

Через час после начала соревнований я стал прохаживаться по «турнирной комнате», выделенной для программистов. По всей комнате расположились команды, состоящие из трех человек. Все они лихорадочно писа-ли код на Visual Works, PowerBuilder, SQL for Windows — все, за исключением одной группы невозмутимых молодых ребят из команды Ernst amp; Young. Когда я подошел к ним, я едва поверил своим глазам. Команда под руководством Крейга Брайта (Craig Bright) рисовала диаграммы! Вместо того чтобы согнуться над клавиатурами, как это сделали их соперники, они сгрудились вокруг листков бумаги. Они уточняли определение требований и усердно планировали архитектуру создаваемой системы. Заметив мой интерес, один из них дал мне копию своего боевого плана. Это был блокнот, содержавший краткое описание их обычной методологии, которая была модифицирована специально для этого соревнования. В блокноте все было расписано по пунктам, по этапам, с учетом промежуточных готовых компонентов. Это было полное, упорядоченное описание всего процесса быстрого проектирования. Даже в пылу гонки «ноздря в ноздрю», когда до сдачи результатов по более чем 200 функциональным пунктам оставалось меньше дня, эта группа демонстрировала невозмутимость под давлением и спокойно анализировала задачу и разрабатывала ее решение. Я был поражен.

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

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

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

Тем не менее, как говорится, был еще не вечер.

По результатам начальной оценки на последнем месте оказалась команда из Xpedite Professional Services Pty. Ltd. под руководством Сью Стивене (Sue Stevens). Пока другие команды усердно наращивали функциональность, они сосредоточились на деталях и тщательно продумывали код, направив все усилия на обработку ошибок и исключений. Однако этот метод, очевидно, не подходил для чрезвычайно плотного цикла разработки, установленного на соревновании. На полпути команда Xpedite решила поменять свою стратегию.

Когда подошло время финальной оценки, команда Ernst amp; Young начала объединять различные компоненты своей методично построенной системы. В спешке, когда все файлы переносились на одну машину, они нечаянно записали черновые версии поверх рабочих файлов. Мы все совершали такую ошибку, случайно перепутав направление копирования. Я и сам совершил ее всего за несколько месяцев до этого, когда переносил файлы Power Point, созданные для другой конференции. К счастью, у меня были резервные копии. К несчастью, у команды Ernst amp; Young их не было. Затерев большую часть своих данных, к финалу они пришли с меньшим количеством функциональных пунктов по сравнению с результатами в середине соревнований.