Ларри Константин - Человеческий фактор в программировании

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

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

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

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

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

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

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

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