Логичное не всегда верное

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

Сделать такую единичную плату стоило около 2 килоевро. Большая Компания, когда получала плату, проектировала корпуса для контроллеров и запускала производство.

Однажды в разговоре со Свеном выяснилось, что время от времени Большая Компания делала ”милые” такие ошибки, когда корпус контроллера имел отверстия для гнезд входа-выхода плат не там, где им следовало быть. В итоге, платы вставляются нормально, но их никак не подключить, ясное дело.

В этом случае Свен с братом просто переделывали свои схемы так, чтобы входы-выходы были там, где они оказались на корпусе. Затем снова отсылали схемы на завод для производства одной платы и платили 2 килоевра. Причем платили именно они, а не Большая Компания.

Тогда меня сильно удивил такой подход – с какого перепуга я должен платить за ошибки других? Свен тогда привел не совсем логичный аргумент – ”ну ведь нам легче потратить 2 килоевра, чем Большой Компании в 20 раз больше на перепроектирование и новое производство корпусов”.

Логика странная – вернее, была странной для меня до недавнего времени.

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

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

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

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

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