vit_r (vit_r) wrote,
vit_r
vit_r

Moneyfall taming and other lost secrets of ancient ages

В беседе с проповедниками моделирования мне было заявлено, что модели клиентам показывать не надо. Нагенерим софта - пусть тыкают в кнопочки и восхищаются.

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

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

(Зрелище забавное и поучителное, если ты - третья сторона. Хреново, когда этот мудрый архитектор твой начальник.)

А всего-то надо было нарисовать пару картинок и перевести тарабарские определения на нормальный человеческий язык.

Ниже небольшая цитата из черновиков про то, почему чудесное MDA работает плохо, а часто ещё и пожирает ресурсы, вместо того, чтобы их экономить.

(Попытки использовать английский превышают мои познания. Плюс накладывается ограничение на количество букв в одном комментарии. Но, думаю, идея понятна.)

The problem of modern tools is the broken top-down level separation.

Let's say I introduce an Order_ID in my model. I only know that this is something unique. After that I discuss my draft model and its interfaces to other systems with different stakeholders.

We find out that SAP system stores IDs as alphanumerical strings, but they are not unique for the whole company. The existing shipping software uses own format with incompatible IDs and adds one or more IDs for delivery. A lawyer says that we are not permitted to save IDs in the way that allows to trace them back to customer ids. Marketing department disagrees and in the conclusion we add a special high secure table for back references.

After that I go to DBAs and discuss technical constrains. char(10) takes too much space. decimal(10) is not efficient. int is too small. unsigned is not good because it is better to use negative values instead of null...

The model grows, morphs, changes and adapts to the environment.

Theoretically this Order_ID must be only drafted at the beginning and will be defined more and more precise by model clarification. This is the way how it works by architects, designers, engineers, painters, writers and in other "old industries".

What do I see in most modern tools when I try to add Order_ID into my first model version?

"Error! Please select a type:
short
int
float
double
string
...
"

The decision will affect not only the software but also the requirements gathering process and future design decisions. If I have divine power of being always right, we save time of doubts and discussions. If my divine prediction turns to be wrong, only for this Order_ID many man months may be invested into the adaptation of my genial design to the defective world.
Tags: business_tales, en, it, marketing, psychology, qa, quality, ru, se
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 8 comments