Сравнение технического долга в результате чернобыльской катастрофы и разработки программного обеспечения

Чернобыль на HBO сразу привлек меня. Не только из-за драмы или истории, связанной со знаменитым инцидентом, меня завораживает то, как актер Джаред Харрис (Валерий Легасов) подошел к смягчению последствий ядерного взрыва. Наблюдение за тем, как его персонаж мысленно разрабатывает решение с наименьшими рисками, основанное на текущих предположениях, только для того, чтобы столкнуться с непредвиденными проблемами, позже нашло отклик у моей инженерной стороны.

*ОСТОРОЖНО, СПОЙЛЕРЫ*

Технический долг

Больше всего на свете Чернобыль является ярким напоминанием об истинной стоимости технического долга.

Технический долг для тех, кто не работает в мире программного обеспечения, - это концепция, согласно которой неверные проектные решения, принятые в коде, или плохо написанный код, должны быть исправлены или вызовут проблемы в будущем. В отличие от чернобыльской катастрофы, технический долг обычно незаметен в программном обеспечении, но исправление может стоить компаниям миллионы. То, что ведет к техническому долгу, очень похоже на то, что было изображено в последнем эпизоде ​​мини-сериала: сочетание неудачных дизайнерских решений из-за сокращения затрат (графитовые наконечники), человеческой ошибки и производственных / деловых потребностей.

В целях этой аналогии я буду использовать термин «бизнес-потребности» для обозначения целевых показателей производительности, которые предприятия пытались достичь.

Снижение затрат

В случае с Чернобылем технический долг начался с графитовых наконечников управляющих стержней. Управляющие стержни были сделаны из бора, что помогло снизить скорость реакции в ядерном реакторе. Однако наконечники этих управляющих стержней были на самом деле графитовыми, что увеличивает скорость реакции. Итак, когда инженер пошел замедлить скорость реакции активной зоны, нажав выключатель аварийного отключения, стержни застряли только кончиками в реакторе, и реактор взорвался.

Графитовые наконечники не были показаны как соломинка, которая сломала верблюдов до финального эпизода. В мини-сериале, когда Валерий упоминает графитовые наконечники, прокурор спрашивает: «Почему графит?», На что Валерий отвечает коротко «потому что он дешевле».

Графитовые подсказки были физическим проявлением того, что программист решил не писать надежный код и не подумал, как будущие инженеры будут взаимодействовать с кодом. Это был короткий путь, который Советский Союз использовал в то время для экономии денег, что привело к одной из самых страшных катастроф всех времен.

В конце концов, они не учли количество ошибок, которые допустили инженеры Чернобыля, которые поставили ядерный реактор №4 в ситуацию, когда он взорвался.

Человеческая ошибка

Техническая задолженность не часто проявляется при обычном повседневном использовании программного обеспечения, как и при стандартном использовании Чернобыльского ядерного реактора.

Скорее всего, как и в случае с программным обеспечением, инженеры спроектировали реактор для обработки 95% возможных сценариев, в которых он будет размещен. Мы часто ссылаемся на эти сценарии как на варианты использования.

Варианты использования, которых нет в этих 95%, называются крайними случаями. Обычно это сценарии, которые кажутся редкими, недопустимыми или вызваны ошибкой пользователя, а не системной ошибкой.

Тем не менее, из-за того, насколько сложны эти системы, вы никогда не сможете предвидеть все возможные сценарии. Предсказать каждый крайний случай невозможно.

Основываясь на шоу (поскольку я не ядерный инженер), я предполагаю, что никто не думал, что кто-то сначала отравит ядерный реактор ксеноном, что приведет к его остановке, а затем попытается снова включить его, не вставляя стержни обратно. .

А потом… что еще хуже… графитовые наконечники стержня управления застревают, вызывая увеличение, а не уменьшение ядерной реактивности.

Безупречный инжиниринг учитывает все возможные сценарии, он учитывает все возможные человеческие ошибки и гарантирует, что пользователи будут двигаться в правильном направлении. Но идеальной инженерии не бывает. Мы делаем предположения, ориентируемся на большинство случаев использования и придерживаемся крайних сроков. При этом ядерный реактор никогда бы не оказался в указанном положении без давления со стороны высшего руководства с целью соблюдения нормативов производительности.

Потребности бизнеса

Последний эпизод, хотя и драматизирован, изображает режиссеров, фантазирующих о повышении по службе из-за успешного испытания реактора № 4. Когда им звонят приостановить испытание на несколько часов, они приходят к выводу, что это будет безопасно.

Сделали ли они вывод, что это безопасно, потому что они продумали процесс задержки теста на 10 часов, или они хотели порадовать начальство? Не берусь утверждать, что знаю, но могу сказать, что я видел, что необходимость соблюдать установленные сроки или квартальные бюджеты вынуждают принимать решения, которые влияют на краткосрочные цели, но в конечном итоге вызывают долгосрочные проблемы.

Стремление достичь краткосрочных целей, таких как ежемесячные квоты и квартальные прогнозы, часто вынуждает руководство играть в систему. Они сосредоточатся только на удовлетворении текущих потребностей или требований, не задумываясь о том, что может произойти позже. Например, возможно, технический менеджер подталкивает свою команду не включать модуль безопасности кода, потому что это не влияет на функциональность и будет хорошо смотреться на них. У них может возникнуть соблазн сделать это, даже если они знают, что это неправильно.

В конце концов, когда их продвигают, это уже чья-то проблема.

У вас всегда будет один инженер

Мне понравилось, как инженер высказался в последнем эпизоде. Правда в том, что всегда есть один хороший инженер, который пытается предотвратить плохие практики. Их не беспокоит чистая прибыль, и они не беспокоятся о том, чтобы говорить с руководством, чтобы сообщить им, что они совершают ошибку. Эти рекомендации можно пропустить, отнести к категории «исправить позже» (что означает никогда) или просто игнорировать их.

Честно говоря, мы должны благодарить этих людей в каждой компании.

Это единственные люди, сидящие между нами и падающими с неба самолетами или падающими с неба нашими банковскими системами. Их дисциплина для хорошего контроля качества и интеграционного тестирования - вот что гарантирует, что мы не умрем.

Заключение

Чернобыль - физическое воплощение технического долга в мире программного обеспечения. Может быть трудно увидеть влияние технического долга на компанию, потому что оно незаметно. Часто это не происходит до тех пор, пока инженеры, разработавшие системы, давно не уйдут.

Это не делает его менее реальным.

Это шоу HBO говорит о моем беспокойстве, поскольку программное обеспечение интегрируется во все.

Какого рода технический долг заложен в наши автомобили и самолеты, когда мы продолжаем пытаться интегрировать машинное обучение и ИИ во все?

Каковы шансы, что инженеры не совершат ошибку, учитывая абсолютную сложность управления устройствами Интернета вещей?

Какие крайние случаи нам не удается уловить? Как сжатые сроки и напыщенные руководители заставляют своих инженеров принимать краткосрочные решения, чтобы гарантировать своевременную отправку кода?

Компании пытаются притвориться, что ими движут более высокие заявления о миссии, но, в конце концов, они руководствуются теми же показателями производительности, которые послужили катализатором катастрофы в Чернобыле.

Каждая ложь, которую мы говорим, влечет за собой долг перед правдой. Рано или поздно этот долг придется выплатить . Блестящий, бесподобный Чернобыль. - @Baddiel Дэвид Баддиел