Olympus BioScapes

И ещё один известный мне квази-научный фотоконкурс — конкурс Art of Failure.

Каждый год компания Olympus, являющаяся одним из ведущих мировых производителей фототехники, микроскопов и других оптических инструментов, проводит конкурс Olympus BioScapes Digital Imaging Competition. В этом конкурсе принимают участие снимки различных микроскопических форм жизни, сделанные при помощи оптических микроскопов с использованием различных технологий съемки.

• 

  "Жуки-братья", Два экземпляра насекомых вида Gonocerus acuteangulatus, размерами по 3 миллиметра, которые появились на свет два часа назад.

• 

  Открытая ловушка водного насекомоядного растения Utricularia gibba с одноклеточными организмами внутри.

• 

  Эмбрион летучей мыши вида Molossus rufus.

• 

  Зародыш цветка лилии, поперечное сечение.

• 

  Микроорганизм Paramecium.

Защита от Злого гения Декарта

Которой не существует. Но все таки я его нашёл!

Понятие

Регулярно как минимум в инженерной среде при проектировании (а точнее, при валидации) чего-нибудь складывается следующая ситуация. Разработчики придумывают какое-нибудь решение, а критики вокруг начинают придумывать разные идеи по поводу того, «а что будет если …». Изначально предлагаются осмысленные варианты поведения (здравомыслящие и логические), далее идет рассмотрение крайних случаев, потом идут какие-либо безобидные ситуации (как некорректный ввод пользователя), но в дальнейшем начинается нечто более серьезное. Что будет если закончится место на диске? Как разруливать ситуацию, если мы имеем нагрузку X, а нам дадут 10*X? А если задача зависнет? Однако, на этом дело не заканчивается. Идут вопросы о том, что делать если сыпется диск? А что если CPU будет не успевать? А если откажет таймер и часы переведутся? А если выйдет из строя тактовый генератор процессора? … где-то в конце этого списка молния попадает в компьютер, но он все равно должен выжить и выполнить боевую задачу.

В литературе по отказоустойчивым системам (fault-tolerance systems) между строк и сквозь все пронзает мысль о том, что нельзя построить систему, которая была бы оказоустойчивая и безопасная ко всему. Только сейчас в статье Marco Schneider'a нашел понятие того, кто пытается любыми способами сломать систему и с фактом того, что всегда есть возможность ему это сделать. То есть, если мы рассматриваем действующую систему, то мы можем находясь извне всегда придумать такую ситуацию, чтобы эту систему сломать, т.е. сделать так, чтобы она перестала функционировать. В статье такая роль называется malicious adversary или evil demon, последнее из которых — Злой гений Декарта.

Опытные и неопытные разработчики

Уровень 1. Новички в инженерии совершенно лишены тормозов и не знают о том, что вообще этот Злой гений существует. В связи с этим то, что они хотят сделать, они реализуют быстро, как придется и так, чтобы работало (классический Cowboy). У них нет в сознании множества граблей, на которые можно наступить. Нужно отправить e-mail? Где процедура… какие параметры? … сейчас подставим и всё! Готово! (пора рапортавать менеджерам о своей высокоэффективности). Однако то, что SMTP-сервер может быть не доступен, не обрабатывается. Письмо может не влезть в ящик, e-mail совсем не e-mail, пароль захордкожен и в открытом виде, бесконечный запрос отправки вешает всю систему, а ошибки сервера забыты, и это далеко не полный список.

Уровень 2. Более опытные разработчики имеют карту местности с множеством граблей, и отлично понимают, что наступить на новые, или на старые, можно в любой момент. Злой гений Декарта присутствует, но он есть интуитивно: уровень проработанности определяется на глазок, по срокам и ресурсам, а те, кто будет аргументировать методом «а что, если молния в компьютер?», будет мягко говоря, проигнорирован. Но даже для весьма опытных специалистов вопросы Злого гения ставят в тупик. Я несколько раз наблюдал ситуацию, когда в кругу матёрых инженеров (один пример на IT-конференции, второй в обществе специалистов по отказоустойчивым системам, третий в общении программистов со стажем порядка 10 лет) имел место диалог вида:

— Вот вы столько всего рассказали, все так интересно, но все равно ваша система не сможет спасти от всего?

— Да, не сможет.(с виноватым видом без акцента на то, что так вообще-то не сможет любая система)

Такой вот универсальный троллинг 2-го уровня.

Уровень 3. Понимание того, что Злой гений Декарта есть, универсальной защиты от него нет, но с ним можно бороться. А тот, кто предлагает универсальные способы решения — алхимик современности.

А как бы вы решали проблему защиты от Злого гения Декарта?

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

Решение 1: На основе анализа предыдущего опыта

В качестве иллюстрации данного способа решения мне нравится пример Титаника (его же и не только использует Leveson в своих статьях и книгах).

Когда спроектировали и пустили на воду Титаник, он считался непотопляемым. Данный вывод был сделан не а пустом месте. В качестве доказательства в пользу имелся ряд аргументов и фактов. Для упрощения (там было много всего), Титаник был спроектирован в качестве корабля с множеством независимых отсеков, который остается на плаву в случае пробоин и затопления 4-х из них. Исторический опыт того времени говорил о том, что во всех катастрофах было так, что корабли не получали повреждений более, чем на заполнение 4-х отсеков. К сожалению, в результате столкновения у Титаника было затоплено 5 отсеков.

Ключевым в данной истории является то, что для решения проблемы непотопляемости был проанализирован исторический опыт и имеющиеся технические возможности, в соответствии с которыми стало возможно ликвидировать на каком-то уровне все опасности, которые угрожали кораблям-предшественникам. Это так называемый Hazard Analysis, используемый сейчас во всех западных системах, критичных к безопасности. Но подобного рода анализ для всех разрабатываемых систем ещё не пришел (дорогое удовольствие).

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

Решение 2: Вероятностная защита

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

Классическими иллюстрациями для этого могут служить криптостойкость ключа при шифровании и контроль CRC в обычных системах (при передаче данных или например для проверки на сбои в памяти).

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

Если используем простейший CRC, то он позволяет также сделать так, что проявление сбоя будет замечено с высокой вероятностью, и не замечено — с пренебрежимо малой. Мы не защищаемся от всех сбоев, но зато защита идет от абсолютного большинства из них. И, если например CRC32, то следует помнить, что в случае сбоя если один из TCP/IP пакетов или запакованных архивов будет распакован или разобран в битом виде, при этом с вероятностью 2^-32 мы этого не заметим и никто нам об этом не скажет.

Здесь Злой гений Декарта есть, и полностью победить его невозможно, но он для победы должен быть достаточно мощен, чтобы перебрать ключ или достаточно удачлив, чтобы пройти через CRC.

Завершение

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

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

О проблемах программного обеспечения в 1983-м году

Цитата из статьи 1983-го года:

If you look at when the Bank of America central computer crashes and start doing statistics, you find that occasionally somebody has spilled coffee in the mainframe, or something like that happened that you can understand. But, in about 95% of those crashes, they don't really know what caused it. The system goes down, somebody says "Oh, here it goes again," and they push the reboot button. It takes them a couple of minutes to bring the stuff in from disk, the system starts again, and everying is fine. So, depending on the particular prejudices of whoever is recording those things, it was either a transient hardware failure, or whatever they like to call it. But basically, they just don't really know what happened.

Если вы взглянете на статистику аварий центрального Банка Америки, то вы обнаружите, что кто-то внезапно пролил чашку кофе на центральный процессор, или что-нибудь подобное, что может произойти и при этом можно понять что именно. Где-то в 95% случаев этих аварий никто не знает что на самом деле произошло. Система падает, и кто-то говорит: «Ё-мое.. опять..», и нажимает кнопку рестарта. Это требует нескольких минут, так как требуется загрузка с диска, после чего система стартует снова, и опять все хорошо. Однако, в зависимости от пожеланий-заморочек сопровождающих, они записывают это как временный аппаратный сбой или что-то в этом духе. Но на самом деле они даже не представляют, что это было.

