Психбольница в руках пациентов

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

* * *

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

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

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

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

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

* * *

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

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

* * *

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