It all comes down to the environment you act in and what you can expect from it. In MDriven you completely control the environment by creating the model. This means that you fully control the rules of the game. If you are fully in control you do not need to safeguard and hedge everything as much as you must if the rules are very loose, changing or unclear.

Walking into a restaurant — asking for a table you expect to be shown a table and eventually served a meal. You expect this because you assume you know the rules the place aim to follow.

System developers not using MDriven can rarely assume that they know all the rules — or that the known rules will be followed. The main reason is that developers are not trying to get just one meal — they are trying to solve all meal-buying-experiences-that-can-possibly-happen-even-if-the-very-unlikely-case-of-“put in your arbitrary real case deviation here”. What is a typical real-case-deviation you may ask? My point is that the possible real-case-deviations can never be fully known unless you fully define the rules of the world you are acting in. Is the kitchen offline? Is there enough cucumbers? Is this really a restaurant?

This is potentially why many companies find system development expensive. They mix up knowledge about what-should-be-allowed-to-happen– i.e. knowledge about the world they are acting in — with on-the-spot-problem-fixing.

As the idea of “on-the-spot-problem-fixing” is brought into system development and coding — the number of ifs-and-buts-checks in your code explodes — and yet it will only be able to handle the small subset of things we can imagine today. Since code is not documentation, at best it is obfuscated documentation, “on-the-spot-problem-fixing” actually hides important knowledge of the world your system is acting in.

The imperative mistake

This is what we define as the “imperative mistake” — believing that we should salvage things in code that are not fully defined in the rules. MDriven use a declarative approach, it does not micro manage acting — instead you define rules of what is possible and opportune.

A mental picture to compare imperative to declarative: Imagine two piles of sand — one with white and one with black sand. The piles need to be moved to another location.

One imperative description of the solution is “get the wheelbarrow from the storage (check that it has enough air in the tire), and the shovel (make sure it is clean and dry), move the white sand first — if you do the black sand first it will leave traces in the white sand you move later on — if you do it the other way around make sure you clean the wheelbarrow — and make sure it is dry. If the door is locked you can request access by asking… If you cannot get access — leave it and try later”.

The same declarative solution is “move the black and white sand — do not mix”.

Reading the example above your reaction may be that I over-simplify or cheat — describing the declarative approach as everything is a done deal. I do not cheat. It is a done deal — that is the whole point of the declarative approach. Skip all the detailed steps — just like walking into a restaurant and requesting a table. What enables you to do this is that the world rules are fully known.

The declarative solution only states intent and assumes that this will be enough — exactly as you would instruct a skilled and intelligent person in a world where all the possible outcomes are known.

The imperative approach resembles how you will instruct person without skills and with no knowledge or experience in the field, in a world where almost anything can happen. You will always be in fear that you have not explained the possible deviations thoroughly enough. Combine this with a team member with Asperger tendencies and you will see your costs skyrocket.

The imperative example has implemented domain knowledge of the fact that black grains are visible in white sand in code (instructions) — not in the documentation of the world it is acting in (the rules).

The declarative example assumes that the world rule-set knows about preferable order or cleaning procedures to move sand. Hence it does not need to hedge or safeguard. It assumes it is dealing with an absolute specialist in the field in an absolute known environment.

One common objection to this explanation is this: “you said: It assumes it is dealing with an absolute specialist in the field. But what if it is not a specialist?”

I love that objection because this goes to the heart of the matter. Let us assume that the declarative world turns out to be really bad at doing the job we ask of it; it mixes the sand. Great find! We have found an issue with the known-world that needs fixing — we solve this problem by evolving the rules of the world — i.e. increasing the knowledge about the world we act in. We amend the rules until the simple instruction of “move the sand” works. This may involve the collecting of additional information into our world — information that must be maintained somehow — maybe by a user — the complexity of our world may increase — but so does the knowledge and hence the instructions within that world can be held simple.

The imperative approach hides important knowledge in code (instructions) — it limits your ability to understand the world you act it.

MDriven — embrace the standards and create real value

MDriven make use of the standard UML to define static information rules (classes, attributes, associations) and dynamic information rules (state-machines). MDriven also use the OCL standard to further define constraints beyond what is defined with associations and types.

As MDriven use the functional OCL language code volume (instructions) shrink dramatically — it promotes declarative thinking — it moves important insight into model (world rules) instead of code — it removes all the non-world-defined-degrees-of-freedom and makes developers much more focused on the documented rules that in turn bring real business insights to your attention.

With MDriven you do not only have a tool to solve your immediate information needs — but a tool to learn, understand, streamline, develop, innovate and grow your business.

That is how MDriven is so much more efficient than other system development tools.

Describing your world declaratively also makes it timeless — not interwoven with aging modernity of today. But that is another story.