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

Студенты

В Рашеньке очень часто на проект хотят взять ходячую энциклопедию. Алгоритмы все помнит, Си с решёточкой знает и «о малое» умеет и даже по большому может. Да чтобы одной рукой с потоками работал, а другой одновременно вебсервисы писал на WCF да левой ногой секретарше кунилингус делал.

В довесок хотят, чтобы кандидат профессионально умел по теории архитектуры и знал все базы данных от MySQL до PL SQL и писал бы трёхэтажные запросы с закрытыми глазами.

Ну, кто же это всё кроме студента умеет? Да никто! Вот и берут студента.

Садят парня создавать проект какой-нибудь автоматизации бизнеса.

Тут и даёт наш студент волю своим шалавливым ручёнкам — и то заюзает и это. Ведь в конце года диплом надо сдавать и если уместить в новом проекте все известные, а лучше неизвестные, передовые технологии и архитектурные приёмы, то преподаватели восхитятся, слава Фаулеру, и поставят пять.

В итоге получается убожество, этакий франкенштейн — здесь и веб сервисы, и Remoting, кое-где на силу пришитый threading. Паттерн на паттерне и паттерном погоняет.

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

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

Расширяемость сей поделки стремиться к нулю. Никакой тебе scalability, extensibility и usability. А это корень авралов. «Универсальная» архитектура перегружена и неподъёмна.

Но клиент этого понимать не желает — для него это просто приложение, например, для сводных отчётов и каких-то рассчётов.

Для программиста это безумное количество классов с чудоковатым наследованием и гремучей смесью технологий — по-простому делать не хочется, гордость не позволяет, а вписывать что-то новое в уже существующую мракобесную горе-архитектуру для команды целое испытытание и дикие муки, включая автора (если он ещё не уволился)!

«Надо бы задержаться, не успеваем», — говорит босс. Так а где же тут успеешь!

Так и гниёт проект мало по-малу.

Индусы

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

Пока работает.

Ибо расширяемость и масштабируемость нулевая.

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

Результат в итоге один, что после «индусов», что после «студентов» — нерасширяемое и неподдерживаемое месиво.

Нормальные адекватные люди, просто компетентные люди

Таких стараются на собеседованиях отсеивать. Бо Спольски приказал. Хочется либо звёзд, знающих всё, либо дёшево. Поэтому выбирают либо студентов либо индусов.

И в заключение пример.

Заказчик: Хочу штуку, забивающую гвозди на 50 мм.

Индусы: Гут. Через неделю готов молоток, забивающий гвозди только на 50 мм. При этом гвозди на 60 мм забивает с трудом, а гвозди на 70 мм и более без серьёзных доработок не способен забить в принципе.

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