Молодые компании как правило не обремены глубоким наследием прошлого в виде Clipper, FOX PRO и DOS, все описанное в статье больше применимо с компаниям старой закалки и гос учереждениям, хотя и там начинаются подвижки.

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

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

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

Насчет платформы. Новые платформы и новые средства разработки позволяют разрабатывать корпоративный софт на порядок быстрее и он будет на порядок надежнее, чем аналогичный софт, разработанный на старых технологиях. Я тоже раньше думал, как вы, что программисту вполне хватит знать хорошо свой любимый инструмент, и можно сделать с его помощью все, что угодно, но потом вот коллеги показали, что это не так. И многие вещи, для разработки которых требовались раньше немыслимые трудозатраты, с новыми технологиями решаются в пару строчек кода. А освободившееся время можно потратить на “социализацию” программы, приспособление ее к человеку и его потребностям, а не к потребностям компьютера. При этом никто не отменяет необходимость знания того, как что работает на нижних уровнях абстракции, но потери времени на разработку несоизмеримые.

Другое дело, что состоявшимся программистам лень изучать новые инструменты и технологии, просто потому что это не принесет им никаких выгод, ведь они уже “состоялись” и теперь им достаточно только сопровождать свой старый софт. При этом у молодежи тоже, конечно, надо на корню пресечь стремление к использованию “новых непроверенных технологий” просто чтобы самим не напрягаться. Вот лучше бы показали молодым, как организовывать процесс разработки, правильно ставить задачу, грамотно делать прототипирование, планирование, тестирование готового продукта и тысячу других вещей, которые нужны для разработки качественного софта. Но проще запретить и упразднить новые инструменты, конечно. Я понаблюдал за этим конфликтом “опытности” и “максимализма” в нескольких ИТ-отделах. Побеждали, конечно, всегда старые-”бывалые” ленивые ИТ-начальники, симбиоза не получалось никогда, а пользователи продолжали плеваться и тратили половину рабочего дня на коррекцию ошибок софта, который достиг пика развития, уперся в свой технологический потолок и способности этого “бывалого”.

PS
Переход по TAB должен происходить так, как это нужно для ввода той или иной формы и он может прыгать совсем не туда, куда указывает дизайнер.

Остановка бизнеса также может произойти, если текучка кадров будет такой, что ни одна новая девочка не сможет оставаться на рабочем месте дольше 2 месяцев. Может, руководству и наплевать на своих людей (люди, между прочим, это чувствуют очень хорошо), но если сложить время+деньги на обучение нового персонала каждые два месяца, то год за годом будет набегать очень внушительная сумма. Еще никто не удосуживается подсчитать эффективность работы с программой и отдачу в денежном эквиваленте.

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

Я даже не говорю о какой-то сверхсложной оптимизации интерфейсов с тщательным юзабилити-тестированием, а об элементарных вещах, которые изучают в университетском курсе технологии программирования UI (например, при нажатии кнопки Tab фокус ввода должен переходить между элементами управления слева направо и сверху вниз, а не наоборот; для каждого состояния системы должен существовать операционный контекст, в котором можно делать определенные действия, но нельзя делать другие и т.п.).

Кто может помешать программистам применить эти элементарные знания, если они у них есть? Может, все упирается в ограничения используемой платформы (DOS+FoxPro против .NET 2.0, набор DBF-файлов против хорошей серверной СУБД и др.)?

Действительно. Администратору и пользователям гораздо проще в этом случае найти другую работу и не напрягаться, настраивая существующее уродское ПО.

Переписать ведь можно с умом, проводя нормальное предпроектное исследование, тестирование, пошаговое внедрение нового с сохранением существующего софта, с совместимостью форматов данных и с возможностью вернуться на старый софт, если новый не удовлетворит. За один день никто организацию на новый АРМ перевести не сможет, конечно. Но попытаться можно, если не мешать программистам, которые хотят что-то изменить, а помочь и направить их.

Не видел еще ни одного ИТ-отдела, где шло бы нормальное эволюционное развитие программных систем. Всегда есть мега-авторитет-начальник, который один раз написал все ПО в организации еще во времена DOS, и он почему-то никогда не заинтересован в улучшении ПО, т.к. “его все полностью удовлетворяет”. Если бы еще остальных сотрудников удовлетворяло. Но ему проще и приятнее обзывать молодых специалистов перфекционистами и подсмеиваться в кулак, ничего не делая и для развлечения ставя им палки в колеса.