Такое ощущение, что за 30 лет ничего не изменилось.

Хотя например есть свидетельства и результаты исследований ещё на рубеже 90-х (в книге Leveson), что там, где есть специальные меры и отсутствуют быстрокодописатели и какможнобыстреереализаторы, все намного лучше.

Разное

Статья сама по себе интересная, просто отмечу тезисно несколько вещей.

• FIFO и LIFO — это все приоритетные очереди, только их частные случаи. Эти структуры данных не обязательно должны быть реализованы так, как это пишут в учебниках (массивы, списки) — они должны выполнять внешние спецификации, и только.
• Ограничения и стоимость синхронизации и параллельности определяются аппаратной частью, и не могут быть решены в вакууме.
• Сначала идет идея и реализация, а только потом формализация того, что было сделано.
• В распределенных и параллельных системах спецификация и доказательство корректности должно быть на высоком уровне, а реализации их выполняющие — на низком.

Фальсифицируемость спецификаций

— Какие могут быть формальности между друзьями! Вася, сделай мне программу сортировки.
— А что такое сортировка?
— Мне надо, чтобы я вводил любые числа, а программа выдавала упорядоченные числа.

(через неделю)

— Ты что, Вася! Я ввожу 5 4 7 6, а твоя программа выдает 1 2 8 9.
— Так бы и сказал, что она должна использовать введенные числа.

(через неделю)

— Ты что, Вася! Я ввожу 5 4 7 6, а она выдает 4 5 6.
— Так бы и сказал, что все числа должны присутствовать.

(через неделю)

— Ты что, Вася! Я ввожу 5 4 7 6, а она выдает 4 5 6 7 и 8 и 9.
— Я выдал все, а от себя добавил, по дружбе, чтобы ты от меня отстал, наконец.

(через неделю)

— Ты что, Вася! Я ввожу 5.4 и 7.6, а она даже два числа отказывается сортировать.
— А откуда я знал, что тебе не только целые надо сортировать? Может тебе завтра взбредет комплексные сортировать?! Последний раз!!!

(через неделю)

— Ты что, Вася! Программа больше девяти чисел не сортирует…

© Конспект лекций для Светы

---

Фальсифицируемость

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

Что такое фальсифицируемость подробно есть в википедии, но для моего контекста достаточно того, что. Любое утверждение должно быть проверяемо (тестируемо). Если оно не проверяемо, т.е. его нельзя протестировать, значит оно ничего не стоит и его нужно выбросить на свалку. В крайнем случае, переформулировать или заменить. То, что можно протестировать — фальсифицируемо. То что нельзя — нефальсифицируемо.

Иллюстрация первая: классическая (в качестве введения)

Приходит заказчик и говорит: «Я хочу программу, и чтобы она работала». Переводя с пользовательского на народный это означает: «У меня есть проблема, и я хочу, чтобы её не было. Разберитесь пожалуйста, что это у меня за такая проблема, и решите её, и чтобы у меня её не было. А что за проблема я знать не знаю и знать не желаю.»

Иллюстрация вторая: недавняя

Несколько дней назад, почти дословное сообщение: «Когда внешняя система работает плохо, нашей системе тоже плохо. Сделайте так, чтобы нашей системе было хорошо. Всегда хорошо. При всех обстоятельствах. Она должна приспособиться к любой ситуации.»

WTF?? С каких это пор можно сделать систему, которая решает любую проблему и приспосабливается к любой ситуации?? Для меня вышенаписанное это звучит как: «Мы вас просили спроектировать непотопляемый корабль. А то, что сделали вы, утонуло после первого попадания ядерной боеголовки».

Удобные спецификации

«Так, вам задание. Система должна работать быстро. Отвечать на запросы — как можно быстрее. И не занимать много памяти. И, ещё, это…, проект должен быть готов чем скорее, тем лучше. »

Сделать универсальную систему невозможно, нужно оптимизировать по каким-либо параметрам. Но кроме этого, здесь следующее: такая формулировка очень удобна. Если вдруг окажется, что система тормозит, то всегда можно сказать «Мы же просили сделать так, чтобы система работала быстро! Почему не сделали?». «Медленно отвечает? Мы говорили вам!» …

Но с другой стороны: «Система вообще-то работает быстро. Может не так быстро, как хотелось бы, но это быстро!»

В результате никто ни в чем не виноват и никому ничего не должен.

Исторический пример неточных требований

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

В спецификации было указано следующее:

“Shut off the pumps if the water level remains above 100 meters for more than 4 seconds.”

“Выключите насос в случае, если уровень воды остается выше 100 метров в течение более чем 4-х секунд.”

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

Особенности верификации ответственных систем таковы, что проверка делается независимой группой, которая выполняет полный цикл обратной разработки. В том числе и интерпретацию требований без заглядывания в исходники. Специалисты по проверке предложили три интерпретации:

1. Среднее арифметическое за последние 4 секунды больше 100 м.
2. Среднее между минимумом и максимум за последние 4 секунды больше 100 м.
3. Среднее квадратическое за последние 4 секунды больше 100 м.

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

Таким образом, чтобы требования были проверяемы, нужна их точная математическая формулировка. Если требования сделаны на естественном языке, то это приводит к множеству различных противоречивых толкований, и в том числе к ошибкам и проблемам.

Необходимость фальсификации

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

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

Таки образом, для каждой из спецификаций должны быть описаны конкретные условия проверки (что проверяется, условия, обстоятельства и т.д.; полная постановка эксперимента (теста) ). Иначе они трактуются как попало и не работают.

Позитивные сдвиги

К таким сигналам отношу следующее. В последнее время несколько раз встречал из различных источников (внутренние правила компании по качеству; слова умных людей; методологии в IT), что: в разработке необходимо 100%-е покрытие тестами; если вы не можете проверить тестами, то и не реализуйте — практически наверняка есть проблема на предыдущих этапах.

Вывод

Таким образом, фальсифицируемость решает проблему демаркации — отделения реальных требований к системе от бесконтрольных хотелок.

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

Истец, судья и адвокат дьявола

Критика и Адвокат дьявола

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

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

Особенности человеческой психики таковы, что любые внешние идеи, отличные от наших, нашим подсознанием воспринимаются отрицательно, и это — аппаратное свойство нашей психики. Поэтому автоматически, когда вы идею выпускаете наружу, то все внешние обстоятельства становятся её критиками, зачастую необоснованно. И, если удары внешних критиков сильны, то это может не только накаутировать саму идею, но и любое ваше желание создавать что-то новое. В таких обстоятельствах важно выпускать такие экземпляры идей, которые имеют некоторый иммунитет и запас прочности. Но как его приобрести?

Так как идея никому не нужна, кроме нас самих, то в таких обстоятельствах нам приходится играть особую роль — критика наших собственных идей. Мы не придерживаемся мнения, что идея не работает, но при этом играем за черных. Очень точное название этой роли — Адвокат дьявола.

Таким образом, мы получаем две роли. Тот, кто выдвигает идею — Истец, ищет её положительные стороны, возможность применения и т.д.. Тот, кто критикует — Адвокат дьявола, занимается поиском слабых сторон и всяческим образом пытается разрушить полезность идеи.

Переключение между ролями

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

По моему опыту, хорошо время на переключение делать где-то минимум в 5-6 минут. За это время — очистить эмоциональный фон и оперативную память. Слишком частые переключения череповаты.

Третья роль

В последнее время окончательно вырисовалась третья роль, в корне отличающаяся от двух, описанных выше.

Особенность в том, что Истец и Адвокат дьявола позволяют выяснить конкретные свойства идеи: её область применения, сколько ресурсов на реализацию, какое качество будет на выходе, слабые места, сравнение с другими идеями, точки оптимума и др.. Однако полученный результат не всегда попадает на хорошую почву. То есть, в зависимости от обстоятельств может получиться так, что идея применима и работает, а может получится так, что не работает и здесь она никак.

Таким образом, решение о факте и необходимости применения лежит вне компетенции Истца и Адвоката дьявола, и эту роль по аналогии с судопроизводством, я называю Судьей. Кроме всего этого, так как Судья нейтрален, то он может устанавливать правила.

