Главная » Хабрахабр » [Перевод] Любопытные извращения из мира ИТ

[Перевод] Любопытные извращения из мира ИТ

Сайт The Daily WTF уже 14 лет собирает курьёзные, дикие и/или печальные истории из мира ИТ. Я перевёл несколько рассказов, показавшихся мне интересными. Все имена и названия компаний изменены.

На работу за 3 000 миль

Правдивая история из личного опыта нашего автора Snoofle. [Оригинал]

Компания хотела продемонстрировать в своём предложении, что у неё хватит персонала для выполнения этого проекта. Много десятков лет назад оборонный подрядчик DefCon Inc работал на армию США и пытался получить новый контракт на создание какого-то приложения, применяемого в бою. Военные, изучавшие различные коммерческие предложения, увидели кучу новых сотрудников, абсолютно незнакомых с необходимыми процессами, процедурами и требованиями, поэтому передали контракт другой фирме. Поэтому она наняла более тысячи разнообразных программистов, руководителей проектов, менеджеров и так далее. Подрядчик, со своей стороны, уволил всю эту тысячу человек.

Компания снова наняла тысячу человек, чтобы показать, что у неё есть персонал. Спустя несколько месяцев возник ещё один подобный контракт. Ещё через несколько месяцев контракт снова был передан другому подрядчику, и компания снова уволила всю тысячу.

На протяжении двух лет такое повторялось несколько раз.

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

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

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

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

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

Ведь доступ возможен только на месте, в Калифорнии, а все сотрудники живут и работают в Нью-Джерси. Прежде чем соглашаться на поездку, разработчики хотели узнать, как они смогут получать доступ к материалам после изучения. Им сказали, что о подробностях они узнают в Калифорнии.

Ну ладно, все они прилетели на западное побережье, заселились в отели и поехали в офис.

В четверг второй недели работы было решено, что для выполнения всех необходимых модернизаций необходимо примерно два года работы. В тот момент им сообщили обо всех проблемах, которые необходимо устранить. Начиная с ближайшего понедельника. Разработчики опять спросили: «Как же мы будем получать доступ к материалам из Нью-Джерси?» Менеджеры ответили, что вся работа должна выполняться на месте, и они будут оставаться в Калифорнии в течении следующих двух лет.

Как отсутствие 90% времени одного из родителей повлияет на детей? Но, постойте у них же не было возможности обсудить это с семьёй! Какого хрена компания не наняла сотрудников на месте, в Калифорнии, а занималась этим в Нью-Джерси? Захотят ли они жить в гостиницах и аэропортах в течение двух лет?

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

Утром пятницы все сотрудники уволились и направились в аэропорт, чтобы вернуться домой. Можно и не говорить, что остаток рабочего для менеджеры втирали о необходимости жертв ради компании, а разработчики задавались вопросом: «Какого чёрта?» Вечер четверга был занят бесконечными звонками домой.

Однако стали гораздо жёстче, когда дело дошло до разговора с подрядчиком и до выполнении его обещаний о наличии опытного персонала на месте работы. Представители армии повели себя достойно и с пониманием отнеслись к тому, что люди не хотят бросать свои дома и семьи на два года.

В результате контракт с подрядчиком был расторгнут, а на его место наняли для наведения порядка нового.

Случай отказа

[Оригинал]

image

В первый день на новой работе Себастьян не был особо воодушевлён. Он уже многое повидал и набрался равнодушия и пессимизма. Эта новая работа не должна была отличаться ни одной другой: куча надоедливых коллег, плохо продуманных требований, старых кодовых баз, полных спагетти-кода. Но она хорошо оплачивалась, а он устал от своей старой группы, ему надоели одни и те же привычные лица. Поэтому он внутренне приготовился к слегка новым оттенкам той же офисной политики и муторных заданий.

Себастьян просто опустил на несколько уровней свою планку требований к рабочему компьютеру, и вернулся в новый офис. Он даже особо не расстроился, зайдя в ИТ-отдел за своими учётными данными и услышав жужжание и щёлканье старых серверов Packard Bell. Ради этого он мог смириться со многим другим. Да, его должность подразумевала собственный офис и соответствующую оплату.

Он ожидал Windows XP; когда загрузилась Vista, он не был уверен, стоит ли ему радоваться более новой ОС, или ужасаться тому, что это Vista. Его логин сработал с первой попытки, что было приятной неожиданностьюю. «Чтобы испугать меня, потребуется что-то большее», — подумал он и запустил Outlook. Завершив получение полномочий администратора и урезав UAC, он даже на какое-то время мог притвориться, что это «семёрка».

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

Первое письмо было примерно таким:

В ней всё делается правильно. Здравствуйте, Себастьян, добро пожаловать в нашу идеально отточенную рабочую среду. Не забывайте часто сохранять работу! При создании проектных документов вы будете работать с Bonk-Word (веб-приложение для документирования компании IBM). При аварийном завершении Bonk-Word вам необходимо будет написать письмо в отдел ИТ для его перезапуска.

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

