Существует множество факторов, которые могут стать катализатором плохого программного обеспечения: от используемых инструментов, общения в команде, личной заинтересованности разработчиков в успехе до методологии тестирования.
Я предполагаю, что среди них есть одна главная проблема, толчок к созданию плохого программного обеспечения, из которого берут начало почти все остальные — воображаемые проблемы.
Большинство сложных или неработающих программ не предназначались быть чрезмерно сложными или нефункциональными. Они просто создавались для того, чтобы делать что-то другое, чем предполагаемая цель.
Допустим, вы — ведущий подкастов, который хочет создать собственный веб-сайт, на котором вы сможете продавать свои продукты, зарабатывать на рекламе без вмешательства третьих лиц и, что самое главное, поставлять подкасты, видео и статьи своей аудитории.
Требования к вашему маленькому веб-приложению могут выглядеть примерно так:
- Быстрое время загрузки в Северной Америке, с потоковой передачей и загрузкой подкастов в режиме реального времени.
- Не сбоит и не зависает в течение первых 15 минут у 99.99% пользователей, желательно никогда не сбоит и не зависает.
- Хорошо интегрируется с Google Adwords и, возможно, с другими сторонними поставщиками рекламы, если будет время.
- Использует динамические ссылки на последние продукты в магазине Zazzle и, если возможно, дает рекомендации пользователям на основе контента, который они потребляли.
- Интеграция с Facebook* Live. Если легко создать альтернативное решение для стриминга, не требующее Facebook, еще лучше.
Вы даете эти спецификации команде подрядчиков и немного обсуждаете их. Кажется, что все согласны. Однако, когда через два месяца они возвращаются с минимально жизнеспособным продуктом, ваше лицо краснеет. Вы только что потратили 15,000 долларов на кусок мусора. Вы хотите вернуть свои деньги.
Когда вы в первый раз открываете приложение, экран замирает. Вы спрашиваете, как выбрать вид рекламы, которую можно размещать на сайте, а вам показывают раздел с уродливым, труднопонимаемым пользовательским интерфейсом. Половина ссылок на ваши товары на Zazzle не работают или у них не хватает изображений, а прямая трансляция на Facebook работает с задержками!
Но команда разработчиков в замешательстве от вашего гнева — что вполне справедливо с их точки зрения, ведь ради вас они прошли через ад и обратно.
Они вложили всю душу в создание этого приложения, и оно обладает удивительными возможностями:
- Современная система рекомендаций.
- Алгоритм, генерирующий расшифровку всех ваших потоков в режиме реального времени.
- Ваша первая страница загружается за время менее 200 мс по всему миру
- Протокол потокового вещания и клиент, созданы практически с нуля, на случай, если вы не хотите полагаться на Facebook live.
- Сервис, позволяющий легко интегрировать более 20 рекламных бирж.
Проблема в том, что вы думали, что запросили основной продукт с парой дополнительных функций, если их будет достаточно легко реализовать. Тем временем команда разработчиков услышала кое-что другое. Они услышали о некоторых интересных задачах, которые они могли бы решить… и о множестве скучных, базовых функций, которые они не удосужились протестировать должным образом или о которых они не заботились.
Что еще хуже, вы не общались с разработчиками напрямую — вы общались через игру «Испорченный Телефон». Вы говорили с продавцом, тот проводил встречу с каким-нибудь руководителем среднего звена, тот писал бизнес-спецификации и передавал их PM, тот писал технические спецификации и передавал их руководителю команды или архитектору, который затем, наконец, начинал разрабатывать продукт со своей командой — каждый из них по ходу дела вносил в него немного своей собственной изюминки.
Воображаемые проблемы — интересны
Воображаемые проблемы зачастую решать интереснее, чем реальные. Чрезвычайно умные люди играют в соревновательные игры, строят и решают математические задачи, пишут книги, цель которых — ответить на абстрактные вопросы о состоянии человека, и все это бесплатно. Однако посредственный программист, скорее всего, возьмет с вас изрядную сумму за создание простого приложения для Android. Это не потому, что посредственных программистов найти сложнее, чем гениев, а потому, что первый вид деятельности приносит удовольствие, а второй может быть довольно скучным.
Большинство программистов хотят получать деньги и одновременно развлекаться. Конечно, определение понятия «удовольствие» у всех разное, но для многих инженеров оно сводится к решению интересных и сложных задач, которые находятся в пределах разрешимости.
Если дать умному человеку слишком много скучных задач, которые невозможно автоматизировать, он сойдет с ума. Однако человеческий мозг, после миллиардов лет эволюции, весьма талантлив в сохранении рассудка. Подобно тому, как жертвы детских трудностей или насилия могут найти спасение в фантастических книгах, жертвы корпоративного программирования или фриланс веб-разработки могут найти спасение в решении воображаемых проблем.
Количество воображаемых проблем, которые может создать для себя инженер-программист, зависит от его воображения и от сложности реальных проблем, которые он должен решать.
Следует отметить, что эта проблема характерна не только для разработчиков. Менеджмент, отдел продаж, отдел кадров, отдел поддержки, юридический отдел и даже бухгалтерия имеют свои собственные уникальные способы создания воображаемых проблем. Они пытаются слишком сильно вовлечь себя в принятие решений даже тогда, когда их присутствие на митинге является лишь формальностью или вообще не требуется. Они чрезмерно акцентируют внимание на незначительной проблеме, связанной с их ролью, или нанимают команды намного больше, чем необходимо, чтобы проиллюстрировать свою важность.
Когда проблемы тупые, умные люди найдут способ справиться с ними.
А коммуникации растянуты
Но воображаемые проблемы — это не только результат скуки разработчиков. Они также являются результатом длинных цепочек коммуникаций.
Когда я только начинал работать с клиентами на фрилансе, я не мог позволить себе быть особенным. Это означает, что у меня были цепочки электронных писем длиной более 100 сообщений, в которых обсуждались незначительные детали внутренних MVP. Бывало, что люди меняли все требования к проекту в течение недели. Клиенты задавали такие вопросы, как «Можно ли это вывести на ICO?» или «Можно ли добавить сюда A.I.?».
Конечно, большинство клиентов более сообразительны, но, несмотря на это, им часто не хватает знаний, необходимых для формулировки или построения некоторых требований. Это нормально, поскольку часть моей работы в качестве «компьютерщика» заключается в том, чтобы помочь людям понять, что им нужно, а что нет, на основе их сценариев использования. Но определить, что нужно, может быть гораздо сложнее, когда между вами и клиентом есть несколько уровней.
Требования меняются, потому что кто-то либо неправильно понял намерения, либо потому что кто-то пытался справиться с вышеупомянутой скукой.
Большинству компаний нравится иметь специалиста по продажам, который ведет переговоры с потенциальными клиентами, договаривается о цене и описывает возможные функции. У них также есть человек, который обсуждает с клиентом более глубокие требования и детали, обычно это еще один специалист по продажам, но с немного другим названием. Затем существует внутренняя субординация, различные уровни управления и, возможно, некоторая иерархия внутри технической команды.
Когда список требований клиента проходит через такое количество людей, даже если эти люди имеют самые лучшие намерения, некоторые вещи неизбежно теряются при “переводе”. Иногда это изменение происходит потому, что первоначальное требование не имело смысла, а иногда требования необходимо переформулировать. Продавец мог бы сказать клиенту: «Всего за 39,999 долларов мы можем сделать это на блокчейне». Но в этом случае каждый, кто столкнется с этими требованиями в дальнейшем, будет задаваться вопросом, что значит «сделать это на блокчейне».
Чаще всего требования меняются потому, что кто-то либо неправильно понял замысел, либо потому, что кто-то пытался справиться с вышеупомянутой скукой, пытаясь сделать свою работу или работу своей команды более интересной и впечатляющей.
В результате всего этого первоначальные требования — реальные проблемы, которые необходимо решить, — теряются. Они заменяются воображаемыми проблемами и пустотами, и у вас есть множество людей, готовых и желающих заполнить эти пустоты своими собственными воображаемыми проблемами, потому что проблемы, которые им приходится решать, скучны, а заполнение пустот дает им способ справиться с ними.
Избыточная сложность и естественный отбор
Часто для существования воображаемых проблем может быть еще более мрачная причина: проблемы могут помочь команде или компании расти, даже стать неотъемлемой частью ее функционирования.
Люди, которых разводят, отбирают и питают для поиска сложных решений, не имеют стимула для реализации простых, — Нассим Николас Талеб
Слышали ли вы когда-нибудь о трех веб-инженерах, которые выяснили, что безопасный онлайн-банкинг на самом деле является довольно простой проблемой для решения? Они разработали безупречное банковское программное обеспечение с нуля, используя методологию функционального проектирования и memory safe языки, а затем начали переводить крупные банки на свою удивительную инфраструктуру.
Возможно, вы о них не слышали, потому что их не существует. Однако существует множество многотысячных команд разработчиков, которые не в состоянии понять такие простые понятия, как «отзыв», и постоянно создают все новое банковское программное обеспечение.
Хранение и передача чисел не является особенно сложной проблемой. А вот индексирование всего содержимого Интернета и предоставление релевантных результатов на запросы на естественном языке за доли секунды — это сложная проблема. Но лишь нескольким умникам удалось решить эту проблему.
Постоянная проблема онлайн-банкинга заключается в том, что банковская экосистема стала действительно хороша в сохранении своей собственной иерархии захвата денег. Ее лидеры являются коррумпированными пиявками, которые наживаются на обществе — но лидеры в организации являются лишь симптомом ее членов.
Я бы не стал утверждать, что большинство рядовых сотрудников банков — злые или злонамеренные люди. Это далеко не так. Обычно это дружелюбные парни, которые работают, чтобы обеспечить пищу, кров и образование для своих семей. Но их главный стимул не в том, чтобы чинить банковское программное обеспечение, а в том, чтобы остаться на работе. Потерять работу в сегодняшней экономике — это не шутка для некоторых. В банковской сфере большой рот или слишком большая инициатива — это легкий способ оказаться перед дисциплинарным комитетом.
Поэтому банковские системы остаются неизменными — не потому, что они эффективны, а по инерции. Эта инерция проявляется в форме работы над воображаемыми проблемами, чтобы избежать решения реальных проблем — реальных проблем, которые, если на них указать, будут угрожать работе других людей. Сосредоточение внимания на этих реальных проблемах может привести к увольнению или, в случае некоторых особенно неприятных «институтов», таких как Goldman Sachs, к получению нескольких разрушающих жизнь коричневых конвертов, отправленных нескольким сотрудникам ФБР.
Трудно заставить человека понять что-то, когда его зарплата зависит от того, что он этого не понимает! — Эптон Синклер
C-менеджмент игнорирует тот факт, что их руководители тратят 90% своего времени на «встречи с клиентами» на тропических островах с миллионными бюджетами на «другие расходы». Руководители, в свою очередь, закрывают глаза на разврат в менеджменте.
Поскольку руководители среднего звена живут в своих фантазиях о «Волке с Уолл-стрит», высшее руководство игнорирует руководителей среднего звена, которые покупают эксцентричные офисы и нанимают себе трех секретарей и дюжину стажеров.
Поскольку линейное руководство не жалуется на фантазии своих руководителей о диктаторской власти, среднее руководство игнорирует тот факт, что линейные менеджеры, вместо того чтобы сокращать расходы, тратят свое время на работу над презентациями в PowerPoint на тему «Совершенствование нашей методологии Agile«.
Поскольку руководители групп, похоже, не замечают того факта, что их начальники даже не умеют правильно пользоваться Excel и бывают в офисе только раз в несколько недель, линейные менеджеры игнорируют руководителей групп и архитекторов, говорящих о «взаимодействии нового поколения между нашими системами с помощью JRPC и микросервисезации с помощью Hibernate и Spring», в то время как они просто должны заставить эти чертовы MySQL-запросы выполняться меньше суток.
Поскольку разработчики, похоже, не замечают, что их лидеры на самом деле не пишут никакого кода, кроме DOT-диаграмм, лидеры команды не жалуются на своих разработчиков, вместо того, чтобы посмотреть на EXPLAIN для вышеупомянутого медленного запроса, а лишь в десятый раз в этом году переделывают пользовательский интерфейс, используя новый JavaScript-фреймворк.
Это порочный круг решения воображаемых проблем, от генерального директора, который не понимает, что кража еще 30 миллионов не заставит его отца полюбить его, до стажера по пользовательскому опыту, который не понимает, что редизайн кнопки «отправить» с помощью Angular-Material-Bootstrap 19.13.5 не устранит тот факт, что пароли хранятся в виде обычного текста (и используют их как часть auth cookie).
Но всем им нужно продолжать решать воображаемые проблемы, потому что если они перестанут создавать и решать эти проблемы, если они начнут фокусироваться на реальных проблемах, они могут понять, что вся система не работает. Они могут понять, что Дебра сидит в углу и все еще смотрит на графики времени работы внутренней серверной несмотря на то, что компания перешла на AWS пять лет назад. Они могут понять, что 99% их работы — это увековечивание существования чьей-то другой работы. И это трудно переварить — для большинства, смею предположить, это невозможно. Поэтому большинство находит способ справиться с этим.