Разработка
Григорий Петров: Иллюзия визуального программирования
Модель «у нас не получается, потому что инструмент плохой» проста, удобна и наш мозг с удовольствием создает ее при отсутствии фундаментальных знаний.
Уже много лет мы слышим высказывания «скоро программисты будут не нужны». Об этом говорят с экранов телевизоров, пишут в блогах и на хабре (оцените рейтинг в минус пятьдесят два). Идея того, что скоро «программировать будут уметь все» и «можно будет мышкой визуально щелк-щелк и готово» или «просто сказать компьютеру, что делать, а дальше он сам как-нибудь» не нова. В той или иной форме я наблюдаю такое последние двадцать лет. В университетах уважаемые профессора из года в год силами студентов создают «универсальные всемогуторы системы визуального программирования», а примерно раз в год очередная крупная компания анонсирует «создавайте игры сайты мобильные приложения, не умея программировать!». Кажется, вот-вот наступит светлое будущее и все станет просто.
Нет, не станет.
Есть подозрение, что такие периодически появляющиеся идеи — следствие неправильного определения места, где лежит сложность. Судите сами. Есть проблема сложности, о которой я уже давно рассказываю. Пока нет массовой системы образования, которая рассказывала бы об этом начинающим разработчикам в простой и понятной форме. Участники разработки видят проблемы, вызванные сложностью, начиная от необходимости в специально обученном «тыжепрограммисте» и заканчивая непредсказуемостью сроков.
А человеческий мозг устроен так, что постоянно строит модели окружающего мира. Собственно, через эти модели мы с окружающим миром и взаимодействуем. У мозга просто нет такой опции как «не получается, потому что не получается». Если человеку в голову пришла мысль о том, что с разработкой что-то не так, то модель уже есть. И какая это будет модель, зависит от множества факторов. Популярно — «криворукий программист», «заказчик идиот». Эзотерически — «плохой день», «невезение». И, наконец, самое мое любимое — «плохой инструмент».
Модель «у нас не получается, потому что инструмент плохой» проста, удобна и наш мозг с удовольствием создает ее при отсутствии фундаментальных знаний. Не получилось забить шуруп? Плохой шуруповерт. Не получилось сыграть на гитаре? Дешевая и не настроенная гитара с плохими струнами. Программы сложнее hello world разваливаются под весом собственной сложности? Плохой язык программирования. Вот было бы такое чтобы мышкой щелк-щелк из готовых блоков и все получается — вот тогда бы мы ух!
Иллюзия плохого инструмента — простая модель, с помощью которой мозг поддерживает в нас более-менее логичную картину окружающего мира. Психологически намного комфортнее объяснить неудачи внешними причинами, нежели признать, что тут надо учиться много лет и вообще все не так просто.
В области разработки софта это особенно актуально из-за молодости отрасли. Быстро «найдя» причину своих неудач в «плохом» инструменте, разработчики и менеджеры начинают с воодушевлением создавать инструменты «хорошие». Как нетрудно догадаться, первые же версии таких инструментов показывают всю несостоятельность их предположений: сложная программа в среде «визуального программирования» быстро превращается во взрыв квадратиков и стрелочек, разобраться в котором еще сложнее, чем в тексте программы.
Сложность разработки, так же как и во многих других отраслях, кроется не в инструменте, а в формулировке. Большинство людей без предварительного обучения не смогут нарисовать в фотошопе красивую картинку, хотя фотошоп вполне себе «простой, визуальный» и не требует много лет изучать языки программирования. Только вот сложность рисования красивых картин — она в самих картинах, а не в используемых инструментах. Большинство людей без предварительного обучения не смогут написать увлекательный роман в текстовом редакторе, хотя текстовый редактор вполне себе «простой, визуальный» и не требует много лет изучать языки программирования. Сложность написания увлекательных романов — она в самих текстах, а не в используемых инструментах. Большинство людей без предварительного обучения не смогут создать сложную программу ни в «визуальном редакторе», ни рассказывая компьютеру, чего они хотят. Сложность программ, так же как картин и романов — в формулировке, а не в инструменте. Хотя наш мозг и пытается нам доказать обратное, чтобы не было так печально.
Практические рекомендации
Это колонка об управлении разработкой, поэтому, если я рассказываю много теории, то ее можно как-то использовать на практике. Знание о ловушке «негодного инструмента» крайне полезно при общении с разработчиками, менеджерами, да и вообще любыми участниками увлекательного процесса создания программ.
- Как только вы услышите «а вот давайте создадим универсальный инструмент, чтобы потом легче было!» — вспомните эту статью. В статье про YAGNI я рассказал о хомяках не все, чтобы не делать ее слишком длинной. Еще одна причина, почему программисты начинают создавать код «про запас» — это как раз попытки создать «правильный» инструмент. Такая работа редко идет на пользу. Обычно после длительной разработки программист тихо «закапывает» получившееся, так как оно не оправдывает его надежд. Хуже, когда созданные инструменты остаются в проекте и приносят в него плохую, не нужную магию.
- Мозг постоянно строит модели окружающего мира, поэтому у него великолепно получается генерировать оправдания. При общении с разработчиками вы будете многократно слышать про плохие инструменты, компиляторы, операционные системы.… Иногда, конечно, инструмент действительно плох. Но чаще всего разработчики неосознанно попадают в описанную ловушку своего мозга и начинают винить инструмент просто потому, что мозг так работает. Чтобы не загонять коллег в такие ловушки и поддерживать конструктивную беседу хорошо подходят простейшие психологические трюки, о которых я уже писал.
Ловушка визуального программирования — одна из множества мелочей, которые делают разработку программ не самым простым занятием. Более того, в ряде случаев создание дополнительного инструмента, включая визуальный — это то, что надо делать. Например, при разработке редактора уровней для игры. Задача тим лида — следить за создаваемыми командой инструментами и вовремя останавливать попытки создать «универсальный всемогутор» чтобы все «наконец-то стало просто и понятно».