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 fast as the those in taking you from Nothing to Something, MDriven is unique in the way you can change the Something you have, and how easily you can 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 multiple iterations – possibly many years of iterations – possible expecting tech-shifts (Modernity-shifts) during the lifetime – then you want something plastic like MDriven.

There is also a subtle difference in what the aim of a development iteration is; 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 require higher plasticity than the first – and in both scenarios you will be satisfied with having chosen MDriven.

What creates plasticity?

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

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

As MDriven keeps your system definition in a clear standardized model with declarative transformations you get both the benefit to easily understand what you have and a clear path to add 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 nirvana of your target business. When this happens you will not need to change the system again – at least not until the your target business change.

This is of course the 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 important – because long after the last system update – users and integrators will ask about definitions and the inner workings of the system. 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).

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

…We recommend you to stay plastic

Even if you from time to time experience nirvana where you see no new requirements – and no changes to existing requirements – it is likely that external factors like a change in regulations, laws, partners or new ideas immediately pull you out of this nirvana state and you need to change or add things in order to support your business best. When this happens you will not regret that you stayed plastic even during the period you did not need it.