Суммируя. Истец выдвигает идею и её защищает. Адвокат дьявола критикует. Судья устанавливает правила (обязательно до), и принимает решение (обязательно после).

Роли в дискуссиях

Часто в разных дискуссиях люди присваивают другим определенные роли (например человек A за идею X, B против X). По моему мнению, такое мышление погубно, и уже давно я научился и привык быстро переключатся между ролями Истца и Адвоката дьявола. Что интересно, исторически была уже масса случаев, когда народ откровенно не понимал мою позицию, пытаясь присвоить её к одной или противоположной точке зрения, и все непонимание получалось потому, что фактически моей личной позиции по вопросу попросту не было.

Аналогии

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

Идея, её реализация и распространение

Меня поpажают люди наyки. Они за всю жизнь пpидyмывают 1 идею, а потом боятся ее сказать хоть ближайшим дpyзьям, боясь что ее yкpадyт. Идyт годы, и идея так и yстаpевает, не бyдyчи опyбликованной. Люди искyсства и бизнеса подают новые идеи сотнями, и совеpшенно спокойно относятся к томy, что какие-то из них бyдyт pеализованы на стоpоне.

Полугуманитарный преподаватель

Цитата из Капеллана Дьявола (с.269):

Однажды мы с Биллом разговаривали о термитах на отделении зоологии в перерыве на кофе. Нас особенно занимало, что за эволюционное давление привело термитов к их необычайной социальности, и Гамильтон стал хвалить «теорию Стивена Бартца». «Но, Билл, — возразил я, — это же не теория Бартца. Это твоя теория. Ты опубликовал её на семь лет раньше». Он помрачнел и стал это отрицать. Тогда я сбегал в библиотеку, нашел нужный том журнала «Ежегодный обзор экологии и систематики» и сунул ему под нос запрятанный в его собственной статье параграф. Он прочитал, а затем неподражаемым голосом ослика Иа-Иа признал, что, судя по всему, это и вправду его теория, «но Бартц изложил её лучше» (это правда, и я рассказываю эту историю вовсе не затем, чтобы принизить вклад Стивена Бартца. Билл Гамильтон знал, причем лучше многих, что набросать идею на обороте конверта, — это не то же самое, что разработать на её основе исчерпывающую модель). Напоследок замечу, что среди тех, кого Бартц поблагодарил в своей статье «за полезные советы и критику», был не кто иной, как У.Д.Гамильтон!

На мой взгляд, в этой цитате хорошо показаны две особенные вещи.

Два разных отношения

Представьте, что вы разрабатываете что-то новое, например новая идея/изобретение, или новый продукт как разработка, или пропагандируете новый принцип. И тут выясняется, что кто-то только что сделал то же самое, но от своего имени. Возможно даже лучше. Какие чувства вы испытываете? Радуетесь ли вы или наоборот, чувствуете, что у вас что-то отобрали?

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

1. Когда хочется никому не отдать и прибить гвоздями свое авторство не только, но и над всем, что из этой идеи следует; а также получить за придуманное плюшки. Надо заставить всех подписать копирайты на себя, доказать свое первенство и прописать его во все педии.
2. Попытаться распространить идею безвозмездно и как можно шире, особо не задумываясь о личном. Если кто-то работает в том же направлении, то поспособствовать изменению мира. Хотят пользоваться? Пусть пользуются, не жалко.

По моему мнению, для данных двух отношений характерно следующее.

Бизнес и личные интересы склоняются больше к первому, наука и гуманизм за все человечество — к второму.

Чем человек становится старше, тем он больше переходит от первого ко второму (эвристическое наблюдение).

Патенты и авторское право — средства для первых, научные публикации и книги — средства для вторых. Первые нагло тырят идеи у вторых, а свои не отдают.

Проработанная модель лучше идеи

Время от времени от имени психологии первых (назовем их эгоистами) слышу такую по смыслу фразу: «Я накидал им идею, и они сделали» с таким подтекстом, что как будто «без моей идеи они вообще никто». Есть ещё другой вариант: «штуку X я придумал и написал ещё в детстве, на коленке, за полчаса; а они её год делали и то еле работает» с подтекстом «это такая мелочь, которую нечего придумывать, я гений и это маленькая частичка моих идей; а эти писатели и внедрятели занимались этим столько времени».

Есть очень две большие разницы между идеей и её реализацией. Кроме того, есть ещё большая разница между реализацией идеи и её продажей (доведением до реального потребителя).

С точки зрения маркетинга и пищевой пирамиды кратко иллюстрирует это следующее выражение: «Тот кто придумывает, получает 1, кто реализовывает 10, кто продает — 100.»

С точки зрения «изменить мир», может быть не так сложно найти идею. Но намного сложнее её реализовать на практике. И ещё на порядок сложнее довести её до потребителя, чтобы ей пользовались многие.

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

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

Что интересно, У.Д. Гамильтон (тот, о ком была первая цитата) свою теорию соотношения полов у медоносных пчел точно так же опубликовал не в специальной заметке в журнале «Nature», как сделал бы любой ученый с нормальной степенью амбициозности, а спрятал в рецензии на чужую книгу. Кстати, у этой рецензии был безошибочно узнаваемый гамильтоновский заголовок: «Азартные игроки со времен зарождения жизни: усоногие, тли, вязы».

Капеллан дьявола

Речь идет об одноименной книге, которую прочитал некоторое время назад.

Книга представляет собой сборником статей Докинза, которые никаким образом не попадали в другие издания. В связи с этим в каждой из них тематика разная и рассматривается под своеобразным фокусом.

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

Рецепт и чертеж

Имеется два различных типа для создания или развития — рецепт и чертеж.

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

Если же мы имеем например торт, то не зная его рецепта, воспроизвести ещё один такой же торт мы не можем. Нам обязательно нужен рецепт приготовления, и не зная ингридиентов и способа готовки, угадать или изобрести рецепт чрезвычайно сложно.

Точные науки (там где больше математики) — занимаются чертежами. Они могут очень досконально описать процессы и воспроизвести их (экспериментально или вывести вездедействующий закон). Неточные науки (социология, психология, экономика, зачастую биология и медицина, …) занимаются рецептами и тортами. Их законы скорее работают чем не работают (т.е. чаще работают, но не всегда), а если человек имеет торт (кого-то вылечил, заработал денег, уладил психологическую проблему, …), то далеко не всегда он имеет рецепт или может объяснить, как он этот торт получил. Т.е. имеет потенциал повторить с большей вероятностью чем в среднем по больнице, но собрать универсальное решение или обучить кого-то этому же — уже затруднительно.

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

Пару своих примеров для иллюстрации.

Естественный интеллект является тортом, а искусственный — чертежом. Мы знаем приблизительно как получается естественный, что из такой-то цепочки ДНК после длительного взаимодействия с окружающей средой возникает естественный интеллект. Однако из-за сложности и длительности этого процесса уровня понимания чертежа у нас нет.

Если мы написали программу, то в подавляющем числе случаев мы можем посмотреть что получилось на выходе (торт), но воспроизвести цепочку решений, приводящих к результату (чертеж) — не в состоянии (если не этом специально не фокусироваться). Более того, каждый торт, в зависимости от времени и человека, получается разным.

Адвокат беспристрастной истины

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

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

Сейчас в суд можно подать в случае, если нанесен ущерб конкретному человеку. Например, кто-то распространяет гомеопатические средства (которые альтернативная медицина), обещает при этом много всего, однако действие средства не доказано. В суд можно подать только от к конкретного человека по его обстоятельствам. Но в общем случае распространение ложной информации и исполнить проверку по принуждению — такое уже сделать сложно.

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

Разрывы в мышлении

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

О таком типе мышления пару раз писал ранее в других контекстах, но в книге мне понравились две иллюстрации.

