How MDriven Is More Efficient Than Other System Development Tools

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.

Imagine walking into a restaurant and asking for a table. You expect a waiter to show you to a table and eventually serve a meal. You expect this because you assume you know the rules the place aims to follow.

System developers who don’t use MDriven can rarely assume they know all the rules — or that they can follow the known rules. 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: you can never fully know the possible real-case deviations unless you fully define the rules of the world you are acting in. Is the kitchen offline? Are 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-solving.

As the idea of “on-the-spot-problem-fixing” is brought into system development and coding, the number of if-and-but checks in your code explodes. 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 we should salvage things in code that are undefined in the rules. MDriven uses 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. Moving the black sand first 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 that it is dry. You can request access if the door is locked… 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. Knowing the world rules fully enables you to do this.

Unpacking the Declarative Solution

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 a 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 the preferred order of 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 absolutely known environment.

A Possible Objection

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 in.

MDriven —Embrace the Standards and Create Real Value

MDriven makes use of the standard UML to define static information rules (classes, attributes, associations) and dynamic information rules (state-machines). It also uses the OCL standard to further define constraints beyond what you can define with associations and types.

As MDriven uses the functional OCL language code volume (instructions) shrinks dramatically:

• It promotes declarative thinking.
• It shifts important insights into the model (world rules) instead of code.
• It removes all the non-world-defined degrees of freedom. Developers become more focused on the documented rules that, in turn, bring real business insights to your attention.

With MDriven, you not only have a tool to solve your immediate information needs. You have 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 the aging modernity of today. But that is another story.