MDriven: The No Code Nirvana You Didn’t Know Existed

Introduction

NoCode is often considered an introduction step – something you do before switching to traditional coding. But what if it is the other way around?

What if you need to do something on the run or beyond what you think is feasible with traditional coding? It could be that the information structures are complex. Or, they are so vague at the onset that you intuitively know they will change dramatically during iterations.

Under these circumstances, you will try to get as much understanding and knowledge before code-start as you can. However, just like moving through a foggy room, you also know the only way to discover what is needed is to move forward, to gain ground. This is why the agile iterative approach is how all successful teams work.

The Issues and How to Fix Them

One issue with traditional code is that it is not as easy to change as it is to write it. Insights that come late fold back into work already done and wreak havoc. This results in technical debt and less-than-perfect solutions. To come to terms with this problem, we should explore how to describe the gist of the system in a way that is just as easy to change as it is to create.

If you have not tried the MDriven-NoCode method before, you now have the perfect opportunity.

Anything you can build with code, you can also build with MDriven-NoCode. However, MDriven-NoCode is on a different level of abstraction and uses two different modes of the simple functional language (OCL) to greatly reduce the bulk of metainformation (ie code or model) needed to describe the logic. The two modes of operation are immutable and mutable – i.e. can it change data or not.

What are the Needs

Luckily, we know the generic needs for any and all information systems. Even if all systems are different, on some abstract level, they all share the same needs:

1. The static part of the system: the information structures
2. The dynamic part of the system: in what way is information allowed to change
3. The transformational part of the system: the need to transform information that exists to deliver on use-cases discovered and requested
4. The navigational and interactive part of the system: how to move between use-case implementations and in what way the end user interacts with the system

How Systems are Built

In traditional coding, you use database tables or blobs along with code to address the #1 static part of the system. You then use code to check and enforce #2 the dynamic part of the system – aka business rules.

You then use code again to #3 transform data to match the use-cases requested like: views, reports, rest-calls, rest-apis, etc. Finally, you use more code to tie the use cases together with #4 the navigational part of the system. You also add #4 interactive functions that you fill with code to create new types of information on user requests – i.e. “Add new customer”.

With MDriven-NoCode, the different needs are more distinct than what they are with traditional coding methods – but, of course, they all tie together to build the same end result.

Some of the areas (#1-2 and some of #3-4) do not need mutability. With traditional imperative code, you always have mutability – ie the ability to change data.

But having something you do not need is harmless – one may think. Can we avoid using mutability when we do not need it? Even if it is theoretically harmless, it adds an option for complexity, which increases the ability to go wrong, ie bugs.

Just like driving against traffic is completely safe as long as you don’t hit anything, mutable code is also safe as long you don’t change anything.

The NoCode Alternative

With the MDriven-NoCode method, you will quickly see the benefits that come from everyone staying in their own lane. The information flow is now safer, faster, and easier to understand by just looking at it.

If you are an experienced software architect, you will know that during the lifespan of any system, you will spend a lot of time just looking at its definition to understand how the system behaves. Ensuring that the system is easy to understand and thus predictable is something traditional coders try to implement through the use of common style guides between developers.

Building the system with a higher level of abstraction, like with the MDriven-NoCode-method, where everything has a specific purpose, will work wonders for this readability. In this higher abstraction approach, the different needs #1 to 4 act as a guideline built into the process, rather than being enforced by style cops in hindsight, as with code.

Summation

The true power of the MDriven-NoCode method is that it does not obscure definitions and insights. It lifts your ability to express complexity in normal conversation. It is also equally easy to change as it is to create.

That is it. Having these abilities of holding the definition in a clear, accessible form without alternative interpretations and supporting your ability to articulate existing, changed and new facts is all that it takes to strengthen you and your team’s ability to build, adapt, and change any software system – quickly – for any area of human activity.

With MDriven-NoCode, your ability to handle complexity will grow in orders of magnitude compared to traditional imperative code.

Remember, you can always return to imperative code when you feel the urge to drive against traffic again. We are just pointing out the alternative. An alternative that takes you to where you want to go with less stress, less risk, and more clarity on how you got there.

MDriven-NoCode does not give you anything you do not already have inside your head. It only helps you structure your ideas and understandings into a running and maintainable enterprise-grade software system.

This way, NoCode is not something you merely start with and move on – it is something you will never give up on because you do not give up on great strategies.