«Программист должен обладать способностью первоклассного математика к абстракции и логическому в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов с трезвой практичностью экономиста» Академик А.П. Ершов
Предисловие
Есть распространенное мнение: «если бы строители строили дома так же, как программисты пишут программу — первый залетевший дятел разрушил бы цивилизацию». С подачи индийского гуру-программиста Мурали Кришна Чимутури (Murali Krishna Chemuturi), Интернет настойчиво приписывает авторство этой цитаты Джеральду Вайнбергу (Gerald Weinberg), хотя на личном сайте Джеральда она не ищется. Скорее всего, человек, который первый заговорил о психологии в программировании, к этому высказыванию не имеет никакого отношения. И вот, почему.
Это изречение – пример демагогического приемчика. Здесь пропущена главная посылка: разработка ПО это то же самое, что и строительство домов. Эта посылка, по умолчанию, подразумевается как достоверный факт, который не требует доказательства. Применение этого приемчика заставляет неискушенного читателя делать ложный вывод о том, что у программистов, в отличие от строителей, руки растут не из нужного места.
Материальное производство (обработка объектов физического мира) насчитывает десятки тысяч лет истории. На этом пути был накоплен колоссальный объем знаний естественных наук: математики, физики, химии, географии, геологии, биологии и проч.
Позволю крамольную мысль. Разработка ПО – новый вид человеческой деятельности, история которой насчитывает чуть больше полувека. В посте я хочу представить свое видение принципиальных особенностей разработки ПО, которые отличают ее от материального производства и следствий, которые из них вытекают.
Особенности и их следствия
Особенность #1. Программирование – интеллектуальная деятельность
Упрощенно, путь от идеи нового здания, моста, автомобиля или ракеты до ее реализации выглядит следующим образом: НИР-ОКР-завод. В верхней части этой пирамиды находятся отраслевые НИИ, которые производят идеи и занимаются проектированием новых изделий. На втором этаже пирамиды работают конструкторы в конструкторских бюро, в задачу которых входит реализация нового проекта в чертежах деталей, спецификации материалов, технологиях изготовления и сборки. На нижнем уровне находятся производственные мощности — заводы, на которых инженеры и рабочие воплощают «в железе» эти чертежи, спецификации и технологии.
То, что производят программисты, нематериально – это brainware, результат коллективного мыслительного процесса проектной команды, материализованный на одном из языков программирования.
Гуру программирования Ф. Брукс в 1975 году писал: «Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов».
Если и проводить аналогию, то программисты работают исключительно на вершине описанной пирамиды. Программирование – это проектирование и только проектирование. Роль конструкторского бюро для программного проекта играют компилятор и сборщик программ. А программистским аналогом завода, который переводит конструкторскую документацию в продукт, доступный потребителю, служит вычислительный комплекс, на котором выполняется созданная программа.
Следствие #1. Производительность программистов с одинаковым опытом по-прежнему будет отличаться в десятки раз.
Брукс говорил об отличие производительности в 10 раз. Роберт Гласс ссылался на эксперименты, в которых был продемонстрирован разброс производительности в 27 раз.
Никто не знает, каким местом человек думает и, как он этим местом это делает. В любой другой отрасли за спиной работника-стахановца сразу же поставили специалиста по научной организации труда, который бы составил карту прогрессивного технологического процесса и установил новые производственные нормативы. А что увидит это специалист из-за спины программиста? Habrahabr.ru?
Следствие #2. Статистика провальных проектов в разработке ПО вряд ли изменится в обозримом будущем.
Давайте вспомним, сколько НИР так и остались на бумаге, не дойдя до ОКР, и сколько еще ОКР закончилось закрытием тематики. Полагаю, что процент инноваций, дошедших до производства от общего числа проектов, выполненных в отраслевых НИИ, будет сравним с процентом успешных программных проектов. И это при том, что ученые в НИИ опираются на достаточно хорошо изученные законы математики, физики и химии, а в программировании аналогичные законы еще не открыты. И в этом состоит вторая особенность программирования.
Особенность #2. Отсутствие законов
Разработка ПО, ИМХО, по ошибке отнесена к инженерии. Инженерия – это там, где применяются достижения науки, техники, используются законы естественных наук для решения конкретных проблем и достижения поставленных целей.
В разработке ПО еще не открыты свои законы Ньютона, нет уравнений Лагранжа или хотя бы сопромата, которые помогли бы нам спроектировать и доказать правильность архитектуры новой нетривиальной программной системы. Наработки математиков в области логики, теории информации, численных методов, реляционной алгебры, теории графов и некоторых других дисциплинах не покрывают сложность задач промышленного программирования.
Даже выдающиеся программисты не возьмут на себя смелость утверждать об архитектуре новой программной системы то, что она будет успешной. Хотя в программировании уже накоплен определенный опыт провалов, который может позволить искушенному программисту увидеть в архитектуре новой системы антипаттерны — источники серьезных будущих проблем. Но не более того.
Существующее состояние Software Engineering напоминает большую поваренную книгу с многочисленными описаниями рецептов однажды успешно приготовленных блюд из ингредиентов, которых никогда в будущем не будет. Завтра новой системе будут другие вычислительные машины, технологии, языки программирования, инструменты и окружающее ПО, новые проблемы взаимодействия с которыми обязательно придется решать.
Следствие #3. Программирование – это ремесло.
А поскольку это ремесло, то человек, научившийся писать программы на C ++, будет также далек от профессионала, как ученик третьего класса средней школы, научившийся писать по-русски, от А. С. Пушкина или Ф. М. Достоевского. Путь к мастерству в ремесле лежит только через опыт. Нельзя научиться разрабатывать программные продукты, читая книги.
Следствие #4. Свобода – необходимое условие работы программиста.
В силу отсутствия открытых законов большинство решений программистских задач находится методом проб и ошибок. У программистов должно быть право на ошибку. Это нормальный атрибут творческого поиска. На ошибках учатся. Умный не тот, кто не делает ошибок, а тот, кто их не повторяет.
Одним из элементов свободы является отсутствие жестких сроков на выполнение задачи. Для профессиональных управленцев отсутствие жестких сроков может звучать как нонсенс, но в творческой деятельности это один из обязательных элементов. Бессмысленно заставлять программистов работать больше, устраивать сверхурочные авралы и субботники. Работать больше, это совсем не значит — работать продуктивнее. Скорее наоборот. Излишнее давление и суета приводят к непродуманным решениям и многочисленным последующим переработкам.
Особенность #3.Отсутствие средств визуализации
Для программных продуктов еще не придумали адекватные инструменты визуализации. Об этом говорил еще Бркус, почти 40 лет назад. Поэтому разработчики ПО часто уподобляются слепым монахам из буддийской притчи.
Следствие #5. Необходимость постоянных коммуникаций участников разработки.
Из опыта. В среднем у каждого участника проекта разработки ПО на всякие разговоры уходит 50% рабочего времени. У нас это называется «синхронизация ментальных моделей». Известно, что слова, тембр и интонация передают только чуть меньше половины информации. Поэтому на передачу информации удаленному участнику команды тратиться в два раза больше времени. Отраслевая методика COCOMO II учит, что если проект выполняется распределенной командой, то его трудоемкость надо умножать на 1,5.
Следствие #6. EQ важнее, чем IQ.
Способность к диалогу и эффективному взаимодействию, умение рассуждать, задавать вопросы, анализировать ответы, искать взаимовыгодное решение в конфликтных ситуациях обязательное качество командного бойца. Креативность и эффективность человека на 80% завися от уровня его эмоционального интеллекта (EQ) и деятельности правого полушария, которое отвечает за целеустремленность, волю, эмпатию, интуицию, способность к эвристическим суждениям.
Если у вас недостаточный EQ, не отчаивайтесь. В отличие от IQ, который формируется в ранней молодости и затем практически не меняется, EQ можно повышать на протяжении всей жизни.
Заключение
Для коллективного программистского творчества скорее уместна аналогия с созданием художественного кинофильма или театрального спектакля. Я полагаю, что количество провальных проектов в этих областях ничуть не меньше, чем в программировании. Дай Бог, если хотя бы треть кинофильмов не «ложится на полки» после первого показа.
И еще одно, что роднит программные проекты с кинематографом. Наличие даже самых звездных актеров не обеспечивает успех фильма. Только талантливый режиссер способен организовать и вдохновить актеров на создание шедевра, открыть новые звезды. А талантливых режиссеров, как, впрочем, и талантливых менеджеров программных проектов, к сожалению, не так много, как хотелось бы.
Автор: craft_brother
