[life;work;prog] Так вот о (казалось бы) простой фразе на русском языке

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

История такова. На занятии по английскому языку, при изучении темы сравнительных степеней прилагательных нужно было исходя из данных о степени безопасности городов Хельсинки и Рио-Де-Жанейро составить предложение на английском языке, которое бы состояло из слов: Helsinki, not, dangerous, Rio de Janeiro (причем, по устоявшейся для конкретного учебника практике, слова должны были идти именно в таком порядке).

Казалось бы, автоматически напрашивается вариант “Helsinki is not as dangerous as Rio de Janeiro”. Однако, мой коллега составил предложение, емнип, “Helsinki is not more dangerous than Rio de Janeiro”.

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

1. Хельсинки не так опасен, как Рио-де-Жанейро.

2. Хельсинки не более опасен, чем Рио-де-Жанейро.

В попытке доказать коллеге, что первая фраза явно объявляет Хельсинки более безопасным по сравнении с Рио-де-Жанейро, я был поставлен перед фактом, что две эти фразы являются словесными описаниями двух математических выражений:

1. danger(Х) != danger(РдЖ).

2. danger(Х) <= danger(РдЖ).

При этом, если смотреть только с математической точки зрения, вторая фраза дает более точное описание степени безопасности Хельсинки – он менее опасен, ну ли, в крайнем случае, так же опасен, как Рио-де-Жанейро. Тогда как первая фраза не дает информации о том, более или менее опасно в Хельсинки. Лишь о том, что степень опасности там иная. А вот в какую сторону – не известно.

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

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

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

В-третьих, почему управлять людьми не просто. Опять же, из-за контекста. Руководитель живет в своем контексте, исполнитель в своем. Поэтому когда руководитель говорит “мне нужно решение проблемы Y”, то исполнитель это может воспринять как “мне нужно сделать фичу X”. Поэтому приходится формулировать задания без умолчаний, чтобы исполнитель воспринял их точно и однозначно (а тут см. пункт “во-первых”).

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

При этом важен и еще один фактор: если в команде соберется 100% единомышленников, которые “сидят на одной волне” и понимают друг друга с полуслова, то это не есть хорошо. Скорее здесь произойдет массовое “замыливание” – глядя на проблему все будут видеть ее только с одной стороны и искать ее решения в одной и той же плоскости. Поэтому в команде обязательно должен быть кто-то, кто мыслит иначе. Своего рода “белая ворона”, обеспечивающая “разрыв шаблонов” остальным членам команды. Сколько таких ворон нужно – это вопрос. Явно не много, но сколько точно не знаю. Впрочем, построение успешных команд – это для меня пока Terra Incognita.

Вот такой вот поток сознания появился из-за несложного упражнения на уроке английского. Уж точно “нам не дано предугадать, как наше слово отзовется”, хотя от программистов и начальников именно это и требуется ;)