Есть такое понятие — «кольцевые виды». В Британии обитают два вида: серебристые чайки и клуши. Внешне они различаются легко (по разному окрашены), и при этом это два вида — они не спариваются в Британии друг с другом. Однако, если двигаться по ареалу их обитания вокруг Северного полюса, (через Европу, Сибирь и Америку), то мы заметим, что серебристые чайки медленно изменяются и превращаются в клуш. На каждом участке они могут спариваться друг с другом, но на концах кольца — уже нет. В Британии нам удобно различать по категориям чаек и клуш, но по факту эти два вида кольцевые, и параллельно с чайками и клушами существуют все переходные формы из одних в другие.

Основываясь на этом примере, мы можем получить следующую иллюстрацию. Если взять современного человека, и сравнить его с кроманьонецем 40 тыс. лет назад, то отличия между ними незначительны (мы можем друг с другом легко спариваться). Если пойти дальше, то можно получить так, что предок человека, живший 200 тыс. лет назад (назовем его X), ещё не ушел от нас настолько далеко, чтобы потерять возможность к спариванию. Однако может получиться так, что мы уже не можем спариваться с предком человека, жившего 400 тыс. лет назад (назовем его Y) из-за того, что различия слишком велики. Особенность всего этого в том, что генетическое расстояние между X и Y меньше, чем между нами и Y, поэтому X и Y могут спариваться. Таким образом, мы и X один вид, X и Y один вид, но мы и Y уже не один вид, и это отличие подобно различиям между клушами и чайками, только с той разницей, что межвидовые формы чаек и клуш ещё не вымерли.

С точки зрения непрерывных понятий можно назвать и другие примеры. Например в настоящее время есть куча переходных форм между планетами и звездами, а также между планетами и астероидами-кометами. То же самое между галактиками, скоплениями и звездными системами. Т.о. такие непрерывные понятия есть очень много где.

Способы предоставления информации

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

Для достижения своих целей в изложении и решения описанных проблем можно использовать разные способы подачи информации.

Мне известны три различных способа, каждый из которых имеет свои особенности и подходит для отдельных целей. Здесь их изложение.

Сократовский метод

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

Данный метод является классической схемой для предоставления человечеству полезных вещей (например описание решения проблемы X или научная статья), а также выполнения различных интеллектуальных работ/трудов.

Если провести описываемый вопрос через классический сократовский диалог, проведя одну итерацию, то это можно представить как:

Проблема → Способ её решения → Решение порождает новые проблемы.

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

Следующий шаг — описание решения. Т.е. мы описали что мы хотим решить, и только потом пишем, каким образом.

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

Таким образом, применение метода — последовательное выполнение ряда шагов (некоторые из которых могут отсутствовать):

1. Проблема.
   1. Актуальность проблемы (зачем её надо решать?)
   2. Описание проблемы (в чем суть).
   3. Примеры.
2. Решение проблемы — что предлагается/суть сообщения.
   1. Описание способа решения (она же теория).
   2. Примеры (они же практика).
   3. Особенности.
3. Выводы.
   1. Значимые результаты.
   2. Какие были/остались проблемы.
   3. Что будет в будущем.

Но не только научные статьи пишутся в таком стиле. Теперь третье приближение к сократовскому методу — цитата о применении метода из книги И.Адизеса «Идеальный руководитель»:

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

Я сознательно выбрал именно такой способ организации материала, применив сократовский метод, поскольку он иллюстрирует и отражает течение жизни — в том числе жизни организации. Изменения порождают проблемы, проблемы требуют решения, а реализованные решения порождают новые проблемы. Такой ход событий подобен человеческой жизни, за исключением того, что в отличие от нее описанный процесс может длиться бесконечно. Предложенный подход позволяет организации продолжать развиваться и адаптироваться к изменениям до бесконечности.

Inverted Pyramid

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

Данный способ появился во время Гражданской Войны (Civil War, полагаю что в США). Все репортеры хотели передать с линии фронта домой свои истории с помощью телеграфа, но особенность в том, что они могли бы погибнуть в любой момент, или телекоммуникационные линии могли бы быть оборваны. Поэтому никто никогда не знал, сколько времени отведено на передачу, и необходимо было передавать самую важную информацию в начале, а менее важное — в последующем.

Журналисты часто используют такой прием в случае, когда нужно быстро что-то написать. Собирается группа абзацев (каждый из них самостоятельная мысль), потом сортируется по важности по убыванию. Таким образом такая постановка задачи позволяет быстро собрать статью, захватить внимание читателя и передать таким образом максимум информации.

Таким образом, основная цель способа — захватить внимание читающего.

Burying the Lead

Lead — основной смысл сообщения. Burying — «закапывание». Т.е., целью является «закопать смысл сообщения». В данном контексте это может означать два основных замысла. Первый — смысл раскрывается в самом конце, второй — смысл закопан внутри и читателю предстоит его найти.

Основным ореолом обитания данного метода являются детективы, истории, анекдоты, пьесы и тому подобное. Читатель чаще всего заинтересован в поиске смысла и к этому подготовлен. Цель — неожиданная развязка или заставить о чем-то задуматься.

Комбинированные схемы

Совсем необязательно при написании использовать только одну из трех схем — их можно вполне успешно комбинировать.

Хорошим вариантом является написание некоторого заголовка или аннотации (lead), в котором содержится основной смысл статьи (core idea), раскрывающая суть, либо захватывающая внимание. А после lead'a можно использовать одну из других схем (сократовский метод для научных и технических статей, или burying the lead для публицистики).

Для иллюстрации этой схемы цитата Don Wycliff'a, победителя конкурса Editorial Writing (1996):

“I’ve always been a believer that if I've got two hours in which to do something, the best investment I can make is to spend the first hour and 45 minutes of it getting a good lead, because after that everything will come easily.”

Я всегда считал, что если у вас есть два часа на то, чтобы что-то сделать [написать], то лучшее, что я могу сделать, это потратить первый час и 45 минут на создание хорошего лида (lead), потому что после этого все остальное идет легко.

Эссенциализм как признак понимания предметной области

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

Многие люди хотя и признают эволюцию, но при этом имеют весьма превратные представления о ее механизмах. Одной из причин недопонимания является присущий нашему мышлению типологический взгляд на животных: мы склонны видеть в каждой особи не индивидуальное существо, а представителя того или иного вида. Из-за этого мы оказываемся слепы к проявлениям внутривидовой изменчивости («медведь — он и есть медведь»). Данное явление тесно связано с так называемым эссенциализмом — склонностью нашего разума приписывать группам объектов, сходных по каким-то признакам, некую общую для них всех идеальную «сущность». Философы написали о сущностях гигабайты текстов. Я не философ и не считаю это недостатком. Но на одном философском сайте мне попалась мудрая мысль, под которой я с радостью подпишусь. Звучит она так: «У вещей нет сущностей».

Дэниел Неттл из Университета Ньюкасла (Великобритания), специалист по эволюции и генетике поведения, провел со своими студентами ряд экспериментов, которые показали, что понимание эволюции может быть улучшено, если в ходе обучения использовать «человеческие» примеры (Nettle, 2010). Как и другие преподаватели эволюции, Неттл неоднократно замечал, что студенты с трудом понимают основы дарвиновского эволюционного механизма, несмотря на всю его кажущуюся простоту и вопреки всем усилиям учителей. Некоторые типичные заблуждения основаны на недооценке внутривидовой изменчивости. Люди склонны думать о том или ином животном прежде всего как о представителе вида. Речь идет, конечно, не о зоологических видах, а о «народных», то есть о таких группировках организмов, которые имеют общеупотребительное название. Народные виды иногда совпадают с зоологическими («лев»), но могут соответствовать целой группе близких видов («дельфин», «медведь») или внутривидовым группировкам (например, собака и волк — два народных вида, которые, по современным представлениям, относятся к одному и тому же зоологическому виду).

Такое «типологическое» восприятие животных, вероятно, сформировалось у наших предков под действием отбора как полезная адаптация. У людей есть специализированные участки мозга, расположенные в височной доле (а именно в верхней височной борозде и веретеновидной извилине), отвечающие за классификацию животных и растений. Повреждение этих участков может привести к утрате способности отличить льва от мыши и ромашку от березы при сохранении прочих ментальных функций. Современные охотники-собиратели различают многие сотни видов живых существ — в отличие от горожан, у которых соответствующие участки памяти, по-видимому, забиты сортами шампуней, йогуртов и автомобилей (Yoon, 2009).

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

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

