Здесь проявляется паттерн: не ставь телегу впереди лошади. Если мы занимаемся сбором статистики без ясного понимания того, что мы делаем, то важный инструмент превращается в упражнение по подсчету зерен. Без разумной интерпретации люди занимаются получением артефактов в статистике, а не улучшением выполнения работы, используя статистику в качестве индикатора этого улучшения. Это не порок машинных инструментов. Без ясной кибернетической модели "плохая" статистика становится палкой, которая бьет людей: "Это люди плохие и следует посмотреть на их грехи. Это наверняка поможет добиться улучшения". Начнутся собрания, на которых будут пытаться разными способами подсчитать ошибки, чтобы "улучшить ситуацию", но создаваемая программа все равно не будет работать.
С помощью метрик, как и со всем остальным, мы ничего не сможем сделать, отвергая нашу ответственность в пользу процедуры.
Использует ли разработчик социально нормальную стратегию паковщика, или хорош в картостроении, он будет подвержен сильному влиянию надежды на инструменты. Паковщик смотрит на инструмент как на машину, которая выполняет работу, как копир в углу офиса. Действительно, таким образом большинство из нас использует компиляторы -- засунь исходник с одной стороны, исполнимый код выйдет с другой. Обычно здесь все нормально, хотя день, проведенный за чтением руководств по компилятору и компоновщику, многократно окупится.
Паковщики любят большие дорогие инструменты со сложным интерфейсом и неимоверно сложным внутренним состоянием. Они обещают делать все и требуют недель на установку и настройку. В них содержится множество сложных технологий. Все эксперименты заканчиваются плачевно. Среди шума легко потерять этот замалчиваемый глянцевыми рекламными проспектами факт. Программирование - это операция по обработке данных, которую этот продукт автоматизирует для вас, поэтому вы можете носить галстук, много улыбаться и быть "профессионалом" -- вот что написано в рекламе.
Картостроители не рассматривают инструменты как копиры, они рассматривают их как протезы ума. Они -- мыслительный эквивалент Рипли из фильма "Чужие" (Ripley in Aliens), взятой в рубку космического корабля, чтобы победить главное чудовище. Картостроители оставляют за собой ответственность за все и используют инструменты для расширения своего кругозора и силы мысли. Картостроители не любят помещать все свои штучки в один инструмент, где их другой и не найдет. Им нравятся коллекции инструментов и чтобы ввод/вывод был текстовым и анализируемым (parseable), так чтобы они могли объединять (соединять) инструменты вместе.
Картостроители считают разумным писать небольшие программы на лету, чтобы манипулировать исходным текстом. Они отдают себе полный отчет в том, что делают хорошо они, а что хорошо делают компьютеры, используя свои собственные суждения, когда проверяют каждый вызов, скажем, функции, чье определение они изменяют, а компьютер гарантирует, что они проверили каждое появление вызова функции в тексте.
Имеются великолепные инструменты картостроителя -- браузеры, инструменты восстановления исходного текста (reverse engineering - дизассемблеры), даже некоторые "интегрированные среды разработки" (IDE). Однако, стоит держать в уме, чего можно достичь на большинстве систем просто с помощью нескольких скриптов и системного редактора. Одна команда пришла в волнение, когда им показали инструменты, которые давали им все возможности для просмотра и средства получения перекрестных ссылок. Но отличия между этими инструментами и пучком скриптов, которые у них уже были, и на написание которых понадобилось одно утро заключались в том, что:
Инструменты нельзя было модифицировать.Инструменты стоили 20,000 фунтов стерлингов плюс 5,000 фунтов стерлингов за рабочее место.Инструменты требовали несколько недель на установку и настройку.Инструменты были с графическим интерфейсом.
Когда кто-то с энтузиазмом рассказывает о новом продукте, остановитесь на минутку и проверьте, может быть правильной реакцией будет: "Ну и что?"
Можете себе вообразить Марго Фонтейн (Margot Fonteyn) с ногами и руками в гипсе и парой кандалов на лодыжках? Очень не грациозно.
Одна из наигрустнейших вещей -- позволить молодым разработчикам начать работу с пошагового подхода, который позволяет им начать создание программы, а затем по мере работы знакомить их с идиомами, позволяющими отобразить проблему на язык и подход. Основной момент в том, что используемые ими языки и подходы предназначаются для отражения предметных областей. С большим удивлением наблюдаешь, как они начинают рассматривать и описывать проблемы в терминах программных структур. Черта, разделяющая хороший способ описания проблемы и хороший способ ее решения, размыта, а использование объектных подходов и языков максимизируют это размытие.
Но как раз в момент, когда они могут стать умелыми и изобретательными, эти разработчики начинают чувствовать себя виноватыми, поскольку им следует "видеть проблему, а не решение". Поэтому они начинают своеобразный спектакль, где они утверждают, что не могут видеть сути вещи, о которой они говорят. Если перед ними поставлена специфическая цель, например обеспечение независимости от реализации, этот маневр может быть проделан с большой ловкостью, поскольку они точно знают, что они не знают и это становится упражнением в строгости, но если они просто стараются быть глупее, чем они есть на самом деле, когда они собираются остановиться?
Если ты хороший, то ты просто находка для своей организации, поскольку можешь сжато изложить, что решение Y хорошо для проблемы X и почему, следующий вопрос, пожалуйста!
Это не преступление -- быть умелым и квалифицированным.
Разбор полетов формализован как составная часть процесса многих организаций. При этом организация распознает ситуации, где все пошло наперекосяк, смотрит на то что произошло, чтобы понять, что же произошло и гарантировать, что это не произойдет снова. У картостроителей нет проблем с этим -- это обычное дело. Но для паковщиков -- это совершенно необычная вещь, с которой приходится сталкиваться в работе.