Creating stuff is hard. Creating stuff that “works” is really hard. I always tell my kids that the difference between an artist who makes sculptures and an architect of any trade is that the latter creates things that work.
Creating software is hard. Creating software that works is really, really hard. What “works” refers to what is accepted and liked by users.
- It follows logical rules that make sense to the business
- It has no bugs
People struggle with software all over the globe. Many fail, some give up. Many want to lower the risk in their endeavor to fulfill a software vision.
Some think that lowering the price of coding is the best way to lower risk. Others think that making sure to only code the correct things is the best way to lower the risk. Some think that the problem should be divided into microservices we integrate at a later date to lower risk.
Over the years, we have concluded that NOTHING is as good and effective to decide if something “works” or not as a real user with real data trying to do a real thing. The problem is that to have that real user doing that real thing in a software system, we need to provide a finished system first – before we really know if it will work.
It seems there is no way to get around the fact that we need to produce something first and decide with precision if it works later. And, this forces us to work on the speculation and assumption that we do the correct thing.
The MDriven vision is to provide the go-to tool for the creation of software that works
To deliver on the MDriven vision, we have reached the conclusion that we must provide a tool that allows you to dispense a finished software system that real users can do real things with. You can quickly get user feedback, with low investment and minimal risk.
Basically, what we need to provide is a tool that allows you to describe your system in a drawing format – the gist of the system. Then, you can have a machine that does all the work the front and backend developers normally do. To you, however, it should feel like no code is needed. Thus, no bugs are produced and no technical testing is needed. Your users can start to give you feedback – whether it works for them or not.
What we want to achieve is :
The investment to build something must be so low – just as low as talking about the needs
This is with the added benefit that you produce a real system so that you can verify and learn from your users. If they like it, you can keep everything as is for eternity. If they hate it, you have learned a few things. You can throw the old stuff out and create something that works better.
The produced system must be enterprise-grade. You should be able to keep it forever or throw it out tomorrow with no regrets
Imagine:
You will be able to handle data like water – water with a unique color per information class – never accidentally mixing two colors, but always having all colors within reach. You can easily pipe the fluids anywhere you need them. There is no limit to how much water you can handle. No limit on how you act or create new colors based on your transparent logic. No need to keep a separate description on how the system works since it is self-explanatory with all the information classified into unique pipes.
This is the vision behind the MDriven-tool-chain. Does it work? Do you need to build real software for real people? You decide!
This video explains how we look at software. Please check out our elaborated thoughts on the wiki here: Fashion_Gist_and_Modernity