Таким образом, если человек ничего не понимает в автомобилях, то он может сказать только то, о чем он понимает — цвет, количество дверей, … Но в том же цвете человек тоже может разбираться по-разному. Смотря на одни и те же вещи, мы субъективно разбиваем их на разные категории.

Это все теория. Что же может быть из неё полезного?

Признак понимания

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

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

Таким образом, если человек различает более подобные понятия, то он лучше разбирается. Если пользуется общими словами, то хуже разбирается. При наблюдении подобного эффекта впоследствии результат прогнозируем и проверяем — меньший или уровень понимания предмета. Более высокий уровень понимания наблюдать сложнее, но можно (терракотовый цвет; использование разнообразных слов, когда кажется, что можно использовать одно).

Вредные обобщения

При контакте с небольшой выборкой целевой группы можно попасться на то, что могут сформироваться не совсем корректные суждения. Например, «X — поганый народ». Т.е. на основании единичной или малой выборки было сформировано внутреннее обобщение. Хотя известно, что в любой статистически значимой популяции можно найти индивидуумов с любыми чертами, только распределение вероятностей будет немногим различаться.

Определять факт вредных обобщений и бороться с ними сложнее, т.к. сами обобщения делаются у нас автоматически.

Синглтоны языков программирования

Разбираясь с некоторыми вопросами высоконадежных систем, предназначенных для управления критически важных процессов информатизации (safety-critical systems), нашел некоторую особенность и попытался её разгрызть, почему сделано так.

Согласно стандарту ISO 61508 (сейчас он же действующий ГОСТ Р МЭК 61508), крайне не рекомендуется использовать динамическую память и динамические объекты (что для серьезных западных систем означает нельзя). Аналогичные требования есть в JPL Coding Standard (это ответственные системы NASA, например софт для марсоходов и МКС) и в MISRA C/C++(ответственные системы по умолчанию, например химическое производство которое может устроить катастрофу или автомобильный транспорт с тем же потенциалом для последствий).

Однако, если создать свою структуру данных и верифицировать её в рамках проекта (это обычно не означает написать пару сотен строк кода за день-два, а работу нескольких высококлассных специалистов в течение нескольких месяцев (счет для самых простых структур данных начинается с 3-х месяцев), которые проведут её через все этапы разработки с многоверсионными проверками спецификаций, полным черно-белым тестированием, верификацией формальными методами с использованием дедуктивного анализа и модели с задействованием автоматики, экспертная оценка как человеком, так и автоматикой (статическими анализаторами кода в т.ч.), и все это умножить на два из-за проверки независимой группой по всем этапам). Удовольствие дорогое, но возможное. (отдельным путем является использование компилятора, обеспечивающего безопасное поведение в случае отказов; классические и всем известные C/C++ к таковым не относятся; к ним обычно относится верифицированный куцый C/C++).

Авторов всего этого понять можно: динамика поставила на колени далеко не один проект С/C++, а в последние годы много усилий ушло на уменьшение последствий от возможных проблем на данном минном поле.

Прошло какое-то время, прежде чем мною ощутилась разница между описанным первым (глобальной динамикой) и вторым (верифицированными структурами данных): отдельно разрабатываемые структуры данных играют (в том числе) роль специализированных менеджеров памяти, а поставляемые в коробке new/delete и malloc/free — синглтонов языка программирования.

Динамика как синглтон

new/malloc и delete/free работают глобально, в одной большой куче. Доступ к ней есть отовсюду. О том, как лучше работать с этой кучей — изобретается множество инструментов и техник, так как надо контролировать создание (только один раз) и удаление (только один раз и только после создания), обрабатывать ошибки (переполнение памяти), попадать куда надо указателем (неопределенное поведение) и типом (срезка), получать доступ и разделять ответственность. Фактически сама куча является глобальной структурой данных, поддерживаемой на уровне языка.

Если мы переключаемся с фокуса глобального хранения на малую изолированную структуру данных, то сразу посредством модульности снимается комплекс проблем, в основном за счёт резкого снижения сложности и разделения ответственности.

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

Синглтоны C++

Прошелся по языку и нашел следующие синглтоны:

• new/delete
• static
• cout/cerr/cin
• Ресурсы (файловые дескрипторы, коннекты, потоки, …).
• Нелокальные макросы.
• Указатели.

Т.о. язык предоставляет пользователю набор синглтонов в упаковке, готовых к использованию.

Свойства

Свойства очень похожи из того, что есть в оригинальном синглтоне. Для всех описанных (кроме макросов, они на этапе сборки):

• необходимо заниматься синхронизацией в многопоточном приложении;
• все сущности видны отовсюду, и любой может сломать сразу все;
• если в проекте/библиотеке сущность уже прибита гвоздями к стенке, то её размножить сложно;
• нужно заботиться о потенциальных побочных эффектах и сводить в stateless после каждого вызова;
• узкое горлышко многопоточной производительности;
• некоторые синглтоны обладают разной степенью глобальности.

Если начинают появляться проблемы с синглтоновостью, то часть из них решается разбиением на модули в виде отдельного процесса, у которого своя куча, свой лог, свои ресурсы. Таким образом мы синглтоны режем на другие синглтоны и частично решаем проблему модульностью. Вторая часть решается переходом на отдельные структуры данных. Т.е. из динамики лучше уйти в свои контейнеры, а если возможно — то в контейнеры проверенных временем библиотек (STL). Третья часть — если есть возможность уйти от динамики, то лучше уйти. Например полиморфить через ссылки, а не указатели.

