Bug fixing как часть прикладной психологии

Порой исправление даже самых очевидных ошибок может буксовать из-за особенностей человеческой психологии. Свежий пример: компонент A передаёт компоненту B набор параметров, в том числе текстовые строки. Строки передаются в виде UNICODE_STRING, т.е. как текстовые строки, не требующие завершающего нулевого символа. Не смотря на это, компонент A передавал строки с завершающим NULL (упакованные в UNICODE_STRING), а компонент B проверял приходящие строки на наличие нуля. Так они и работали, пока между ними не вклинился третий компонент X.

Компонент X выборочно менял строки, идущие от A к B, теряя по пути нулевые символы. Что совершенно законно, раз речь идет про UNICODE_STRING. Результат – компонент B ругается страшными словами и ничего не работает.

Встал вопрос кого править. Казалось бы, ответ очевиден – правим B, поскольку иначе придется менять протокол (тип строк) и править всех. Однако не тут-то было. Команда компонента B предъявила «железный» аргумент: наш код не менялся и замечательно работает уже X лет, а тут пришли вы со своим X и всё поломали. (Я тут утрирую, конечно). Ситуацию усугубило то, что исправить ошибку нужно «здесь и сейчас», а потом будет поздно…

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

Конечно, в конце концов, был починен именно компонент B, однако осадок остался…