Вопиющая эффективность

Если бы кто-то меня спрашивал, то я бы назвал уходящую эпоху разработки ПО временем "вопиющей эффективности".

Одна компания разрабатывала приложение для управления документами. Вопиюще эффективным решением в рамках этого проекта была создана должность Идеолога™ Разработки. В его обязанности входило делиться мудростью и наставлять команду на путь истинный. Человек то был не простой, а сильно-больно проникшийся идеями распределённых SCM и объектными базами данных. По его указке вся команда вопиюще эффективно использовала Mercurial, а базой данных для своего приложения выбрала RavenDB. Приложение сыпало багами, а временами задумывалось секунд на 40 на ровном месте. В какой-то момент Идеологу™ Разработки продемонстрировали наглядно на unit-тестах что дело в RavenDB, который при определённых условиях несказанно тупит, игнорирует заявленную транзакционность, а в иных случаях и вовсе теряет данные. Было предложено перейти на sqlite. Но Идеолог™ Разработки заявил что вся команда просто не понимает вопиющей эффективности технологии, а по сему должна думать шире и код писать лучше. Долго ли, коротко ли, команда была разогнана, а проект передан другим людям. Спустя годы, разработка продукта успешно завершилась. Я ради интереса скачал демо-версию с официального сайта и разобрал её reflector-ом. Что бы вы думали? От RavenDB не осталось и следа, а все данные переехали в sqlite. Судьба Идеолога™ Разработки осталась неизвестной, но злые языки поговаривали что его повысили в должности.

А однажды коллега по цеху поплакался мне что пишет WebAPI-интерфейс для RabbitMQ. Я уж было понимающе кивнул — мол — хотели, видимо, встроить в продукт какой-нибудь красивый мониторинг состояния очереди сообщений, загруженности топиков, скорости обработки. "Нет-нет, что ты" — замахал руками коллега — "просто наш вопиюще эффективный архитектор настаивает на вопиюще эффективных микросервисах, а они должны общаться между собой исключительно по WebAPI. Иначе это не вопиюще эффективные микросервисы, а фигня на палке". Мы оба замолчали и посмотрели вдаль. "Зато мне зарплату повысили" — добавил коллега после выдержанной паузы.

И вот жила-была ещё одна система. Всё по-простому: бекенд на C# о полусотне сущностей, да пятнадцати сервисах с бизнес-логикой. WebAPI, бэкофис. Работала как часы, развивалась неспешными темпами. Но тут начальник разработки прочёл книжку про CQRS и Domain-Driven Design и решил что существующие сервисы не столь вопиюще эффективны. Из команды был выбран наиболее усердный программист и отправлен делать PoC. Спустя полгода разработки стало очевидно, что в новой DDD-архитектуре на каждую операцию придётся создавать ажно по 3, а иногда и по 5 новых классов. PoC толком не тестировался, потому что было сложно замОчить EF-ный DbContext и временами падал по непонятным (из-за загрязнённого stack trace-а) причинам. Не смотря на это, новый подход был сочтён вопиюще эффективным. Усердного программиста повысили до тимлида, подняли зарплату и наняли ему в команду мидлов для поддержки этого чуда природы. Спустя несколько лет компания (будучи признана вопиюще эффективной) была несколько раз перепродана, да с прибылью. А о том, что DDD-часть системы еле шевелится, а большинство бизнес-операций по-прежнему выполняются через те самые пятнадцать сервисов с бизнес-логикой, говорить было как-то... не принято.

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

Такие дела

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