The Programmers` Stone (Программистский камень)

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

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

Все успешные начинания -- "дела скунса". Поэтому есть неудачные начинания. Усилия "дел скунса" могут сменить большой риск потери управляемости [из-за разбухания проекта - С.К.] на малый риск "пионерства" [в смысле быть первым - С.К.]. В таких ситуациях это может оказаться эффективным средством управления риском.

Глава 3. Программист за работой

Подходы, методологии, языки

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

На одном конце этого спектра расположены продукты COTS (Commertial Off The Shelf - Коммерческие, взятые с полки). Загрузи его, запусти его, работа сделана. На другом -- набор команд процессора, который позволяет нам выжать из железа все, на что оно физически способно. Между этими крайностями располагаются различные промежуточные семантики, которые упрощают поиск взаимосвязей ограничивая семантику.

В этих терминах, язык -- это произвольный набор (ящик инструментов -- kitbag) семантик. Cи - язык, но также и Excel -- язык, как и средства создания интерфейса пользователя (GUI builders). Эти наборы лежат, но не дают никакого намека, как использовать их содержимое. Языки специализируют по проблемным областям, чтобы достигнуть большой вероятности получения более простых взаимосвязей для любой проблемы из выбранной области. Чтобы решить, какую из двух семантик (языков) выбрать, обычно нужно спросить, какая из них требует более простых взаимосвязей (более простой программы), чтобы выполнить работу. За исключением самых тривиальных случаев, это требует знакомства с обоими наборами семантик на практике.

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

Подход заключается в совете, даваемом одним опытным картостроителем другому, о том, как лучше всего решать проблему какого-то типа. Это приглашение посмотреть на мир определенным образом, даже если это выражено как процедурный рецепт. Предписание "Получи диаграмму (Data Flow Diagram) изменения начислений по неделям" в книге "Как построить систему печати платежной ведомости" (How To Build A Payroll System) на самом деле выглядит так "Ограничь рассмотрение до систем с понедельным начислением, и выведи перечень этих начислений".