Introduction

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

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

Under these circumstances you will of course try and get as much understanding and knowledge prior to code-start as you can – but just as you move through a foggy room you also know that the only way to discover what is needed is to move forward, to gain ground. This is why the agile iterative approach is the way 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 once it is written as it was to write. This means that insights that come late fold back into work already done and wreak havoc – causing technical debt and less than perfect solutions. To come to terms with this problem we should have a way 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 MDriven-NoCode you can also build with code – but MDriven-NoCode is on a different level of abstraction and use two different modes of the simple functional language OCL to greatly reduce the bulk of meta information (ie code or model) needed to describe the logic. The two modes of operation are immutable and mutable – ie 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 in order 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 interact 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 so that it 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 request – ie “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) does not need mutability. With traditional imperative code you always have mutability – ie the ability to change data.

But having something that you do not need is harmless one may think – we can just avoid to use mutability when we do not need it? Even if it is theoretically harmless it adds an option for complexity and complexity adds ability to go wrong, ie bugs.

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

The alternative

With the MDriven-NoCode-method you will quickly see the benefits that comes from everyone staying in their own lane. The information flow is now safer and 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 in order to gain understanding on how the system behaves. Ensuring that the system is easy to understand and thus predictable is something traditional coders try to implement by 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 that is built into the process, rather than being enforced by style cops in hindsight, as it is with code.

Summation

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

That’s it. Having these abilities of holding the definition in a clear, accessible form without alternative interpretations and support 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 – fast – 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 go back 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 to structure your ideas and understandings into a running and maintainable enterprise-grade-software-system.

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