Статья была опубликована 24 июня 2008 года, но несмотря на свою древность она очень показательна. В ней есть госзаказ, попил средств, бюрократия и эффективный менеджмент во всей красе. А написана она не про Россию, а про Францию.
***
Несколько лет назад меня пригласили консультантом по одному проекту ПО для крупной французской технологической компании. Увиденное выходит за рамки всего, что я мог представить в разработке. Простое отсутствие профессиональной компетентности оказалось не самым худшим. Гораздо хуже было крайнее презрение к человеческому достоинству, что показалось мне сравнимо с тюрьмой в том виде, как я её представляю. Вот список, проверьте сами.
Масштаб.
- разработка программного обеспечения для государственного агентства.
- сложность низкая, с несколькими вывертами.
Правительство платит авансом несколько миллионов евро. План разработки на два-три года. Для начала компания нанимает несколько разработчиков и продолжает удваивать размер команды каждые три месяца или около того, осваивая бюджет по мере поступления средств.
7 лет спустя проект ещё не оформился. Набегают штрафы по несколько тысяч евро в сутки. Руководство решает сократить расходы и производит увольнения опытных сотрудников, нанимая людей с небольшим или нулевым опытом работы.
10 лет спустя, учитывая катастрофическое состояние проекта, менеджмент среднего звена решает нанять некоторых людей с опытом разработки, чтобы вернуться в график. Средняя текучка среди новичков: три месяца. Это минимальный срок, чтобы иметь право уволиться во Франции.
12 лет спустя проект ещё не закончен. Компания снова попадает на ежедневные штрафы, выставляя новые счета правительству за постоянно растущий поток запросов на изменение. Идёт 2008 год.
Цифры.
- 6 миллионов строк кода
- На основе C++
- Более 50 000+ классов
- Конкретная версия C++ устарела, но привязана к компилятору, который распространяется только с одной (не поддерживаемой) операционной системой
- На основе CORBA
- СУБД от компании-банкрота
- Несколько слоёв поверх друг друга для обработки GUI, ни один из которых фактически не поддерживается авторами
- Сборка занимает 48 часов на 32 параллельных машинах
- От 40 до 50 одновременных процессов для запуска только пользовательского интерфейса
- Отсутствие динамического связывания библиотек: размеры исполняемых файлов начинаются с нескольких сотен мегабайт
- Время запуска программы: около 15 минут
- Среднее время между сбоями: от 30 секунд до 30 минут
Ни один разработчик не скажет, что C++ - простой язык. Наоборот, один из самых сложных. На самом деле он настолько сложен, что даже его создатели признаются, что ещё не овладели всем. См. признание Страуструпа в его знаменитом "интервью", которое сочинили как розыгрыш.
Столкнувшись с таким невероятным лабиринтом бездонной сложности, люди реагируют по-разному. Все гики-выскочки слышали о C++ и хотят доказать, что тоже могут на нём программировать. Они бесстрашно погружаются - и получают увечья до неузнаваемости. Тратят бесчисленные часы, пытаясь понять, почему куча абракадабры бесконечно крашится без видимой причины. У кого есть разум - те быстро уходят на другие языки и другие проекты. Жизнь слишком коротка.
Поддерживать крупный проект сложно независимо от языка. Только представьте, что сотрудникам нужно поддерживать 6 МИЛЛИОНОВ СТРОК кода - и вы получите представление о том, как далеко может зайти безумная разработка. Шесть миллионов - большое число. Если читать по одной строке в секунду, то вы просидите перед экраном семьдесят дней без перерыва.
Для понимания масштаба расскажу два случая.
Одному разработчику поставили задачу проверить, почему нажатие правой кнопкой мыши в интерфейсе полностью подвешивает приложение. После нескольких дней тщательного изучения и невероятного количества терпения он обнаружил, что щелчок правой кнопкой мыши работает нормально, просто контекстное меню появляется примерно через 45 минут. Все меню динамически генерируются из кучи (статического!) контента при каждом нажатии правой кнопкой мыши в главном окне.
В какой-то момент пользователи сообщают, что вообще не работает опция "Загрузить данные с CD-ROM". Потребовалось несколько недель, чтобы разобраться. Но в итоге баг-репорт пометили как "Решён ранее", потому что данные загружались корректно. Разве что загрузка 700 МБ занимала семь суток. Но терпение - это добродетель.
Управление версиями пошло вразнос.
Прошло несколько лет, прежде чем одному смышлёному парню в команде пришла идея использовать инструменты для управления версиями. Первая попытка не слишком получилась, так что команда переключилась на другую систему. А через пару лет - на третью, теряя всю историю с каждым переходом.
В итоге выбрали инструмент-катастрофу с GUI. Мерзость, исходящую непосредственно из Швеции. Пришлось выделить на полный рабочий день команду из четырёх человек для выполнения большинства задач в этой системе. Выглядело примерно так:
- Для первого извлечения кода (checkout) следовало назначить встречу с командой контроля версий. Встречу обычно назначали через неделю.
- Редактирование файлов не разрешалось без разрешения менеджеров среднего звена. Вы должны заранее сообщить своему менеджеру, какие файлы хотите отредактировать, а затем отправить официальный запрос на получение разрешения, который команда управления версиями может рассмотреть в течение нескольких дней.
- Каждая модификация кода запускает ветвление. Это значит, что потом нужно объединить все полученные модификации. С таким количеством файлов в хранилище вы можете подумать, что редко встретятся два человека, работающие над одним и тем же файлом. Но оказалось, что большая часть работы идёт над теми же 100 файлами или около того.
- Возврат (check-in) проходит через болезненную процедуру, когда ваш код проверяет автоматическая программа для обнаружения ошибок, а потом менеджеры. Нечего и говорить, что с таким подходом ошибки плодятся быстрее, чем их успевают исправлять. Внимательный взгляд на количество зарегистрированных ошибок показал, что на каждое исправление появлялось две новых ошибки.
- Управление версиями вообще простое. У старой программы - первая версия, у сегодняшней - вторая, у будущей - третья. Никто не может сказать, какую версию отправили заказчику.
(От себя добавлю, что описаный выше процесс, это просто ужас. Системы управления версиями для того и нужны, чтобы разработчики в любой момент могли редактировать нужный код. Если изменение кода требует написание предварительного запроса за 1 неделю, то работа не сдвинется с места. И если проект занимает 6 млн. строк кода, а основная работа ведется в 100 файлах, то никакая система управления версиями не поможет)
В какой-то момент была назначена официальная дата выпуска, совершенно оторванная от планов команды. Когда пришёл день, клиенту фактически отправили пустой компакт-диск с инструкциями по установке, потому что никто не смог собрать софт в течение нескольких недель. Клиент узнал, что ему прислали пустой диск, официально пожаловался - и получил старую версию. Он узнал об этом, потому что отображаемая дата в поле "О программе" оказалась такой же, как и в прошлом году.
Кадры.
С таким большим количеством народу вообще без опыта разработки ПО разве удивительно, что ошибки плодились в огромном количестве? Какой-то особо одарённый менеджер выяснил, что затраты на персонал - главные затраты в проекте чистой разработки ПО. Совсем не испуганный этим необычайным открытием, он решил уволить всех людей хоть с каким-то опытом, но сохранить всех менеджеров. Было не редкостью видеть книжки "C++ для чайников" на столах многих сотрудников.
Познакомьтесь с командой - 20 разработчиков, 35 менеджеров. Вы не ошиблись: менеджеров больше, чем реальных разработчиков.
Менеджеры продолжают организовывать встречи, где они снова и снова показывают одну и ту же презентацию PowerPoint AD до отвращения, в то время как разработчики убивают время, болтая в огромном офисе открытого типа.
Немногие менеджеры имеют опыт работы в индустрии ПО. В то время как раз SCO судилась с IBM по поводу Linux. Даже если всё было блефом, но реально действовало на всех этих людей, которые понимали, что скоро придётся платить за свободные программы. Никто из них никогда не упоминает "Software Libre", но все они знают о "Software Gratuit". Излишне говорить, что проект напичкан библиотеками GNU, а эти ребята понятия не имеют, что так проект становится совместимым с GNU. Хотя ладно, учитывая ужасное качество этого кода, никто никогда не будет настаивать, чтобы они открыли исходники.
Технические знания ниже плинтуса. Мало кто знает об интернете. Те, кто знает, думает, что он создан для порно. Упомянете, что вы что-то видели в интернете — и вам начнут подмигивать и улыбаться.
Добро пожаловать в ад.
Всё это было бы забавно, если бы высшее руководство не вело себя как нацисты в концлагере. Просто приведу несколько примеров.
- Запрещено приходить на работу после 9 утра. Однажды старший менеджер стоял перед главными воротами и тут же увольнял всех, кто пришел после 9:01. Под раздачу попали в том числе ряд менеджеров и продажников.
- Курильщики берут больше перерывов, поэтому меньше работают. Руководство попыталось заставить всех бросить курить по приказу. Не получилось.
- Кофе-машины регулярно выходят из строя на несколько дней. Те, кто пьёт кофе, меньше работают, чем те, кто неотрывно сидит за своим столом, набирая драгоценные строки кода.
- Те же кофе-машины выключают всякий раз, когда чиновники приходят в офис, чтобы создать впечатление, что все на работе.
- Туалеты самые отвратительные, какие я видел в жизни. Вероятно, идея заключалась в увеличении производительности: чем меньше времени вы тратите в туалете, тем больше (и лучше) работаете.
Наверное, вы задаётесь вопросом, зачем же люди продолжали приходить на работу в такое место. Первой и главной причиной стал глубокий экономический кризис, который переживала Франция в то время (и до сих пор, в определённой степени, переживает). Наличие работы и заработной платы считается привилегией, независимо от условий.
Другая причина заключалась в том, что для многих это была первая работа. Без какого-то сравнения невозможно оценить, насколько ваша работа отстой. Большинство новичков считали совершенно нормальным, что вынуждены приходить ровно в 9:00 или быть уволенными, когда абсолютно ничего не накладывало такого ограничения, кроме больного ума менеджера.
Что касается того, как правительство позволяет подобное: мы все знаем, как это работает. Ребята, отвечающие за бюджет в министерстве, дружат с топ-менеджерами в ряде компаний. В такой стране, как Франция, коррупция не редкость на этом уровне, она в основном не раскрывается и редко преследуется по закону. Видимо, это относится не только к Франции. Я слышал такие же истории из других мест Европы и из США.
В следующий раз при мысли, что твоя работа отстой - подумай еще раз.
Комментарии
В современных конторах где разработчиками управляют эффективные, но безграмотные менеджеры, такой подход крайне вреден.
Есть два разработчика. Один светлый джедай — ранняя оптимизация, продуманная архитектура, качественный код. Второй — тёмный ситх, он пишет как конь копытом, главное побыстрее. Внимание, вопрос: кто из них будет на лучшем счету у миньеджеров?
Правильно, второй. Потому что он пишет, укладываясь в спринты скрама, а потом выдаёт оптимизацию в сотни процентов по скорости, просто поубирав ненужные циклы. А первый с его качественным кодом во-первых в сроки может не уложиться, а во вторых ну не получится в разы оптимизировать уже хороший код. А результат... А кого нынче волнует результат?..
Вы несистемно мыслите: какая-такая оптимизация? Надо "фичи" гнать!
Если где-то чего-то не хватает - уходим в облака, которые масштабируются по щелчку :)
Я сча скажу ужасное, но я вижу за этим логику и смысл: в большинстве веб-проектов время разработки стОит гораздо дороже железа. На продукт, который бежит в одном экземпляре реально гораздо выгоднее докупить ещё 100 гигов памяти, 500 SSD и 100500-ядерный процессор, чем тратить месяц на оптимизацию.
Команда из 10 человек сжирает в месяц около 50-70 килобаксов.
Зарплата - верхушка айсберга, потому что налоги, потому что аренда офиса, потому что на 10 человек ещё требуется обслуга бухгалтер-уборщица-управленец (да-да, управленцы тоже нужны). На 70 килобаксов можно уже поставить кластер, и утыкать его памятью сверху донизу.
...
Собссно, такой подход (пока) не работает только в очень серийном встроенном софте, где тиражи устройства должны исчисляться хотя бы тысячами или - лучше - миллионами экземпляров, и каждый бакс в процессор отзывается тысячами-миллионами в серии.
Но и то: в мелких сериях уже проще воткнуть камень подороже-побыстрее, чем мучаться с вылизыванием (если это, конечно, именно вылизывание, а не замена алгоритмически или концептуально откровенно страшного говнокода).
И девы превращаются... в девопсов! :)
И да, разработка - малая доля, поддержка и внедрение - наше всё. Если разрабатывать до посинения каждый модуль (как положено, по правилам), то клиент устанет ждать и возьмёт готовое. Похуже, помедленнее, но готовое и не у вас.
Так что говнокод - наше всё. И увы, даже в embedded.
Есть классная книга где подробно описано почему это происходит и как этого избежать. Прочитал и не один раз . Многое спорно, но показывает сложность проблем.
Фредерик Ф.Брукс
Мифический человеко-месяц или как создаются программные системы
https://eusi.ru/lib/brooks_mificeskij/index.php
И её по уму надо преподавать в ВУЗах как пособие по созданию сложных программных продуктов.
Верно. Приятно встретить ценителя!
В серьёзных ВУЗах её преподают. Это уже классика. Проблема в манагерах, которые по тупости не понимают, для чего нужны дорогостоящие специалисты(особенно архитектор) и как их правильно применять.
В мое время к сожалению это не преподавали. Хотя это впрямую мой профиль :(.
Нам в университете эту книгу крайне рекомендовали к прочтению. Правда, зачёта по ней не было :)
Статья забавная.
Несогласен со следующим:
Автор не в курсе, что код принято разбивать на функции и процедуры, что упрощает отладку и модернизацию? Автор не в курсе, что допустимо использовать библиотеки, которые можно подгрузить-выгрузить в процессе работы и/или модернизации? Автор не в курсе, что можно написать внутри самой программы собственный фреймворк с очень удобными функциями?(А-что? Приходилось и так извращаться!)
Автор явно сам не программист ни разу или не работал с большими проектами, где программистов сотни, вот там без общей концепции написания кода и единых для всех правил взаимодействия элементов и обязательного подробного документирования частей проекта - получите полный сатан, который невозможно ни отладить, ни исправить, ни вообще разобраться!
Автор статьи может и знал, как надо делать. Но когда на 20 разработчиков приходится 35 менеджеров, когда сами разработчики постоянно смотрят в книжку "С++ для новичков" и когда любое исправление кода требует подачи заявки за 1 неделю, сделать ничего толкового нельзя. Только если разогнать всех и нанять 2-3 толковых специалистов, которое напишут код заново.
Всё вами написанное предполагает, что в проекте есть ведущий разработчик и архитектор, которые(-ый) следят за целостностью проекта, представляют, как и что между собой должно взаимодействовать (определяют протоколы и интерфейсы) и директивно предписывают использование единого фреймворка для реализации базовых функций. Все расширения и изменения базового фреймворка строго контролируются или вообще блокируются. Кроме того, в идеале любой добавляемый модуль и функция должны быть снабжены тестами, подтверждающими их работоспособность и бессбойность в рамках поставленной задачи и "сопрягаемость с окружением" в рамках предложенных интерфейсов и протоколов.
Так вот, это идеальный и редкий случай. На практике зачастую приходится работать с кучей легаси, без архитектора, с без описания интерфейсов (код сам себя документирует! ага), без понимания, что уже написано другими командами, и т.п. и т.д.
тут выгораживать программеров ни к чему.
и так ясно что надо было выкинуть все написанное на второй год и переписать с нуля. только оказалось некому.
Я программеров не выгораживаю - управленцы оказались ДЕРЬМОМ.
Подумалось, что есть в этом что-то французское. Их фирма AREVA просрочила ввод АЭС в Финляндии на 10 лет...
И
Я как-то пользовался ПО Аревы. "Транснефть" заказала на ее программном пакете и контроллерах АСКУЭ АСТУЭ энергохозяйства. Это просто был треш и угар. ПО было написано на яве. Сразу стало понятно почему символ явы чашка кофе, за время изменения пары надписей на мнемосхеме верхнего уровня АСУ, можно выпить не одну чашку... Но архитектура и инструментарий взаимосвязи верхнего и среднего уровня были каким то верхом извращенства в "лучших" традициях французских инженеров. Не менее доставляло железо контроллеров. Которое отдавало концом 90ых, с электролитными конденсаторами приличных размеров, россыпью микросборок и обычных транзисторов на желто-зеленом 3 мм двухслойном текстолите, который крепился саморезами. Всё это добро изготавливалось где то в Бразилии на закрывающейся линейке без возможности последующего сопровождения.
У френчей это было и раньше - например, история эксплуатации и ремонтов подводного линкора «Сюркуф».
Какое-то днище. Нормальная информационная система процентов на 70-80 состоит из БД. Остальное интерфейс, пользовательский или служебный (вебинтерфейсы и пр.) Причем, на чем написан пользовательский интерфес - пофигу, ибо там минимум логики.
И таки да - системы с декларативным описанием интерфейс появились примерно в то-же время.
Не где не сказано что это информационная система.
Скорее всего это она и была. Судя по тому, что там была загрузка данных с CD. Возможно это было ПО для обычной обработки данных.
Там явно упоминалась и некая СУБД и множество пользователей.
Впрочем, это американский(или европейский) стайл - загонять логику в интерфейс, отчего он становится дико сложным и глючным.
Практически в любой системе используется СУБД и много пользователей. Но это не делает их информационной системой. Системы картографии или сапр к примеру используют базы данных, но при этом основную работу выполняет клиент который из данных предоставляемые СУБД делает конкретный продукт карту чертёж, схему, набор команд управления и прочие. Это всё гадание на кофейной гуще.
Набор команд формируется в СУБД и вебъинтерфейсом идет на оборудование. Нафига клиент? Собственно у нормального сотового оператора это просто одна из подсистем, где в БД хранятся данные по наборам команд для конкретного типа оборудования, которые сопоставляются с набором других справочников. И все изменения логики или появление нового оборудования сводятся к работе со справочниками в БД. Никакого кодинга, адских компиляций и т.д.
Интерфейс (его описание) также хранится в СУБД и строится на клиенте.
С САПРОМ и ГИСами таки да несколько сложнее, но не намного.
Собственно принцип везде один - все хранится в декларативном виде в БД, а на интерфейсе оно только собирается в законченный вид.
В вашем конкретном случае да. Но бывает совсем не так. И программа обработки данных может быть очень сложно и многофункциональна. Какой нибудь специализированный софт типа геофизического seisworks или какой нибудь другой. Да там база данных ORACLE и он многопользовательский. Но обработка данных идет по очень сложным моделям.
На мой взгляд вы пытаетесь всё многообразие программных систем свести к информационной системе. Что не совсем корректно.
Это junior style. Национальность неважна.
Не только :). Ещё это защита от кражи базы данных или перехода на другой продукт с конвертацией данных. Сама база толпа не чем не связанных между собой таблиц. Вот и ломаешь голову какая с чем связанна. И вроде все сделал правильно но 1 % данных потерялись.
Угу, "безопасность через неясность" (security through obscurity).
Но бритва Оккама говорит, что обычно все проще - неопытность / некомпетентность.
Есть один момент. Очень любопытный. Про аванс. Году в 2008 и у нас так было. Когда систему только вводили с госзакупками. Когда только загоняли в систему всех, то можно было авансы получить. На 100 процентов за всех не поручусь, но когда всех загнали, то строго пост-оплата. И появились банки, которые под госконтракты дают авансы в кредит. Но в торгах на понижение ставки не участвуют, как исполнители контрактов участвуют в торгах на понижение дохода и прибыли. По мне, так вся система и была сделана ради того, что бы в максимальном кол-ве госзакупок, без доли ростовщикам не обошлось бы. Все для того, что бы им на Ибице не беднелось. Но это мое неправильное и абстрактное мнение. Просто любопытно, как сейчас во Франции. Так же дают авансы напрямую, не финансируя ростовщиков за госчет или тоже перестали давать? Берите кредиты. Гарантия по нему госконтракт.
Ага, я "начал что-то подозревать" уже на этом моменте. Государственный аванс - это самое сладкое для менеджера-распильщика. Аванс-то ведь берётся на компанию, а пилится он менеджерами... Потом увольнение и поиск другого сладкого места.
Спасибо, повеселили. Такого количества фейлов в одном проекте - поискать. особенно умилила процедура работы с системой контроля версий.
С программным обеспечением F-35 тоже весело всё.
Что-то у меня в голове описанное вообще не укладывается. Это ж полный финиш. Не представляю, как до такого можно дойти. Прям аж не верю вот.
Эта ситуация скорее исключение, чем правило. Просто в ней наложилось одно на другое, поэтому она и выглядит так ужасно. В проектах случаются перекосы даже сейчас, но схема разработки ПО уже хорошо отработана, есть хорошие IDE, CVS и фреймворки.
Перспективный чат детектед! Сим повелеваю - внести запись в реестр самых обсуждаемых за последние 4 часа.
К сожалению, можно. Когда наша команда начинала в конце 90-х, в России просто нигде не учили как правильно разрабатывать программный продукт (именно это: системы контроля версий, система сборки, тестирование и т.д.). Сейчас уже учат. Так что все стадии эволюции и связанных проблем видел собственными глазами. Притом что у нас ни разу не распил. А если ещё и распиловочная контора, то всё - туши свет.
Думаю, что такое было не только в России, но и везде. Это сейчас есть куча техник и инструментов для разработки ПО, а тогда никто толком не понимал как делать правильно.
Если в команде были опытные программисты, то был высокий шанс получить хороший продукт быстро. А если приходилось учиться на своем опыте, то проходили по всем известным и неизвестным граблям.
Это сейчас есть Интернет и куча тематических порталов, а тогда было непросто.
правильно - это когда работает, а все эти ваши ООП, джавы, аджайлы, девопсы от лукавого и их основная цель минимизировать риски от того, что толпа низкосортных кодеров лабает по ТЗ, слабо понимая что это и зачем
Именно с таким мировоззрением получается код, который (в лучшем случае) понимает только его автор и никто больше.
Сложно конечно себе представить настолько запущенную ситуацию. Менеджмент конечно там был абсолютно деревянным.
А мне и статья понравилась и ситуация там..... Просто праздник какой то )))) побольше бы таких проектов и руководителей для Франции))
Это просто пипец. Я думал у нас тут жопа, а все познается в сравнении. Нафик надо из таких контор бежать. Даже если ты джуниор, максимум через пол года.
Спасение утопающих дело рук самих утопающих, как известно. Франция сама выкрутится.
Давайте о себе подумаем. Например не надо выдавать диплом о среднем образовании тем, кто совсем ничего не понимает, дебилам. Надо проанализировать как такие менеджеры получили диплом. Не имея уважения к людям работающим, не понимая специфики.
Обычно они умеют сделать select * from table. И считают трудоемкость всего остального ПО аналогичной. Наши манагеры считают, что все можно купить за границей.
Небольшая зарисовка о французском IT из опыта фриланса:
Сдав пару крупных заказов и решив финансовые проблемы на пару ближайших месяцев я отправился на сайты фриланса посмотреть на чем еще можно подзаработать копейку-другую. На удивление на всех площадках по моему профилю нашелся только один заказ на $7. По описанию там было что-то мелкое минут на 5 работы. Поотлынивав пару часов, периодически нажимая F5, я понял что другой работы не предвидится и нажал так кнопку принять заказ. Мгновенно открылось окно чата и заказчик на английском с легким привкусом гуглтранслейта начал мне любить мозг. Он задал кучу вопросов по моим знаниям, выразил раз сто сомнения в моей квалификации, признался что уже не один контрактор пал смертью храбрых на этом заказе. Эта эпическая беседа длилась больше часа. Причиной моего терпения было только то, что мне решительно нечем было больше заняться. В итоге он предоставил доступ к их системе. Признаюсь честно - я очень неверно оценил затраты времени, наверное первый и последний раз в своей карьере. На решение проблемы мы потребовалось меньше минуты. Еще минута ушла на написание резюме по проблеме и закрытие задачи. Дальше началась феерия: француз строчил вопросы со скоростью, что не всегда успевал исправить косяки переводчика и текст состоял из смеси французских и английских слов. Мои объяснения он или не понимал, или просто не мог в них поверить, поэтому через полчаса мне на скайп позвонил их русскоговорящий сотрудник, которому я смогу объяснить одну простую вещь: при установке системы в автозагрузку не был добавлен один сервис и всё это работало пару лет, пока по какой-то причине сервер не перезапустили. К чести французов они заплатили сразу, как только убедились что все работает не только $7, но и максимально допустимую сервисом премию в 200%. А после разговора с русским француз опять связался со мной и отдельно заплатил $50 "мимо кассы". И это была не слишком маленькая программистская контора, десятка три программистов и пара сисадминов.
Достойным человеков этот француз оказался. Не из-за того, что премия оказалась в разы выше основной оплаты, а из-за того, что захотел ее выплатить.
А вы представьте, что они трахались с этой непонятной ситуацией пару месяцев уже :) У них там истерика пополам с оргазмом должна была приключиться от решения проблемы.
В середине конце 90-х кроме С++ ничего и не было для крупных проектов.
Впрочем, зависит от платформы, на VMS были DEC Works, DEC Rally и прочие интересные штуки...
Delphi? Но если вспомнить, что в рассказе Франция, т.е. должна быть лицензия, чтобы проверяющие не любили мозг, то тогда появляется вопрос цены, а у Delphi цена немаленькая. Остальные языки стали появляться и развиваться намного позже.
Ладно, тут мой косяк - Delphi не умеет в другие ОС кроме Windows, а выпущена в 1995 году (первая версия под Windows 3.1).
Это сейчас беру Lazarus/Free Pascal и клепаю на любую систему (кроссплатформенность) на паскале, не пытаясь ломать мозг об i++ + i++ и их аналоги. И бесплатно! Либо для Unix использую Python.
Тогда винда была на коне, а линукс только только набирал популярность. Так что Дельфи отлично бы подошел.
Кстати да.
Может там мейнфреймы какие были центральные... впрочем, какая разница, условно серверный кусок могли на плюсах наговнокодить, а клиентский на дельфи.
Питон совершенно кроссплатформенный.
Страницы