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

И разница немалая — это как Сальери и Моцарт. Одно исследование за другим показывают, что лучшие проектировщики создают структуры, которые быстрее, меньше по размеру, проще, понятнее и разработаны меньшими усилиями. Различия между выдающимся и средним достигают порядка величины.

Нетрудно проследить, что ряд хороших и полезных программных систем проектировался комиссиями и создавался с помощью проектов, состоявших из многих частей. Но программные системы, вызвавшие восхищение страстных поклонников, являются продуктом одного или небольшого числа выдающихся проектировщиков. Посмотрите на Unix, APL, Pascal, интерфейс Smalltalk и даже Fortran — с одной стороны, и Cobol, PL/I, Algol, MVS/370 и MS-DOS — с другой (рис. 16.1).

Рис. 16.1 Имеются ли у этих продуктов страстные поклонники?

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

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

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

Как растить выдающихся проектировщиков? Место не позволяет обсуждать это пространно, но вот некоторые очевидные шаги:

• Систематически и как можно раньше выявлять первоклассных проектировщиков. Лучшие — не всегда самые опытные.

• Назначить наставника, ответственного за рост перспективного проектировщика и тщательно следить за его карьерой.

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

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

Об оборотнях и прочих мифических ужасах

«Серебряной пули нет: сущность и акциденция в программной инженерии» (глава 16 данной книги) первоначально была заказным докладом для конференции IFIP (Международной федерации по обработки информации) 1986 года в Дублине и была опубликована в ее трудах. [1] Журнал «Computer» перепечатал ее под обложкой в готическом стиле, иллюстрируя кадрами из фильмов, таких как «Вервольф из Лондона», [2] и снабдив боковым полем «Убить вервольфа» с изложением современной легенды о том, что справиться с ним можно только с помощью серебряной пули. До публикации я не знал об иллюстрациях, и для меня было неожиданностью, что серьезная техническая статья была так красочно издана.

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

Серебряная пуля все-таки есть — ВОТ ОНА!

«Серебряной пули нет» утверждает и доказывает, что в течение десятилетия (с момента публикации статьи в 1986 году) ни одна разработка в области техники программного обеспечения не позволит повысить производительность труда в программировании на порядок. Из этого десятилетия прошло уже девять лет, и можно посмотреть, насколько сбывается предсказание.

В то время как «Мифический человеко-месяц» породил частое цитирование и мало споров, статья «Серебряной пули нет» вызвала статьи с опровержениями и письма в редакции журналов, поток которых не прекратился и по сей день. [3] Чаще всего критикуется главное утверждение о том, что волшебного решения нет, и мое ясно выраженное мнение о том, что его и быть не может. Большинство соглашается с основной частью моих аргументов в «СПН», но затем заявляет, что в действительности серебряная пуля для программного зверя существует, и изобрел ее автор. Перечитывая сегодня ранние отклики, не могу не отметить, что патентованные средства, столь энергично предлагавшиеся в 1986 и 1987 годах, не возымели эффекта, на который претендовали.

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

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

Неясное изложение влечет непонимание

Судя по некоторым откликам, мне не удалось четко изложить свои аргументы.

Второстепенное свойство (accident). В резюме главы 16 я постарался со всей возможной ясностью изложить основные аргументы «СПН». Некоторые, однако, были смущены терминами второстепенное свойство (accident) и несущественный, второстепенный (accidental), которые я использовал в старом употреблении, восходящем к Аристотелю. [4] Под accidental я не имел в виду «случайный» или «относящийся к несчастному случаю», а скорее, «несущественный», «побочный» (incidental) или «принадлежащий» (appurtinent).

Я не хочу порочить роль случайности при разработке программ. Вслед за английским драматургом, автором детективов и теологом Дороти Сэйерс (Dorothy Sayers) я рассматриваю всякую творческую деятельность, как состоящую из: а) формулирования концептуальных конструкций, б) воплощения в реальном материале и в) диалога с пользователем в реальной жизни. [5] Та часть построения программы, которую я назвал сущностью (essence), состоит из умственной работы создания концепутальной конструкции, а та, которую я назвал второстепенной (accident), есть процесс ее воплощения.

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