Человеческий фактор в программировании.

Виртуальная видимость.

Интересно отметить, что для получения выигрыша от видимости в работе необязательно, чтобы кто-нибудь сказал хоть слово. Большинство из нас сталкивалось со случаем, когда какая-то ошибка никак не находилась. Вы изучили тестовый прогон и листинг. Вы знаете, что проблема скрыта в одном из блоков кода, но сколько бы вы по нему не проходили, вам не удается обнаружить, где собака зарыта. Отчаявшись, вы стучите в дверь соседней комнаты и настойчиво требуете помощи. В конце концов, Шарлотта имеет степень Рh.D в Соmрutеr Sсiеnсе. Вы начинаете описывать ей суть проблемы. Как только вы добираетесь до цикла, что-то бросается вам в глаза. Шарлотта еще не успела ничего сказать, а вы тихо восклицаете: «О!» — и начинаете робко выходить за дверь, на ходу бормоча благодарности. «Пожалуйста, в любое время», — слышите вы в ответ.

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

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

В большинстве ситуаций преимущества видимости существенно возрастают, если к процессу подключается второй человек, однако с каждым новым человеком отдача снижается. Конечно, бывают и исключения из правил, особенно на самых первых или самых последних стадиях разработки системы. Метод мозгового штурма лучше работает при большом количестве мозгов, способных пробудить этот шторм.[35] Небольшие группы смогут создать только пылевой вихрь или могут просто сесть и посидеть спокойно. В разборе кода и анализе дизайнерских проектов также полезно участие нескольких критиков. Чем больше людей просмотрит работу, тем с большей вероятностью могут быть обнаружены ошибки и упущения. С другой стороны, в реальных задачах, связанных с поиском хорошей архитектуры программного обеспечения при наличии сложных взаимосвязанных ограничений, участие слишком большого количества умов зачастую приводит к взаимным стычкам. Вероятно, в качестве оптимального значения здесь подойдет известное правило «7 ± 2».