The word plastic: https://www.thesaurus.com/browse/plastic
The main USP (unique selling point) for MDriven is its ability to stay plastic (adaptable) no matter how complex or large the definition of your system/space is.
MDriven is frequently compared to other low/no-code tools. Still, even if MDriven is as fast as they are in taking you from Nothing to Something, MDriven is unique. You can change the Something you have, and easily add more to your current Something without causing or resulting in instability.
If you are only going one iteration – from Nothing to Something, you may not need something very plastic.
Suppose you, however, will be going through multiple iterations – possibly many years of iterations – and are probably expecting some tech shifts (Modernity shifts) during your lifetime. In that case, you need something plastic like MDriven.
There is also a subtle difference in the aim of a development iteration. Will you be adding something on top of what you have? Or, will you change 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(flexibility)?
To achieve 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 understanding the read code 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 an ideal 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 malleable 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.
