Creating stuff is hard. Creating stuff that “works” is really hard. I always tell my kids that the difference between an artist that does 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” means that which is accepted and liked by users – it follows logical rules that make sense to the business – and 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 micro service that we at a later date integrate in order 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 getting around the fact the we need to produce something first and decide with precision if it works later – and this forces us to work on speculation and assumption that we do the correct thing.
Our vision is to provide the go-to tool for creation of software that works
In order to deliver on our vision we have reached the conclusion that we must provide a tool that allows you to provide a finished software system that real users can do real things with – so that you quickly, with low investment and minimal risk, can get the user feedback.
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 – and then have a machine that does all the work the front and backend developers normally do – but to you it should feel like No-code is needed – and thus no bugs are produced and thus no technical testing is needed – and thus your users can start to give you feedback – if 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
– but with the added benefit that a real system is produced 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 and can through the old stuff out and create something that works better.
The produced system must be enterprise grade and you should be able to keep it forever or through 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 have all colors within reach – easily pipe the fluids anywhere you need them – no limit on 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. If it works? Do you need to build real software for real people? You decide!
This video explains how we look at software – and please check out our elaborated thoughts on the wiki here : https://wiki.mdriven.net/index.php/Fashion_Gist_and_Modernity
