The word plastic: https://www.thesaurus.com/browse/plastic

The main USP for MDriven is the ability to stay plastic no matter how complex or large the definition of your system-space is.

MDriven is frequently compared to other low/no-code tools, but even if MDriven is equally as fast as those in taking you from Nothing to Something, MDriven is unique in the way you can change the Something you have, and how you can easily add more to your current Something without causing instability to the result.

If you are only going one iteration – from Nothing to Something, you may not need something very plastic.

If you, however, will be going through multiple iterations – possibly many years of iterations – probably expecting tech shifts (Modernity shifts) during the lifetime – then you want something plastic like MDriven.

There is also a subtle difference in the aim of a development iteration: is it for adding something on top of what you have – or is it for changing what you had before to something better suited to your requirements? The latter of these two requires higher plasticity than the first – and in both scenarios, you will be satisfied with MDriven.

What creates plasticity?

To get high plasticity in an environment, we need transparency of what we have – it is inadvisable to change things you don’t fully understand.

This is where traditional coding, and even most low-code tools, are at a disadvantage – it is hard and time-consuming to read code – and the understanding of code read-only exists in the head of the individual who did the reading.

As MDriven keeps your system definition in a clear standardized model with declarative transformations, you get both the benefit of easily understanding what you have and a clear path to adding the new requirements expressed in the language of the business.

When you do not need plasticity anymore…

Maybe your many iterations, in the end, reach the nirvana of your target business. When this happens, you will not need to change the system again – at least not until your target business changes.

This is the definite north star of all development – to finish up – to reach all goals.

In our experience, this never happens – but if it does – what good is the plasticity then? Not much. Transparency is, however, still relevant – because long after the last system update – users and integrators will ask about definitions and the system’s inner workings. MDriven really shines in transparency – it is an effect of its declarative nature.

Changing from MDriven to Traditional Code

The main reason traditional coding is slow is because the specification is in flux – and as it changes, developers need to go back into low-plastic code and make costly changes.

If you have a perfect working system in MDriven, you also have a perfect specification of that system (in MDriven, the specification is the system).

A perfect specification enables you to get a perfect cost estimation of the implementation with traditional coding. This way, use MDriven to drive the knowledge process of your business requirements and be very plastic during this phase; once you feel you have been plastic enough, you can harvest all your knowledge in a controlled implementation into a less plastic future.

…We recommend you Stay Plastic

Even if you occasionally experience nirvana where you see no new requirements – and no changes to existing requirements – likely, external factors like a change in regulations, laws, partners, or new ideas may immediately pull you out of this nirvana state. You may need to change or add things to support your business best. When this occurs, you will not regret staying plastic even when you do not need it.