Т.о., понимание синглтонов позволяет лучше ощутить источник проблем и ведет к светлому будущему (;

Алхимики современности или неразрешимые проблемы

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

Но алхимики никуда не исчезли. Они до сих пор среди нас, только декорации изменяются.

Здесь хочу выделить отдельный класс т.н. неразрешимых проблем и описать пару их свойств.

Современные примеры

Поиск серебряной пули

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

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

Поиск элексира вечной молодости

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

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

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

Знание языка

Имеется ввиду человеческого языка общения.

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

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

General Problem Solver

Это мое прогностическое мнение. Не существует универсального AI, решающего любую проблему. Есть много разных AI с разной эффективностью, и естественный интеллект не исключение.

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

Свойства

Все свойства расписаны выше, но здесь их явная систематизация.

Кроме того, мое контекстное определение. Неразрешимая проблема — такая проблема, которая решается частично, но не может быть решена полностью, либо полное её решение слишком затратно; мы можем решить её частично, и улучшить результат, но полного решения нет.

Полезность и бесполезность попыток

Исторически показано, что подобные попытки зачастую не приводят к решению самой проблемы, но приносят большое количество косвенных плюшек и изобретений. С одной стороны, проблема не нешена, а с другой — плюшки есть.

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

Множество предложений простого способа

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

Нет простого способа

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

Оптимизм

Есть вещи, которые не таковы, какими мы хотели бы их видеть. Очень хочется иметь философский камень, универсальный молоток, элексир молодости и пр.. Но реальность не такова.

Заключение

Когда каркас данного сообщения был готов, то перечитал Брукса (его Мифический человеко-месяц, где есть No Silver Bullet с историей 10 и 20 лет спустя). И с восхитительным удивлением нашел там следующую цитату:

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

Turski W. M. And no philosophers’ stone, either // Kugler H. J. (Ed.). Information Processing 86. Amsterdam : Elsevier Science, North Holland, 1986. P. 1077-1080.

Развитие технических систем — Взрыв и стандартизация (с примером IBM)

Лампочки накаливания появились не сразу, а долгое время изобретались разные варианты решения. В свое время Эдисон перебрал две тысячи лампочек, прежде чем выбрал ту самую, которая победила газовое освещение.

При выходе в новую область наблюдается взрыв разнообразия различных форм. Так было с самолетами в 20-30-х гг., так было в войне Unix'ов, так было с кодировками до ASCII и до UTF-8.

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

После взрыва запускается процесс естественного отбора, когда разнообразие начинает уменьшаться, а видообразование приостанавливается. Отдельные наиболее приспособленные особи выживают и захватывают большие области, другим видам питаться нечем и они отмирают. Так, на сушу в свое время вышли 5-ти, 6-ти и 8-ми пальцевые существа, но выжили только потомки первых, потому мы такие и других больше не наблюдаем.

В технических системах происходит аналогичный процесс, когда остаются в основном 4-хколесные машины шириной в две крупы лошади, мейнстримовые языки программирования, типовые решения для аппаратных устройств (генераторы, трансформаторы), коробочные продукты (one-the-shelf), … Большие выжившие монстры решают большие классы задач, а в маленьких закоулках ютятся отдельные подвиды, зачастую мало кому известные и потенциально отмирающие.

Технические пути отбора

В технических системах с точки зрения отбора можно выделать два механизма.

Первый — насильственный захват и выбивание конкурентов. Например как это делает Windows — разработчики Windows сами себе стандарт, не обращая внимания на других, и способ захвата — выживают те решения, которые выигрывают на рынке, даже если эти решения не являются сильными. Это и сама ОС, и Ctrl-C Ctrl-V (задолго до них был Ctrl+Insert и Shift+Insert), и Win-1251 и др.. С точки зрения разработки — это решения для себя, для полного контроля и для вписывания в внутрикорпоративные стандарты.

Второй — через комитет (comittee). Когда собирается группа экспертов и после обсуждения принимает какое-либо чаще всего консенсусное решение. Решения более сильные, более глобальные, но делаются немногим дольше и не всегда выживают.

Технетика

Естественно, напрямую переносить эволюцию с био- на техно- нельзя, но в них много похожего и подходит для аналогичного объяснения. Био-эволюция по большому счету слепа в своем отборе (по очень малому нет), а для технических систем несколько шагов вперед проверяет человек, сразу отрабатывает несколько вариантов и имеет некоторую цель для реализации.

Таким образом, любые технические системы развиваются, живут и умирают. И, как ни странно, есть целые труды и школы, которые описывают данный процесс. С одной из таких я познакомился где-то на рубеже 2000-х, это была Технетика Б.И.Кудрина — информация в ней зубодробительна и слишком философска для обычных людей, но базовые понятия развития техники удалось почерпнуть именно оттуда. В дальнейшем элементы технетики встречались и замечались в жизни много раз, иногда принося существенную пользу.

Стандартизация вычислений с плавающей точкой

Сейчас ещё один такой случай, который увиделся при чтении Fatal Defect (chapter Wrong Number), где подробно разобрана история становления стандарта по вычислительным арифметическим операциям на компьютерах/калькуляторах с плавающей точкой. Особенность в том, что в 60-х не было единого подхода и решения того, как хранить вещественные числа в компьютере, а также как проводить вычислительные операции. Каждая организация делала свое решение, а зачастую внутри организации разные аппаратные разработки имели разные реализации.

Особенностей разностей несколько. Для примера, первая в том, что для повышения точности можно хранить разное количество дополнительных разрядов (кроме отображаемых на дисплее калькулятора можно хранить 0, 1, 3, … разрядов за краем табло, чтобы потом результат вычисления был более точным; например если не хранить, то 1/3*3 получится 0.99999). Второй является то, что можно использовать разные способы округления, которые также могут отражаться на конечном результате. Третьей являются разные алгоритмы выполнения данных операций, каждый из которых может отличаться точностью, быстродействием и неравномерным распределением ошибок. Четвертой — возможно разные преобразования между отображением и вычислением (например сначала берется то что на дисплее в 10-й системе счисления, переводится в 2 с/c, считается, далее обратно в 10 с/c). Пятой — стоимость системы.

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

Компьютер в любом случае не может обеспечить 100%-й точности для всех математических вычислений (так как числа в памяти есть конечное число единиц и нулей), и, казалось бы, с этим мало чего можно сделать. Однако в 70-х запустился процесс продвижения идеи, согласно которой необходимо было привести зоопарк к общему знаменателю, чтобы мы не всегда получали точный результат, но на разных компьютерах этот неточный результат был бы одинаковым.

В конце 70-х IBM инициировала внутри себя процесс создания подобного стандарта, так как зоопарк был внутри данной организации и руководство уговорили это сделать. После запуска процесса был собран IEEE-комитет из ~70 представителей различных компаний и институтов (не только из IBM). После многочисленных штурмов и споров (потому что каждый эксперт считает свои заблуждения самыми правильными) был выпущен черновой вариант с сомнениями о том, что этому кто-то будет следовать. Однако IBM в 1980-м выпускает первые чипы 8087, которые соответствовали описанным требованиям, и после этого запустился лавинообразный процесс, который охватил всех мировых производителей, хотя официальный чистовой вариант был принят в 1984-м.

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

Радость от повторения

Дети любят, когда им несколько раз читают одни и те же сказки.

В фильмах и особенно в сериалах зрители любят, когда повторяются определенные фишки.

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

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

В разработке видео-игр, когда гейм-дизайнеры рассматривают игроков как подопытных кроликов, есть такое понятие как Core Gameplay Loop, заключающееся в том, чтобы формировать такие повторяющиеся радости, и чем чаще то делать, тем они сильнее закрепляются, и потом на них строить все остальное.

Если часто общаться с человеком, то можно заметить множество повторяющихся штук, в том числе и за собой.

По-моему, за всем этим стоит некий нейробиологический принцип, или общее психическое свойство. Но в популярных литературах ещё ничего такого не встречал.

О правильном

В начале всяческой философии лежит удивление, ее развитием является исследование, ее концом — незнание.

М. Монтень

Не бывает правильных (тру-шных и т.п.) программ. Бывают программы с определенными свойствами. Мы не проверяем тестами корректность программы, и не доказываем правильность формальными методами — а определяем вполне её конкретные свойства.

Не бывает правильного способа решения проблемы. Бывают способы с определенными последствиями.

Не бывает правильного принципа или метода. Бывают принципы и методы с определенными достоинствами и недостатками, работающие в определенном окружении.

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

Одно дело когда известен контекст и все понимают, чем «правильный» вариант лучше, чем остальные. Другое дело, когда контекст теряется, и народ уже не понимает что стоит за словом «правильный». «Потому что так написано в книге Х», «Потому что так сказал Y», «Мы всегда делали Z, и в дальнейшем будем делать так же», …

«Правильное» мышление дешевле. Не нужно заморачиваться о причинах, достаточно принять на веру. Так например учатся дети у взрослых, принимая опыт как есть, без какой-либо критики, но в том числе, не понимая причин почему именно так. Так принимают схемы поведения у авторитетов.

После того, как схема принята, то изменить её сложно. Классическая цитата Лоренца:

Для существа, лишенного понимания причинных взаимосвязей, должно быть в высшей степени полезно придерживаться той линии поведения, которая уже — единожды или повторно — оказывалась безопасной и ведущей к цели. Если неизвестно, какие именно детали общей последовательности действий существенны для успеха и безопасности, то лучше всего с рабской точностью повторять ее целиком. Принцип «как бы чего не вышло» совершенно ясно выражается в уже упомянутых суевериях: забыв произнести заклинание, люди испытывают страх. (К. Лоренц, Агрессия)

Если существо работает «правильными методами», которые лишены понимания причинно-следственных взаимосвязей, то мы и получаем такую картину, когда делается потому, что так делалось всегда, а шаг в сторону — это страшно. И работает эта штука подсознательно.

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

Понимайте причинно-следственные взаимосвязи.

Поступательное развитие

В последнее время вокруг меня что-то много звезд выстроилось по этому понятию…

Примеры

Нельзя сразу собрать проект, который реализует полет на Луну. Или создаст термоядерную бомбу. Или реализует национальную ПРО.

Сразу слетать на Луну — это будет глупая и бессмысленная смерть. Сначала надо собрать ракету и запустить. Понять, что чтобы слетать, надо работать над надежными двигателями, иначе летать она будет низко. Придумать гироскоп, иначе летать будет не туда. Собрать конструкцию заданного масштаба (ракеты малой дальности и межконтинентальные — это две болшие разницы). Запустить железяку и проверить, чтобы она не столкнулась с небесным сводом. Запустить жывотное, потому что его не жалко. Запустить человека в корпусе. Запустить и отработать технологии выхода в открытый космос. Слетать на Луну и померять радиацию. Попробовать прилуниться, а то иначе можно утонуть. И только потом появляются какие-то шансы на слетать и вернуться обратно.

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

Для ПРО сначала необходимо создать что-то, что сможет зарегистрировать массы самолетов. Потому что-то, что сможет засечь одиночный самолет. Потом что-то, что сможет засечь и определить высоту полета. Потом что-то, что сможет засечь, определить x,y,z,t и сбить. И только потом можно думать о чем-то, что сможет отразить атаку в глобальном масштабе.

Два простых правила

Давно в данной теме знаю и использую два простых правила:

Законченные и дискретные решения

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

Сложные системы строятся из простых

После Буча сейчас много где цитируют J.Gall'a ^*: «Любая работающая сложная система является результатом развития работавшей более простой системы... Сложная система, спроектированная "с нуля", никогда не заработает. Следует начинать с работающей простой системы».

Процесс роста

Совсем недавно встретил через Стратоплан картинку роста в любой области (источник — недра психологии потока):

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

На графике по вертикали сложность постановки задачи, они же требования к её исполнению (масштабность проекта, процент отказов, производительность системы, … — все это может быть большим уровнем по требованиям). По горизонтали наши умения (+ знания и навыки). Т.е. способность что-либо делать.

В самом начале мало чего умеем. И лучше, если не предъявляем к себе каких-либо сверх-требований. Тогда это нижний левый угол.

Делая что-то, мы учимся это делать лучше. Если делать это долго, то мы научимся это самое делать, но нам становится скучно. A1→A2. Если мы предъявляем к себе более высокие требования, то появляется чувство тревоги — получится ли? сложно! много всего.. и все такое. A1→A3.

В состояниях A2 и A3 зоны дискомфорта — человек может бросить этим заниматься, а может получить большой стимул к развитию.

Оптимальное развитие — как по красной линии, можно немного иногда заходить в сторону тревоги. Если делаем переход вида A1→A4, то растем и можем осуществить большее.

Следствия:

• Сначала мы все ничего не умеем. Если мы предъявляем к себе большие требования, то станет страшно, ничего не будет получаться и все будет заброшено. Поэтому начинать надо с простых вещей.
• Если долго делать одни и те же простые вещи, то станет скучно и уныло. Что делать? Повышать требования.
• Что делать чтобы быстро расти вверх? Идти согласно коридору потока. Если проект большой и масштабный, то идти придется долго, зачастую окольными путями.

Под другим ракурсом

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

Слишком сложная цель

Регулярно встречаю случаи, когда народ хочет «сразу все», и иначе — только «ничего». Это либо попытка собрать большую сложную систему сразу, которая заканчивается фатально, либо долгое вынашивание идеи без каких-либо реализаций.

Здесь вижу два больших разных пути решения: «составление программы» и «работа в стол». Первый вариант предпочтителен — есть ресурсы, понятно приблизительно что делать, вехи отмечены. Второй вариант — за неимением первого, когда цель недостижима, не хватает ресурсов, практическая область не понятна.

Работа в стол: переход на самообразование в случае плохого образования; постепенная выработка мастерства; методический и системный сбор информации.

Составление программы: серия последовательных целей; законченные проекты, решающие часть задачи; проекты, релевантные конечной цели; моральная готовность к длительной работе.

Отсутствие цели

Проект выполнен, а дальнейших целей нет.

Активный поиск качественно более широкой и дальней цели и отсутствие ожидания. Без этого — останов процесса роста и потеря поступательного развития.

Отсутвие возможности работы над следующим этапом (не важно по каким причинам) — способствует потере команды и задела.

Цель забирают

По разным причинам — недопущение до информации, высмеивание, потеря контроля, куча соавторов.

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

---

^{* — данная мысль только в программной инженерии лет на 20 старше; у Брукса в статье о серебрьяной пуле есть ссылка на научную публикацию 1971 года и цитата коллеги 1958-го года.}

Art of Failure

Теперь прибавился к известным мне квази-научным фотоконкурсам конкурс Art of Failure.

Конкурс проводится в рамках международного симпозиума IEEE по физическому анализу и анализу отказов интегральных полупроводниковых схем (IEEE International Symposium on the Physical and Failure Analysis of Integrated Circuits). На этом конкурсе представляются имеющие художественную ценность фотографии необычных объектов и явлений, которые возникают на кристаллах микросхем и других полупроводниковых приборов, возникшие в результате неисправности или выхода из строя этих кристаллов.

• 

  Именно эту картину увидел на изображении, снятом электронным развертывающим микроскопом, Лим Сав Синг (Lim Saw Sing), сотрудник компании Infineon Technologies, рассматривая поверхность полимидного кристалла, подвергнутого процессу ионного травления. Этот снимок занял первое место в конкурсе Art of Failure 2012.

• 

  Мембрана из специального материала "прилипла" к коротким частям из углеродной ленты, формируя подобие странного и необычного "леса" на этом изображении с микроскопа. Данный снимок сделал Лим Чен Вэй (Lim Chan Way) из компании Infineon Technologies.

• 

  Аналитики компании Advanced Micro Devices посчитали, что данная структура на поверхности кремниевой подложки очень смахивает на слона в головном уборе. Фотография так же принадлежит Жаклин Ква (Jacqueline Kwa) из компании AMD.

• 

  Проводя свои исследования, инженеры компании WinTech Nano-Technology создали эти 20-микронные структуры из меди, используя технологию нанопроизводства с использованием сфокусированного ионного луча. Фотогорафия Ху Бинг Шен из компании WinTech Nano-Technology.

Что такое человеческий фактор

Лет пять назад встретил мнение о том, какими будут в будущем автоматизированные системы и звучало оно где-то так:

В будущем на автоматизированном заводе не должно быть кроме роботов никого, только один человек и собака. Зачем человек? Чтобы кормить собаку. Зачем собака? Чтобы смотрела за тем, чтобы человек ничего не трогал.

Сейчас обнаружил более оригинальное высказывание (в книге Fatal Defect, 1995), которое походу имеет также корни ещё на лет 10-15 глубже. Итак, шутка, которая ходит среди инженеров-разработчиков автоматизированных систем авионики:

Future automated airplanes will have only a pilot and a dog in the cockpit. The pilot will be included to reassure the passengers while the computers fly the plane. The dog is there to bite the pilot in case he or she touches anything.

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

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

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

Приведенная цитата из книги принадлежит Nancy Leveson, она не является её автором, но от себя продолжает её так:

The pilot will also be there so that there's someone to blame in case of an accident.

Пилот также будет тем, кого можно будет обвинить в случае какого-либо происшествия.

Зачастую в случае различных происшествий называется человеческий фактор, формулируясь под видом «чего-то недосмотрели», «чего-то не учли», «не услышали сигнала» и пр.. Пара примеров.

Первый. Более подробное рассмотрение происшествия, описанного ранее. Во время снижения A320 получилось так, что пилоты задали слишком быстрое снижение и из-за этого врезались в гору. Однако за всем этим стоит нечто большее. В авионике за 20 лет до происшествия сделали обязательное правило для установки подсистемы, которая оповещает пилотов об опасности слишком низкой высоты полета. Эти подсистемы автоматически посылают звуковые сигналы с громкостью и частотой в зависимости от высоты полета. Однако в рассматриваемом деле на возможность исправить ситуацию с помощью их сыграло дополнительно два фактора. Во-первых, исторически получилось так, что зачастую реализация данных устройств оповещения была такой, что система до неприличия часто давала ложные срабатывания и поэтому пилоты привыкали к данным звукам и не обращали на них особого внимания. Со временем система улучшалась, но сотрудники авиакомпаний по-прежнему считали, что оповещения часто подвержены ошибкам. Во-вторых, для внутренних авиалиний Франции администрацией было принято решение, что раз это внутренние, то пилоты хорошо знают местность и для них такую систему можно просто не устанавливать. Таким образом получается, что на факт катастрофы повлияло как инженерное решение (слишком часто ложные срабатывания), так и административное (отсутствие оценки реальной опасности). Но в протоколах записано, что виноваты пилоты.

Второй. Нам на лекции как-то Анатолий Коврига рассказывал об одной из схем управления ж.д. стрелками. Со временем эксплуатации выяснился один дефект, который мог приводить (и привел) к опасному отказу (переводу стрелки в случае занятой секции, т.е. потенциально под поездом). Фактически это был инженерный просчет. После происшествия (аварии) схема была пересмотрена и в неё добавлен ещё один элемент — конденсатор, который был призван исключить возможность опасного отказа. Но особенность была в том, что конденсатор в этой схеме был с такими параметрами, что требовал очень аккуратного и регулярного обслуживания. В корпусе проблема была решена, но в реальности получалось так, что если происходит что-то страшное, то оказывался виноватым не разработчик, и не начальник станции, а электромеханик, который обслуживал данную схему и якобы забыл обслужить конденсатор.

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

Для решения есть ряд путей:

• Обучение обслуживающего персонала — лучшее понимание как работает система у тех, кто с ней работает.
• Создание более дружественного интерфейса и общая минимизация трудностей общения людей и системы — более человеческий интерфейс, разработчики должны писать код для людей (с обратной связью) а не чтобы просто написать и сдать.
• Создание системы принятия решений — для чрезвычайных ситуаций создание БД того, что если что-то произошло, то надо делать так-то.
• Отработка чрезвычайных ситуаций на симуляторе/имитаторе — например в авионике пилотов тренируют на разных сиутациях (отказали закрылки, ушли в штопор, внезапная потеря высоты) и потом они это уже делают более интуиутивно.
• Разработка более корректной и надежной системы как таковой.

Nancy Leveson часто и давно говорит о том, что катастрофа является результатом стечения ряда факторов, и обвинять только один из них является классической ошибкой. В случае с человеческим фактором почему-то получается так, что его очень удобно обвинить во всем.

Баг, о котором услышал весь мир (The "BUG" heard 'round the world)

10 апреля 1981 года, приблизительно за 20 минут до запланированного запуска первой американской космической транспортной системы, астронавты и технические сециалисты попробовали активизировать программную систему, выполненную с 4-хкратным резервированием и дополнительным запасным компьютером… но не смогли. Фактически, у них не было никакой возможности это сделать, так как компьютер просто не воспринимал команды… Это был баг, очень маленький, очень неуловимый, очень замысловатый и очень древний — это была ошибка в логике инициализации резервной системы. Это была ошибка, которая является кошмаром для программистов и руководителей, из разряда тех, которые «не могут произойти», даже если вы будете следовать всем правилам хорошего проектирования и разработки.

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

Одним из самых известых багов в истории, которые при этом были документированы по описанному сценарию, является подготовка первого полета Шаттла 10 апреля 1981 года, когда контроллеры отменили запуск в космос шаттла Колумбия всего за 20 минут до намеченного времени. По этой причине на это обратила внимание мировая общественность и почувствовалось давление на то, чтобы подробности были раскрыты. Это был баг, который моментально стал извествен всему миру. Через некоторое время после проишествия Neumann нашел одного из разработчиков программного обеспечения, Jack'a Garman'a, и уговорил его раскрыть детали прозошедшего — именно так появилась эта публикация.

Для повышения надежности шаттл использует 4 идентичных компьютера, работающих по одной и той же программе, включенных в мажорирующую схему 2+2 с сильными связями, функционируя в горячем резерве. Это означает, что 4 компьютера разбиты на 2 пары, каждая из которых синхронизируется со своим «напарником». Если состояния пары одинаковы, то это считается корректной работой системы. Если одна из пар расходится во мнениях, то вся пара считается сломанной и управление переходит на вторую пару компьютеров. Синхронизация между парами происходит на каждом цикле внутренних часов. Данная организация позволяет защищаться от аппаратных проблем — например в случае сбоев из-за электромагнитного излучения.

Кроме описанных 4-х компьютеров в системе присутствует также 5-й компьютер, являющийся резервным. Его ПО обладает такой же функциональностью, но написано другими программистами и работающее под другой операционной системой — для обеспечения более высокого диверситета на программном уровне (в данном шаттловом случае компилятор и железо были одинаковыми с основной системой). Данный компьютер включается только в случае, когда обе пары из основной системы 2+2 выходят из строя, при этом резервная система управление и всю ответственность берет полностью на себя. Резервный компьютер программно призван отличаться от основного и в этом плане его назначение — избежать программных ошибок.

В описанной истории инженеры обнаружили баг временной синхронизации между описываемыми компьютерами. С вероятностью 1/67, которая срабатывает на каждом запуске системы, могло получится так, что часы синхронизации пары 2+2 и резерва окажутся на 1 такт впереди общих тактов синхронизации. Именно это произошло на реальной системе при пробной попытке запуска челнока за 30 часов до предполагаемого старта. В случае рассинхронизации получалось так, что старта основной системы не было, а резервный компьютер никогда бы не получил сигнала о том, что 2+2 вышли из строя. Следует заметить, что тысячи часов тестирования не смогли выявить описанную проблему.

В комплексе имелось три ленты времени — данные телеметрии, время для основной системы и время резервной. При подготовке к запуску заранее стартовала телеметрия (как обратный отсчет) и относительно её синхронизировались обе системы (основная и резервная), но время самого запуска в них системе вычислялось математически и по общим тактам. Далее, если происходила рассинхронизация, то получалось так, что время, которое оставалось до старта по расчету во время ожидания сигнала, становилось отрицательным (пришло время старта, ожидаем sync, а его нет). Число беззнаковое, поэтому оно становилось равным FF, т.е. конечному числу, а по меркам реальной системы — равному бесконечности.

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

В описанном я бы назвал несколько причин:

1. Синхронизация между двумя разными системами (основная работала в виде асинхронной с приоритетами (fixed priority executives), а резервная периодическая синхронная (cyclic executive)).
2. Разница сред тестирования и эксплуатации (таймеров).
3. Отстутствие аналитической проверки при внесении изменений, влияющих на время синхронизации.

И да, доказательство корректности имело все шансы поразить проблему точно в цель (;

Выученная беспомощность

Встретил на днях в сети такое понятие, как выученная беспомощность. Много думал (;

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

Пропадание желания ломиться даже в открытые двери

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

Так, это явление много раз наблюдал на студентах, но при этом называл по-другому. Например если человек пытается сдать л.р. несколько раз, то на какой-то из разов у него полностью пропадает желание двигаться дальше. Многое зависит от разных факторов, но в среднем где-то последняя попытка на уровне 3-4-й. Если правила сдачи строги, а попытки заканчиваются, то происходит нечто, из-за чего желание что-то делать напрочь пропадает, даже если до конца дойти остался один шаг. И пропадает практически до конца курса. В связи с этим через пару-тройку лет у меня на каждую из работ выработался индивидуальный подход — если чувствуется, что попытки исчерпываются, то работа пропускается как есть, даже если большие пробелы и огрехи. Но явно об этом нигде не говорится — чтобы оставалось ощущение, что все честно.

Аналогичное явление в рабочем процессе. Появилась идея X — пробуем предложить/обсудить/внедрить с коллегами A, B, C. Если при разных X'ах какой-то из A, B, C не имеет смысла или не пробиваем, то желание ещё раз пропадает, при чем вне зависимости от того, кривые идеи или правильные, работающие или перспективные — по факту подсознательно все срабатывает, так в конце концов выливается в подпольные проекты, решение проблемы в обход A/B/C, уход от митингов с A/B/C и др.. "Осадок остался" (с), но при этом где-то глубоко.

Контроль всего (вторая часть в вики)

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