Moneyfall taming and other lost secrets of ancient ages
Люди - основной компонент любого интеллектуального производства. А финансы - направляющая сила их действий. Можно вспомнить жажду славы, революционный нигилизм или манию осчастливить человечество, но финансы всегда побеждают.
Именно поэтому надо вскрывать реальные цели и искать истинные причины проблем. Там где «чисто технический анализ» выдаёт какой-то бред, вскрытие личных целей показывает, что фирма А ввела процесс Х потому, что вот этому конкретному остолопу захотелось получить красивую строчку в резюме и перейти из разработчиков в аналитики, а фирма Б накупила на всех тула Y не потому, что он вписывается в процессы, а потому, что картинки в рекламных брошюрках у них клёвые и в отделе продаж очень милые люди. (Никто не говорит, что выявлять истинные причины просто.)
Почему софторазработку так дико перекосило в последнее время? Потому что «делать» стало дешевле чем «думать». Если в древние времена сложное серверное приложение сначала раскладывалось на бумаге, и умные люди аккуратно просчитывали последствие технических решений, то сейчас набирают офшорных индусов, ставят над ними вчерашних студентов и лепят из фреймворков что-то вроде целевой системы. А так, как ни времени подумать, ни умения этого делать у назначенных аналитиками недоучек нет, начинаются разговоры о том, что пользователи не знают, что им нужно, а требования меняются каждую неделю.
Кстати, процесс думания - не только самый дорогой, но и самый неприятный. Потому все любят делать модульные тесты, которые просто поют код разработчика на другой лад, вместо сложных функциональных, которые проверяют поведение системы. Кстати, это не только требует меньше ментальных усилий, но и генерирует огромный массив работы при внесении изменений. Менеджеры тоже в деле.
Естественно, разработчику не надо думать о том, могут ли быть в коде ошибки. Забота об этом переносится на тесты. (Особенно хорошо видна экономика, если тесты делает другой отдел или, ещё лучше, заказчик.)
Если найти и нанять дорогих аналитиков, можно закладывать фундамент, ставить несущие конструкции и аккуратно выкладывать стены, не забывая про сантехнику и прочее. (И я видел фирмы, где это на самом деле работает.) Но, как учит Паркинсон, менеджерам выгоднее отчитывать об экономии на штучных расходах и повышать поголовье подчинённых. В результате, поднимаются обои, к ним подкладываются кирпичные стены, а потом ломом пробивается окно. (Которое потом частично замуровывается, потому что рядом дверь и по стене пошли трещины.)
Ниже добавление экономического разбора к тому, что здесь уже было про Model Driven Architecture. Мне лень переводить на русский, просто переставил цитаты из другого места. Писалось ночью, так что английский брать в пример не надо.
Engineers divide the complex world into simple manageable problems and solve them. Humanity scholars make complex descriptive theories that cannot be proved or rejected by experiments.
Of course OMG has not failed. We must not mistake advertized desires for real goals. If you investigate OMG and its work, you can find out that it exists not to make users happy but to make life easier for tool vendors.
Например, можно было сделать диаграммы удобными для пользователей, введя разные геометрические фигуры, разные типы стрелок, разные типы линий, разные цвета. Но это нетривиальная задача для создателей стандарта, потому что пришлось бы учитывать цветовую слепоту, особенности различных культур и достижения психологии. Если к стандартным прямоугольникам просто добавлять строчку текста, запрограммировать это элементарно, а думать совсем не надо. (Особенно, если текст спрятать где-то во внутренних формах и на диаграмме не показывать.)
Before UML introduction there were a lot of different tools that supported incompatible DSLs and incompatible processes. The direction of UML "evolution" was the creation of "common" abstract levels and interchange formats. Current UML and its successor SysML are pure scholasticism not compatible with real business needs. But the needs of tool vendors, consultants and certification authorities are fulfilled in the fullest.
Представьте себе, сколько можно было бы заработать на обучении, если бы диаграммы и слова объяснения были бы на самом деле без подготовки понятны экспертам в предметной области и, даже, менеджерам. А так, есть сертификат для базового уровня, есть для продвинутого, есть для разработчиков, есть для аналитиков... И можно по каждому тулу ввести обучение, потому что они все тоже ужасно кривые и неудобные.
Чтобы источник не иссяк, в стандарты по качеству вписывается обязательное наличие всей диаграммной бюрократии. (Понятно, что большинство совсем не генерирует код из моделей, а перед проверкой или после сдачи проекта приводит прямоугольнички и стрелочки в состояние более-менее напоминающее получившееся в результате хаотических изменений и доработок.)
Также не забываем про уничтожение критериев качества в целях снятия ответственности за конечный результат. Аналитикам и дизайнерам не хочется отвечать за то, насколько их прожекты реализуемы, разработчикам не хочется показывать ошибки, влезшие при переписывании с диаграмм в код, а менеджерам не хочется отвечать вообще ни за что.
Потому никто никогда не будет искать способов отличить хорошую аналитическую модель от дерьмовой. Никто не будет разбираться, что нужно, чтобы диаграммы легко читались пользователем, а не запутывали его и не вызывали ошибки понимания. Тем более, никому не интересно, чтобы мудрёный язык понимали бизнесмены, биологи и бухгалтера. Это было бы полезно для «улучшения мира», но направлено против экономических сил.
Now the new generation of IT professionals moves to functional programming because they cannot imagine that object oriented technologies and MDA may be simple, effective and appropriate for concurrent environment.
Именно поэтому надо вскрывать реальные цели и искать истинные причины проблем. Там где «чисто технический анализ» выдаёт какой-то бред, вскрытие личных целей показывает, что фирма А ввела процесс Х потому, что вот этому конкретному остолопу захотелось получить красивую строчку в резюме и перейти из разработчиков в аналитики, а фирма Б накупила на всех тула Y не потому, что он вписывается в процессы, а потому, что картинки в рекламных брошюрках у них клёвые и в отделе продаж очень милые люди. (Никто не говорит, что выявлять истинные причины просто.)
Почему софторазработку так дико перекосило в последнее время? Потому что «делать» стало дешевле чем «думать». Если в древние времена сложное серверное приложение сначала раскладывалось на бумаге, и умные люди аккуратно просчитывали последствие технических решений, то сейчас набирают офшорных индусов, ставят над ними вчерашних студентов и лепят из фреймворков что-то вроде целевой системы. А так, как ни времени подумать, ни умения этого делать у назначенных аналитиками недоучек нет, начинаются разговоры о том, что пользователи не знают, что им нужно, а требования меняются каждую неделю.
Кстати, процесс думания - не только самый дорогой, но и самый неприятный. Потому все любят делать модульные тесты, которые просто поют код разработчика на другой лад, вместо сложных функциональных, которые проверяют поведение системы. Кстати, это не только требует меньше ментальных усилий, но и генерирует огромный массив работы при внесении изменений. Менеджеры тоже в деле.
Естественно, разработчику не надо думать о том, могут ли быть в коде ошибки. Забота об этом переносится на тесты. (Особенно хорошо видна экономика, если тесты делает другой отдел или, ещё лучше, заказчик.)
Если найти и нанять дорогих аналитиков, можно закладывать фундамент, ставить несущие конструкции и аккуратно выкладывать стены, не забывая про сантехнику и прочее. (И я видел фирмы, где это на самом деле работает.) Но, как учит Паркинсон, менеджерам выгоднее отчитывать об экономии на штучных расходах и повышать поголовье подчинённых. В результате, поднимаются обои, к ним подкладываются кирпичные стены, а потом ломом пробивается окно. (Которое потом частично замуровывается, потому что рядом дверь и по стене пошли трещины.)
Ниже добавление экономического разбора к тому, что здесь уже было про Model Driven Architecture. Мне лень переводить на русский, просто переставил цитаты из другого места. Писалось ночью, так что английский брать в пример не надо.
Engineers divide the complex world into simple manageable problems and solve them. Humanity scholars make complex descriptive theories that cannot be proved or rejected by experiments.
Of course OMG has not failed. We must not mistake advertized desires for real goals. If you investigate OMG and its work, you can find out that it exists not to make users happy but to make life easier for tool vendors.
Например, можно было сделать диаграммы удобными для пользователей, введя разные геометрические фигуры, разные типы стрелок, разные типы линий, разные цвета. Но это нетривиальная задача для создателей стандарта, потому что пришлось бы учитывать цветовую слепоту, особенности различных культур и достижения психологии. Если к стандартным прямоугольникам просто добавлять строчку текста, запрограммировать это элементарно, а думать совсем не надо. (Особенно, если текст спрятать где-то во внутренних формах и на диаграмме не показывать.)
Before UML introduction there were a lot of different tools that supported incompatible DSLs and incompatible processes. The direction of UML "evolution" was the creation of "common" abstract levels and interchange formats. Current UML and its successor SysML are pure scholasticism not compatible with real business needs. But the needs of tool vendors, consultants and certification authorities are fulfilled in the fullest.
Представьте себе, сколько можно было бы заработать на обучении, если бы диаграммы и слова объяснения были бы на самом деле без подготовки понятны экспертам в предметной области и, даже, менеджерам. А так, есть сертификат для базового уровня, есть для продвинутого, есть для разработчиков, есть для аналитиков... И можно по каждому тулу ввести обучение, потому что они все тоже ужасно кривые и неудобные.
Чтобы источник не иссяк, в стандарты по качеству вписывается обязательное наличие всей диаграммной бюрократии. (Понятно, что большинство совсем не генерирует код из моделей, а перед проверкой или после сдачи проекта приводит прямоугольнички и стрелочки в состояние более-менее напоминающее получившееся в результате хаотических изменений и доработок.)
Также не забываем про уничтожение критериев качества в целях снятия ответственности за конечный результат. Аналитикам и дизайнерам не хочется отвечать за то, насколько их прожекты реализуемы, разработчикам не хочется показывать ошибки, влезшие при переписывании с диаграмм в код, а менеджерам не хочется отвечать вообще ни за что.
Потому никто никогда не будет искать способов отличить хорошую аналитическую модель от дерьмовой. Никто не будет разбираться, что нужно, чтобы диаграммы легко читались пользователем, а не запутывали его и не вызывали ошибки понимания. Тем более, никому не интересно, чтобы мудрёный язык понимали бизнесмены, биологи и бухгалтера. Это было бы полезно для «улучшения мира», но направлено против экономических сил.
Now the new generation of IT professionals moves to functional programming because they cannot imagine that object oriented technologies and MDA may be simple, effective and appropriate for concurrent environment.