April 30th, 2008

Заваровский

Открываем или выдумываем?

Сейчас у falcao идет подзамочная дискуссия о том, изобретаем ли мы новое или открываем его (там обсуждается один аргумент по частному вопросу). Припоминаю другие дискуссии на эту тему или просто высказывания - наблюдаю поразительное единодушие: falcao и sowa относительно математики, а flying_bear относительно физики однозначно высказывались за то, что они открывают, т.е. истины этих наук, сами объекты этих наук со всеми их свойствами существуют объективно, независимо от самих исследователей и существуют вечно, т.е. в своей полноте уже сейчас. Не знаю, как обстоит дело в биологии - не припомню высказывания на этот счет ivanov_petrov - было бы интересно узнать. Наверное, они правы - я не собираюсь оспаривать эту точку зрения, просто не имею обоснованной позиции по этому вопросу.
Но мне тут пришло в голову - а в моей профессии, в автоматизации производственных предприятий, эта позиция - открываю, а не изобретаю - контрпродуктивна. Не просто не подходит, она однозначно вредна. Когда я автоматизирую какой-то бизнес-процесс, я выявляю в нем основные операции, контрольные точки, в конце концов разрабатываю структуру данных и алгоритмы обработки. По сути, это достаточно типовая задача, можно сказать - математическая. Но при решении я знаю, что через некоторое время бизнес-процессы изменятся (предприятие развивается, меняется сам рынок - куча внутренних и внешних процессов, предсказуемых только в самых общих чертах), и мне придется переделывать то, что я сейчас сделаю. Предприятие меняется и соответственно меняется его информационная система. Так вот - как мне решать эту задачу? Существует ли "идеальное" решение этой задачи, то, которое мне надо "открыть"? Сейчас я могу получить всю информацию о текущем состоянии (тоже не всегда, но ладно) и для этих условий подобрать оптимальный алгоритм (иногда даже можно математически доказать, что лучше нельзя). Но будет ли это решение на самом деле идеальным? Как правило - нет. Чем лучше решение этой современной задачи, тем неустойчивее оно по отношению к возможным изменениям условий, изменениям предмета автоматизации. То есть я должен выбрать такое решение, которое потом удобно будет адаптировать к изменениям реальности.
С другой стороны, если я пытаюсь учесть как можно больше возможных вариантов развития, т.е. сделать решение более универсальным, то мне приходится платить за это слишком многим: и намного больше работы (и возможных ошибок в коде), и сложнее алгоритм (и дольше), да и пользователю сложнее, а значит - больше человеческих ошибок. Значит, мне надо выбрать несколько направлений, как может изменяться бизнес-процесс, и заложить возможность легкого развития системы в этих направлениях. Если угадал - значит, потом мне будет легко адаптировать инфосистему к изменениям. Не угадал - предстоит много работы.
Да, мой опыт позволяет многое предугадывать, но получается не всегда. Ключевое слово тут - предугадывать, это всегда угадайка. Если же я поверю в то, что существует некое идеальное решение и мне надо его "открыть" - это будет катастрофа. Неопределенность, будущая неопределенность входит существенной частью в мою работу. Если представить, что биологический вид "думает", как бы ему измениться на будущее (ламаркизм такой) - вот реальность моей работы. Принять в ней существование "идеальных" решений моих задач можно только приняв полную лапласовскую предопределенность, более того - практическую предопределенность, т.е. такую, которую я могу познать на практике. Расчитывать на это не приходится, поэтому я не открываю, а изобретаю - не идеальное, а приемлемое, заведомо не оптимальное и гадательно предвосхищающее будущее.

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

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