Завтра к 9 часам утра у вас должен быть готовый проектный документ. Начните с проектирования решения проблемы со шрифтами на Macintosh, которую мы не можем решить четыре года. Спасибо.

«Шесть страница на завтра?», — забеспокоился Себастьян. «Наверно, я возрадовался эффективности слишком рано. Ну, по крайней мере, не будет скучно», — он хрустнул костяшками пальцев, открыл Bonk-Word и начал разбираться с так называемыми проблемами со шрифтами.

К концу дня он мысленно делал ставки: что свалится первым — Bonk-Word или сама Vista. Первое, что он выяснил — менеджер не шутил о частом сохранении. Но ведение статистики вылетов на листочке почему-то успокаивало Себастьяна. Оба они крашились примерно через каждые полчаса. Простейшие математические действия не впечатляли, но были надёжными. Оно напоминало ему: в мире что-то ещё работает. Стабильными. Регулярными.

Но он был тихим и отдельным. Возможно, в этом офисе Себастьян чувствовал себя одиноко. Он задержался на работе, чтобы изучить разнообразную литературу, посвящённую рендерингу шрифтов, в том числе спецификацию Postscript, сопроводительную литературу с рекомендациями по его использованию и информационные центры в World Wide Web, созданные для коллекционирования мудрости лучших умов отрасли в знакомом и удобном формате вопросов и ответов. Пусть постоянные вылеты раздражали, но Себастьян всё-таки двигался вперёд. Он потратил две страницы на описание того, что можно было рассказать в двух словах. Он пространно описал в документе «создание программы на Python для рендеринга каждого символа».

«Если им нужно шесть страниц, они получат шесть страниц», — думал Себастьян.

Он закончил работу, вышел из здания (которое подозрительно пахло старым кожаным нижним бельём) и медленно подошёл к своему «бесплатному месту на парковке» (ещё одно преимущество, оправдывающее эту работу в его глазах). Первый день оказался странным, но Себастьян видел, что вполне выдержит это в течение как минимум нескольких лет. Медленно — потому что стоянка была совершенно разъедена ржавчиной, и во многих местах бетон полностью отвалился, обнажив арматуру пола и колонн.

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

Скорее всего, это просто формальность, после которой я смогу приступить к работе». «Я сделал, как просили, и в нужном объёме.

В его ушах всё ещё звенела полученная им абсурдная, но жестокая критика. Спустя час униженный и измотанный Себастьян вернулся в свой офис. Кроме того, ему недвусмысленно сообщили, что отладить шрифты с помощью Python «невозможно». По словам президента, его заголовки разделов были едва «зеленоватыми», а не зелёными, как требовала компания, а заголовки глав — непростительно «красноватыми» вместо ожидаемо фиолетовых. Ожидая звонка президента, менеджер Себастьяна расхваливал документ, но во время проверки не сказал ни слова, неотрывно смотря на кирпичную стену за своим столом. Вместо него Себастьяну приказали работать на C++ и использовать «чудесные» программные библиотеки компании.

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

«Взглянем на эти библиотеки». «Ну ладно», — сказал он вслух в пустом офисе.

Естественно, что в такой помешанной на документах компании документация к «чудесным» библиотекам должна быть точно набрана правильным шрифтом с идеально точным оттенком, с правильными заголовками глав и названиями разделов. Первое, что он начал искать — это документация. Была уйма проектных документов с идеальным зелёным и фиолетовым цветами. Но документации… не было. Но в них описывалась только методология разработки библиотеки и ничего не говорилось об её использовании.

«Возможно, код самодокументированный...» «Я что, схожу с ума?», — спросил себя Себастьян, когда машина перезагрузилась в третий раз.

Он испытал ужас, но особого удивления не было: библиотеки состояли из плохо продуманных обёрток строковых функций из стандартной библиотеки.

Его ежедневно вызывали для очередного раунда словесных запугиваний. Несмотря на постоянные фиаско, Себастьян держал удар. Себастьян отказался от собственной библиотеки компании, начав решать проблему на известном ему Python; в конце концов, если его всё равно будут гнобить, то зачем делать то, что тебе говорят? Компания за четыре года не могла справиться с этой шрифтовой проблемой; тем не менее, ничто из предлагаемого им не устраивало президента. 488 неискоренимых, неисправимых, не решаемых заплатками конструктивных ошибок. Но что бы он ни применял: собственный тестер на Python, или тестер Microsoft, или Apple, или Adobe — шрифт оставался полным хаосом.

Он утверждал, что это вина Себастьяна, ведь тот не использует великолепные библиотеки C++. Президент категорически отказывался признать правду.

