этот неуклюжий, нефункциональный мир Корпоративных Решений

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

Менеджеры обожают приобретать продукты с эмблеммой «industrial strength architecture». Орды юных программистов обучаются в университетах доктрине, согласно которой использовать следует лишь «выведенные в лабораторных условиях, чистые» языки программирования, ктороые так славно подходят для иллюстрирования абстрактных концепций «теории вычислительной техники» (Computer Science).
Такое ощущение, что мало кто замечает, как немного мы получаем, приобретая супер-дорогие корпоративные софтверные решения.
Этой статьей я хочу предостеречь коллег от возможных ошибок. Хотя некоторые, уверен, будут возмущены, видя, как я наезжаю на их любимые технологии. Уверяю, я не хотел никого обидеть :)
Итак, на чем я буду основывать свои выводы? Все очень просто: я работаю в крупной компании, которая реализует различные софтверные проекты, в том числе и на базе признанных «корпоративных технологий». Просто взглянем на сопроводительные документы к этим проектам. Заглянем, так сказать, за сцену
Так, вот проекты на Java. Посмотрим, может быть я ошибаюсь и Java — это и есть обещанный «путь в светлое будущее»? Смотрим в графики готовности проектов на Java... Так, что у нас тут? Простейшее веб-приложение. Время сдачи переносилось уже 6 раз, по прежнему проблемы со стабильностью работы приложения, 300-процентное превышение бюджета, невозможность заставить корректно работать элементранейшие вещи, более 10000 строк кода вспомогательных классов для решения проблемы получения пары байт из базы данных!Я не поленился сравнить проекты подобные этому с эквивалентными PHP-проектами, и ни один из последних не имел каких-либо из перечисленных проблем. Фактически, проекты на PHP представляли собой лучшие решения, реализованные быстрее при большем количестве функций.
Ладно, идем дальше... Ага, Novell Portal Services — «портальное решение масштаба предприятия, закрывающее все ваши корпоративные потребности», вспоминаю я строки из брошюры. Звучит солидно, ничего не скажешь. А теперь откроем папку с материалами по управлению проектом. Я вижу: проблемы со стабильностью, последний дэдлайн сдачи — 18 МЕСЯЦЕВ назад, 200%-ное превышение бюджета, тысячи строк «выброшенного» кода (попытка заставить работать некоторые плагины, которая, несмотря на титанические услилия, провалилась), сбои в базе данных, многочисленные проблемы с безопасностью — и все это про портал, имеющий ненамного больше функций, чем статический веб-сайт. Хм...
А вот и проект на Oracle. Лидер в области СУБД, скажете вы. Прямо на коробке с «Ораклом» написано, что продукт позволит вам сэкономить тучу денег на разработке и обслуживании. ОК, почему же тогда разработчики до сих пор, по прошествии 3 месяцев с дедлайна, пытаются заставить этот проект удовлетворительно работать? Я спросил у коллектива разработчиков. Оказывается, есть проблема в чтении данных из BLOB’а, трудности с конфигурацией требуют прибытия сертифицированного специалиста для тонкой настройки.
Буквально за соседней дверью сидит комманда разработчиков под MySQL, я поделился с ними проблемами «ораклистов» — ребята плакали от смеху. Они сказали, что часто случается, когда их комманда спокойно и в полном объеме реализует те фичи, к которым «ораклисты» даже не знают как подступиться, чтобы получить хотя бы базовый функционал.
Но постойте: PHP — не «настоящий» язык программирования, а MySQL — не «настоящая» база данных, правда? ;) Недавно на K5 /* сокращенное, «домашнее» название проекта kuro5hin.org — прим. переводчика */ читал статью про тонкую настройку MySQL, и в конце толпа комментариев вроде "fuck MySQL, use Oracle/PostgreSQL" /* здесь оставлен англоязычный вариант по причине его колоритности и лаконичности — прим. переводчика */. Это, по моему, чистой воды снобизм. Может быть PHP MySQL /* сюда же — непонятно почему гонимые CGI и Perl — прим. переводчика */ — не «настоящие» технологии, но если с их помощью я могу решить поставленную передо мной задачу, и решить хорошо — я буду пользоваться ими вне зависимости от их репутации.
ОК, теперь отвлечемся от материалов наших корпоративных проектов и зададимся некоторыми насущными вопросами.
Почему так мучительно сложно создать работающий проект с помощью «корпоративных решений»? Я начинаю склоняться к мнению, что ПО масштаба предприятия так дорого стоит не по причине богатства функционала и стабильности, а потому, что на базе него практически невозможно самостоятельно реализовать проект.
Почему же индустрия с такой готовностью тратит в пустую кучу денег? Не надо быть великим мыслителем, чтобы увидеть в этом некоторую закономерность: кому-то выгодно держать цены на софт высокими, а сам софт делать настолько запутанным, чтобы разобраться в нем могли только специалисты, прошедшие соответсвующую подготовку, для чего существуют сертифицированные курсы, тренинги и проч.
Но почему разработчики — простые, так сказать, труженики клавиатуры — также являются частью этого безумия? Этому есть несколько причин. Во-первых, считается, что «корпоративно-ориентированному» разработчику (Java, Oracle и т.п.) легче найти работу, и менее вероятно быть уволенным. Во-вторых, эти технологии нам активно скармливают с самого начала обучения, подливают масла в огонь и друзья-приятели, «старшие товарищи»: «Зачем тебе <assembler, perl, ruby, C и др.>, ты с этим в жизни не устроишься. Выучи что-нибудь солидное и модное — возьмут работать в крупную компанию, сразу на хорошую зарплату». Опять же принцип почасовой оплаты, принятый в некоторых местах: чем больше я мучаюсь с разработкой, чем дольше и чем с более умным лицом — тем больше я получу.
А посмотрите на наших менеджеров: как они «смотрят в рот» консультантам, с умным видом предлагающим мигрировать на, например, комплексное решение (для всех ИТ-нужд предприятия) от того или иного софтверного гиганта.
Я думаю, индустрии пора «воспрянуть ото сна». Нет, я не говорю что надо заклеймить как негодный, например, язык Java. Есть много вещей, где применение Java оправдано, но есть и не меньше случаев, когда не стоит притягивать Java за уши! Да, технологии вроде PHP /* или CGI/Perl */ используется «всяким сбродом» без высшего технического образования, чуть ли не сопливыми пятиклашками, но может быть есть смысл задуматься, почему профессионалы от ИТ отказывают себе в выгодах от простоты и продуктивности этих технологий, когда «хоббийный» сектор наслаждается этими выгодами уже несколько лет!
Я знаю многих разработчиков, которые согласны со мной в том, что перегруженные, навороченные решения только жрут время и деньги, поддерживая стоимость разработок на чрезвычайно высоком уровне.
...Спросите у себя, почему вы пребываете в состоянии детского восторга, когда наконец-то успешно завершили сериализацию/десериализацию объекта в С#, при том что тут же, за соседним столом разработчик на PHP решил аналогичную проблему тупым вызовом специального метода и уже 3 часа как занимается другими вещами...

WAKE UP! — WAKE UP! — WAKE UP! (с) Rage Against the Machine.
Просыпайся, народ!

thasmudyan, перевод Alice D. Saemon, впервые опубликовано на kugo5hin.org.