Чтобы понять всю глубину проблемы, рассмотрим отключение сети управления движением воздушного транспорта над Лос-Анджелесом из-за сброса даты 32-битных часов. Или отключение всех двигателей на борту самолета Boeing 787 по той же причине. Или сотни жертв крушения Boeing737 Max из-за сбоя системы MCAS.
А как насчет моего собственного опыта с сайтом healthcare.gov на заре его существования? После первого входа, как и на многих современных сайтах, в целях защиты от взлома мне нужно было ответить на ряд вопросов. Одним из вопросов был «запоминающаяся дата». Я ввел: 21.07.73. Сайт мне выдал, что я ввел неправильное значение.
Я программист. И знаю образ мышления программистов. В итоге я попробовал ввести дату в разных форматах: 21/07/73, 21–07-1973, 21July1973, 21071973 и тому подобное. Результат был одинаков. Неправильное значение. Я расстроился. Что за приколы? Какой формат вам еще нужен?
Потом меня осенило. Программист, написавший код для сайта, не знал, какие вопросы будут задаваться. Он просто выдергивал вопросы из базы данных и сохранял ответы. Этот программист, вероятно, не предусмотрел поддержку нестандартных символов и чисел для ответов. Так что я набрал «годовщина свадьбы». Наконец, получилось.
Думаю, что вполне справедливо сказать, что любая система, которая требует от пользователя мышления программиста, чтобы ввести какие-либо данные, — дрянь.
В этом разделе я мог бы рассказать массу историй об отстойном программном обеспечении. Но другие уже сделали это намного лучше. Если вам хочется ближе ознакомиться с масштабами этой проблемы, советую почитать книгу Гойко Аджича Humans vs Computers[30] и книгу Мэтта Паркера Humble Pi[31].
Вполне разумно, что боссы, клиенты и пользователи ждут от нас программ высокого качества с наименьшими недочетами. Никому не нужна ерунда, особенно если заплачены приличные деньги.
Обратите внимание, что упор Agile на тестирование, рефакторинг, простоту проектирования и обратную связь с заказчиком — это очевидное лекарство от низкого качества кода.
Всегда готовы
Самое последнее, чего от нас ожидают клиенты и руководство — что мы, программисты, будем как ненормальные переносить сроки поставки программного обеспечения. Но такие опоздания в мире разработки происходят сплошь и рядом. Причина таких задержек часто в том, что разработчики пытаются оснастить программу сразу всем функционалом, а не делать в первую очередь наиболее важные функции. Покуда есть функции, которые реализованы, протестированы или документированы лишь наполовину, программой пользоваться нельзя.