Он попрощался со своим милым офисом и адской машинкой, которую выдавали за компьютер. Исчерпав все варианты, Себастьян оставил ключ от ржавеющего гаража на столе менеджера вместе с заявлением об уходе. Глубоко вдохнул, в последний раз почувствовав муторный запах кожи и вышел, окончательно и бесповоротно.

Почему-то он сомневался, что будет скучать по компании.

От такого здравоохранения можно заболеть

[Оригинал]

Если вы жили жизнью праведника, то эти системы были просто разными приложениями на одной платформе. В любой отрасли есть информация, которую необходимо переносить между несовместимыми системами. Представьте какое-нибудь Java-приложение в Safari под какой-нибудь версией Mac OS, которому нужно обмениваться данными с какой-то версией . Однако если вы отклонились от благого пути, то эти системы были написаны на разных языках для разных платформ, работающих в разных операционных системах с разным порядком следования байтов. NET под какой-нибудь версией Windows, которой, в свою очередь, нужно общаться с какой-то версией COBOL с двоичным кодом EBCIDIC, работающей на каком-нибудь мейнфрейме.

Задолго до того, как кто-нибудь мог вообразить подобный кошмар, мы работали с SGML, который деградировал эволюционировал в XML, который должен быть тривиальным приемлемым способом задания содержащихся в документе формата и полей с доступным на всех платформах парсером, благодаря чему информацией можно обмениваться, не зная ничего, кроме DTD и/или схемы для валидации и парсинга.

Не надеясь на лучшее, для упрощения работы мы написали поверх XML библиотеки обёрток.

К сожалению, они с задачей не справились.

В отрасли здравоохранения какие-то работающие с сopen-source ребята создали проект (H)ealthcare (API), или HAPI, который по сути является объектно-ориентированным парсером текстовых сообщений отрасли здравоохранения. К сожалению, они, похоже, страдали от синдрома «не знаю, когда остановиться».

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

О чём вообще думали эти разработчики? Это API с приблизительно 15 тысячами вызовов методов!

Поэтому я сразу же начинаю думать о каком-нибудь массиве или списке. Например, класс: EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO может иметь от нуля и более product service разделов. Поэтому вместо чего-то наподобие такого:

EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO info = ...; List<EHC_E15_PRODUCT_SERVICE_SECTION> prodServices = info.getProductServices(); // итерируем

… нам требуется выполнить что-то из этого:

// Получаем подструктуру EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO info = ...; // Получаем из подструктуры встроенные product-service // ...если мы точно знаем, что в сообщение он только один: EHC_E15_PRODUCT_SERVICE_SECTION prodSvc = info.getPRODUCT_SERVICE_SECTION(); // ...если мы не знаем, сколько их будет: int n = infos.getPRODUCT_SERVICE_SECTIONReps(); for (int i=0; i<n; i++) // ...или можно просто взять их и выполнить итерацию List<EHC_E15_PRODUCT_SERVICE_SECTION> allSvcs = info.getPRODUCT_SERVICE_SECTIONAll();

… и нужно вызвать нужный метод, иначе рискуешь получить исключение. Но если существует множество способов выполнения одной задачи через API, то возникает множество способов её выполнения в коде с помощью API, что неизбежно приводит к проблемам.

Но потом ты осознаёшь, что некоторые из этих структур данных встроены на десять и более уровней вглубь, у каждой есть десятки подструктур и/или полей, и у всех них несколько методов доступа. Можно сказать: «Да ладно, всё не ТАК уж плохо»; достаточно использовать то, что тебе нужно. А потом ты осознаёшь, что разработчики HAPI устали печатать текст и начали использовать для всего сокращения с такими понятными названиями структур данных, как LA1, ILT и PCR. Да ещё у всех них реально длинные названия.

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

Ему регулярно давали задания (на выполнение которых отводилось по несколько недель) по простому парсингу одного дополнительного поля. Аноним работал в здравоохранении и занимался поддержкой библиотеки, обёрнутой вокруг HAPI. Потратив кучу времени на пережёвывание томов документации по API, он написал общий парсер из одного класса в 300 строк с несколькими split, substring, parseDate и parseInt, в качестве замены всего интерфейса.

После этого добавление нового поля стало занимать не больше десяти минут.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Перевод] IntelliCode теперь и в TypeScript/JavaScript

На Build 2018 мы анонсировали Visual Studio IntelliCode: набор AI-инструментов, которые способствуют более качественной разработке. В сотрудничестве с командой IntelliCode мы рады сообщить, что теперь IntelliCode доступен пользователям TypeScript/JavaScript через расширение IntelliCode для VS Code. Что такое IntelliCode? IntelliCode дополняет ...

Анонимный Дед Мороз 2018-2019: пост хвастовства новогодними подарками

Анонимный Дед Мороз 2018-2019 набирает обороты: каждый пятый участник отметил подарок отправленным, а несколько человек даже нашли в себе силы встать из-за компьютера и забрать посылку на почте. Давайте зайдем в комментарии и все у них разузнаем! Что же именно ...