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!
We have set up a GoFundMe campaign to see if that is a good way to let the community influence the priority we give to things.
There is no need for us to prioritize things no one will use – so this is a way for us to allow you to chip in a bit and and hope that others can help out to make things happen.
The first one that we have had request for but never got time to deliver upon is to make sure the complete MDriven stack runs on Linux
So why do we need money? Are we broke? Nope – not broke – we are doing well – precisely because we make sure we spend our time on things that people are prepared to pay for. This is just a way to ask for the money upfront to make it easier for us to move it up in priority.
NoCode is often looked upon as an introduction-step – something you do before switching over to traditional coding. But what if it is the other way around?
What if you need to do something that is on the rand or even beyond what you think is feasible with traditional coding? It could be that the information structures are complex, or so vague on the onset that you intuitively know that they will change dramatically during iterations.
Under these circumstances you will of course try and get as much understanding and knowledge prior to code-start as you can – but just as you move through a foggy room you also know that the only way to discover what is needed is to move forward, to gain ground. This is why the agile iterative approach is the way all successful teams work.
The issues and how to fix them
One issue with traditional code is that it is not as easy to change once it is written as it was to write. This means that insights that come late fold back into work already done and wreak havoc – causing technical debt and less than perfect solutions. To come to terms with this problem we should have a way to describe the gist of the system in a way that is just as easy to change as it is to create.
If you have not tried the MDriven-NoCode-method before you now have the perfect opportunity.
Anything you can build with MDriven-NoCode you can also build with code – but MDriven-NoCode is on a different level of abstraction and use two different modes of the simple functional language OCL to greatly reduce the bulk of meta information (ie code or model) needed to describe the logic. The two modes of operation are immutable and mutable – ie can it change data or not.
What are the needs
Luckily, we know the generic needs for any and all information systems, even if all systems are different, on some abstract level they all share the same needs:
The static part of the system; the information structures
The dynamic part of the system; in what way is information allowed to change
The transformational part of the system; the need to transform information that exists in order to deliver on use-cases discovered and requested
The navigational and interactive part of the system; how to move between use-case implementations and in what way the end user interact with the system
How systems are built
In traditional coding you use database tables or blobs along with code to address the #1 static part of the system. You then use code to check and enforce #2 the dynamic part of the system – aka business-rules.
You then use code again to #3 transform data so that it match the use-cases requested; like views, reports, rest-calls, rest-apis etc. Finally you use more code to tie the use cases together with #4 the navigational part of the system. You also add #4 interactive functions that you fill with code to create new types of information on user request – ie “Add new customer”.
With MDriven-NoCode the different needs are more distinct than what they are with traditional coding methods – but of course they all tie together to build the same end result.
Some of the areas (1-2 and some of 3-4) does not need mutability. With traditional imperative code you always have mutability – ie the ability to change data.
But having something that you do not need is harmless one may think – we can just avoid to use mutability when we do not need it? Even if it is theoretically harmless it adds an option for complexity and complexity adds ability to go wrong, ie bugs.
Just like driving against traffic is totally safe as long as you don’t hit anything, mutable code is totally safe as long you don’t change anything.
The alternative
With the MDriven-NoCode-method you will quickly see the benefits that comes from everyone staying in their own lane. The information flow is now safer and faster and easier to understand by just looking at it.
If you are an experienced software architect you will know that during the lifespan of any system you will spend a lot of time just looking at its definition in order to gain understanding on how the system behaves. Ensuring that the system is easy to understand and thus predictable is something traditional coders try to implement by the use of common style guides between developers.
Building the system with a higher level of abstraction, like with the MDriven-NoCode-method, where everything has a specific purpose, will work wonders for this readability. In this higher abstraction approach the different needs 1 to 4 act as a guideline that is built into the process, rather than being enforced by style cops in hindsight, as it is with code.
Summation
The true power of the MDriven-NoCode-method is that it does not obscure definitions and insights, and it lifts your ability to express complexity in normal conversation. It is also equally easy to change as it is to create.
That’s it. Having these abilities of holding the definition in a clear, accessible form without alternative interpretations and support your ability to articulate existing, changed and new facts is all that it takes to strengthen you and your team’s ability to build, adapt and change any software system – fast – for any area of human activity.
With MDriven-NoCode your ability to handle complexity will grow in orders of magnitude compared to traditional imperative code.
Remember you can always go back to imperative code when you feel the urge to drive against traffic again. We are just pointing out the alternative. An alternative that takes you to where you want to go with less stress, less risk and more clarity on how you got there.
MDriven-NoCode does not give you anything you do not already have inside your head – it only helps you to structure your ideas and understandings into a running and maintainable enterprise-grade-software-system.
This way NoCode is not something you merely start with – then move on – it is something that you will never give up on because you do not give up on great strategies.
In this letter you will find our proven strategies to enable your coworkers to continuously sharpen their own information management with custom IT and get motivated and collaborative on their own. Your coworkers will reduce their own stress and they will leave you with a fully documented truth on how they work – without you needing to push for it. You will see how this strategy is future proof – running on the technology valid at any time – now and in the future. We are sure that you will see the benefits of what we have found and the tools we provide to support you to win with your business. With a slim IT-budget and higher coworker satisfaction.
In a world of computational irreducibility, we must move in order to find answers – there often are no shortcuts – you must process all the steps in order to find the results and answers.
In this world we need tools to structure both our findings, history and our latest movements forward – and we need such a tool to be so transcendental to all the implementation details so that it holds the idea (the gist of it) – nothing else. Why? – well, first it is a question of the economics; ideas do not need implementation details to be conveyed and discussed, secondly it is a question of agility – the idea as its own thing can evolve and get improved much faster than any implementation of the idea can.
But ideas can never deliver on their own – they need to be implemented in order to manifest in the world – they need both hard toiled basic function in the reality of today (they need today’s modernity) and they need the sass and flair from the current flow (they need fashion).
A strategy for a world like the one described above should keep ideas as its own thing, separate from Modernity and Fashion. With information technology it is possible to have machines act on the ideas alone, and provide an exact implementation of these ideas manifested in the Modernity current at the time. With this strategy we accept the irreducibility of the ideas creation process but have full automation (reproducibility) of the Modernity.
We suggest that we pull apart the monolith of the current IT-processes that does not separate ideas i.e. the Gist from Modernity and Fashion but instead praise the mixture of them in agile code centric processes. By pulling the Gist, Modernity and Fashion apart to their own processes, we achieve both fluency of thought (the Gist alone) and speed of delivery (automated Modern implementation) and this leaves much more creative space for Fashion.
The above described strategy stems from the findings that has been vetted and tested in real life scenarios with almost magical results during the last ten years of MDriven business focused development.
We offer businesses to revolutionize their ability to build around ideas (the Gist). Ideas that lasts as long as they need and can be changed and replaced as often as needed. Ideas easily communicated internally in a format that can engage everyone in an ongoing discussion on how to win today and tomorrow. Ideas in a structured format is a foundation to build new ideas on top of – but will also allow for faster dismissal of ideas not rooted in practical reality. Ideas that is light as air, but strong as steel. Ideas that becomes the language everyone in the business can talk and improve upon.
We also offer today’s technology brought to life in an instant with the structured ideas you provide it with. This is not “a system” it is “development done instantly” – it takes the structured ideas you have now and instantly acts on your ideas only. The process is literary seconds short. Imagine what effects that may have on the spirit of your workplace – if ideas discussed one day can be fully documented and in the collective memory for the future and have been put in production in the core tools for the business tomorrow. Seeing your ideas come to life triggers the positive thinking that so many businesses want to tap into. We know how to tap into it and make it core to your organization.
Benefits
As a managing director of a business following the MDriven method you will get some clear benefits:
You will have a complete documentation of the current ideas central to your business – you will know that the Gist of the business is not only in the heads of a few persons, but a documented established shared truth that stays behind when everyone goes home at 5PM.
As you now have separated implementation (Modernity) from idea (Gist) and also automated the IT- implementation process of new ideas you will see a higher churn rate when it comes to coworker driven process improvements. This will lead to increased levels of engagement from your workforce – and likely less frustration for you to deal with.
As time goes by the technology advances. Your business must then change its tools to take advantage of modern times. As your ideas now are separated from the implementation you will not be stuck with old legacy IT-systems and a hurtful transformation process. Instead you can seamlessly update the Modernity separately from the Gist.
As the MDriven method is Idea and language centric you will notice cross-department increased collaboration as ideas get communicated in a common language that acts as the truth everyone aim to improve.
A few of your coworkers will probably shine brighter than others as they may be more talented in dealing with the “why we do things” than others – and in the MDriven method these persons tend to be the custodians of the common idea and the ones working with main business improvement process. As they now have MDriven tools their result becomes facts faster and with low risk. And as the risk is reduced you can delegate even more to them than before – freeing up more of your time to work as an extrovert leader rather than someone that is mopping up conflicts and failures.
With MDriven method fully implemented your coworkers continuously improve internal and external processes in order to reduce their own stress and frustration. It is amazing what information technology can do if it is applied where it hurts in a business, by people that actually feel the pain. Coworkers that has this ability to improve their own environment are happy, and happy people does not leave.
We discussed the vision of MDriven and how MDrivenServer fits into it.
2022 31 August
Technically this is the 2de meetup for the season – but we had a “Mulligan” on the first. Posted this video of walkthrough of some of the many possibilists that the PlacingContainers enable you to do:
Learn how you can add your own views to the model designer to see the contents of your model in new ways – using the same strategy as you do for your own applications : https://youtu.be/FyddPcDLYvM
Meet 2022 16/2
In this session we discuss recent ServerSide jobs improvements. The perfect way to give your system a “pulse” – or move work to elsewhere from your UI. This session discuss definition, debugging and error catching.
In this MDriven discussion we show the new operators on boolean caseTrueFalse and WhenTrue. These can be used to make the ocl-expressions more streamlined than with clunky if-then-else-endif :https://youtu.be/WTes0K4SYZc
Meet 24/11
We are working on visual studio 2022 support. An introduction on where we are and what will be:https://youtu.be/zlVCImM7JPc
Meet 10/11
Learning how to model with MDriven. We are always on the lookout for ways to make it easier to understand what MDriven is in order to let more people discover the power of model driven development. We have one idea in particular that we want to show and discuss. https://youtu.be/EZ_c6Vu9M6E
Meet 27/10
Tonight the topic was static html vs applications and how we can use functions in MDriven to publish cached derived complex data in any shape or form for fast access by search-engines and users (with low effort). CacheInvalidation and ocl operator XHtmlReportAsString will be discussed.
I hope you can hear my enthusiasm in the video even though I have a serious man-cold. Having 100% control of structured data AND full ability to transform all data with precision AND having an auto invalidating cache mechanism is so science fiction and make building information-complex scalable systems fun and straight forward. Video-link https://youtu.be/Kjf0HnreFdg.
Debugging has many sides to it – from understanding data to stepping code. In tonight’s session we will look at some new features in the Model-debugger (your go-to-tool for investigating data) and also point out some resources to see how you can step through codedress code while running in Turnkey – and setting up your codedress code for isolated development or testing – but still with access to data.
There are signs that it is not complete – and we invite everyone to think about how to evolve this manifesto. Moving to the web and focus on UX that can work on phones and the-web-at-large probably will result in changes to our governing document and then result in new possibilities in MDriven UI stuff.
Welcome!
Update on the Linux project.
Lets discuss the UI future – what is your gut feeling?
Notice that Microsoft is vague at best on this subject; Currently they say that WPF is ok, UWP is ok, WinUI is ok, Xamarin Forms is ok and will turn into MAUI that will be ok. They also say that UNO is ok. They then say that Web is ok, especially with Blazor on webassembly.
More?
Who cares?
What are the rewrites needed for you once the Modernity switch?
We also found out why the images would not show in the demo: it was an issue on the build machine not building the typescript into js for the core projects – fixed now – but need to figure out why the core compiler skips the TS…
Meet 21/4 2021 & 7/4
Due to two different technical mishaps the videos for these 2 sessions has been lost
Meet 24/3 2021 ViewModel-Editor – overview of usage and features Continued- Q&A – Rest or UI Allowed, ActAs-Expressions etc
We did not get through the list this time either – partly because we added some things – we will keep at it!
The transform demo failed to show its point and I promised to explain why – so I checked it and it turned out we transformed a null object. This was due to us not having an enable expression on the action – so I only thought we had a vCurrent_ when we did not:
I fixed it:
And then we get a transformation from Thing/Details to Order/OrderRows:
Meet 24/2 2021 ViewModel-Editor – overview of usage and features Continued- Q&A – Again!
The important MDrivenServer has been given an overhaul regarding design and functions. Demo will show how to install it on local IIS and its new UI and functions.
Also – I ran into trouble when trying to show how to connect to MDrivenServer with PersistenceMapperWebAPI. Made a new video for that: https://www.youtube.com/watch?v=mc66E3bZYe8
The agenda for 27/8 – cache invalidation
Thanks to all that attended – caught this video of the event:
The agenda for the next meeting 12th Augustat 19.00 UTC+1
First session after summer holidays. We will show the new Wizard built into MDrivenDesigner. We need to lower the bar for newbies getting started with MDriven and maybe this wizard is on to something?
The agenda for the next meeting 17th of Juneat 19.00 UTC+1
Agenda for tonight: We will demo Localization support – for MDriven and Turnkey systems. In order to show the practical work with translations we will also demo the ExcelPlugin that is a practical tool for Turnkey systems
The agenda for the next meeting 3th of June at 19.00 UTC+1
Tonight we will demo the new Merge-Model functionality of MDriven. This is a great functionality if combined with to-the-point-small-example-models, because then you can simply add more examples and increase functionality of your system without actually doing any modelling on your own! It becomes “much larger puzzle pieces”. I had not fully anticipated the effect of the merge-model logic – but now that I have tried it out I think it is a revolution! Watch a video of it here: https://youtu.be/9_bWfAnY0_w
We invite to open discussion on all the challenges that exists in building large information systems that are easy to maintain and extend!
The agenda for the next meeting 20th of May at 19.00 UTC+1
Last fortnight it was Lars Olofsson presenting MDriven Turnkey architecture – thank you all that participated in the discussions around that subject.
This time we are going to demo how to replace part of the generated UI in MDrivenTurnkey with components you easily control/build yourself. Components and replaceability is essential to get a Turnkey based system to fit any purpose. Since the distinction between the data provision (Gist defined by declarative view models) and rendered UI (Fashion) is so clear in the architecture it should be real easy to inject your own fashion-parts – and it is – join us tonight and see for yourself!
The agenda for the next meeting 6th of May at 19.00 UTC+1
Thanks to all of you that joined last time. Interesting to hear your thoughts on software transparency!
MDriven-representative – welcome and short introduction
Everyone that was on the last session gets time for a short recap; Name, City and project or major events since last
All new members get 1-2 minutes per person for a short introduction – Name, city, current project, background, future
Upon user request Lars Olofsson (MDriven) will walk through the MDriven and Turnkey servers architecture, the web client and how you might use it – or – get ideas from our work in your application.
With the time left you can raise questions to MDriven or to other participants
MDriven-representative close the meeting on the hour (20.00 GMT+2 ) and we are welcome to continue discussion on the chat or in other format
The agenda for the next meeting 22th Aprilat 19.00 UTC+1
First of all: Thank you to all that made the last meet so good and enjoyable! We had 14 attendants and a good round-the-table introduction of everyone
MDriven-representative – welcome and short introduction
Everyone that was on the last session get a minute to recap ; Name, City and project or major events since last
All new members get 2 minutes per person short introduction – Name, city, current project, background, future
Open discussion on the topic of the day ; transparency in software – your thoughts – your ideas – pros and cons….
With the time left you can raise questions to MDriven or to other participants
MDriven-representative close the meeting on the hour (20.00 GMT+2 ) and we are welcome to continue discussion on the chat or in other format
The agenda for the next meeting 8th April at 19.00 UTC+1
MDriven-representative – welcome and short introduction
2 minutes per person short introduction of everyone in the meeting – Name, city, current project
MDriven-representative describe main focus points on development and projects
we split 30minutes and share it between attendances
– in this slot you can choose what to say; describe what you do – challenges – shortcommings – things you worry about – suggest a topic for the next meet etc
With the time left you can raise questions to MDriven or to other participants
MDriven-representative close the meeting on the hour (20.00 GMT+2 ) and we are welcome to continue discussion on the chat or in other format
Introducing the MDriven Discussion group
What should this group do? Our idea is to listen to all needs and suggestions – as well as provide information on progress and goals
Who is this group for? Our idea is that anyone in anyway associated with MDriven can participate
Can you come and go? Our suggestion is Between meetings yes – but during meeting preferably no –
How long should the meeting be? We think 1 hour and that we respect the time so that people can plan
How often do we have this meeting? We suggest bi-weakly initially
Why is the meeting held at off European business hours? We will start like this and see how it goes and if we have better suggestions
Developing detailed business support systems with software can be hard. The quickly changing requirements mess up earlier assumptions – and even if new facts are good since you learn more – you eventually end up in a chokehold where you need to choose between correcting implemented knowledge from yesterday or add new knowledge from today.
You – as the “software developer”/”solution architect”/”only grown up in the room” is probably the only one “capable of”/”interested in” tracking the current Gist of the system or best known idea of what the system is supposed to do. Everyone else is probably happy to just shoot new or revised requirements at you from the hip like were they information age cowboys – with machine guns.
There are two major strategies to manage this situation before you go mad.
Slow the process down so that you can keep up
Become an augmented developer and tenfold your output and passed requirement memory
If you ask the persons that you build the software for, they will probably vote for you following strategy number 2. Simply because slow is not fun and it is expensive.
Drew Thomas – @truedrewco wrote this tweet suggesting that the area of “nocode” could be called “Augmented Development” instead – and it is brilliant I think! Spot on!
When answering the question “Why we address system development the MDriven way” we most of the time come back to the fact that it is a great idea to separate the true knowledge of the domain – The Gist – from the fast aging technology choices (Modernity) – and from the even faster changing look-and-feel choices (Fashion). This is contrary to traditional development that mixes it all up with hard to read, non reversible code.
The main protests we get against this argumentation is oddly enough that the true knowledge of the domain (the gist) is so complex so no one can comprehend it. Ok – how to retort to that? If it was true, we can just all lay down and die anyway – if there is no way to understand anything – we should not build any system with any methodology, period.
People touting the idea that “this area is so complex so do not even try, you will never make it” most often has a clear case of the emperor-has-no-clothes-syndrome, i.e. they make a big bombastic claim and hope that it will not be scrutinized – if it isn’t – they win – otherwise they lose. They will do anything to get acceptance for their claim – everything rides on this single claim – and debating with people like that is tiresome and probably a waste of time.
Why do they do it? Why do we meet so many seemingly professional business persons that argue that a certain area-of-anything is beyond the grasp of human understanding? Well there is ALWAYS an agenda – they are not really saying that THEY cannot understand the area – they are saying that YOU cannot understand the area – and that YOU cannot describe the area perfectly with an easy to read, transparent, easy to maintain timeless UML-model that executes in an MDriven-environment. That is what they really say. And that is what we see MDriven-developers all over the world prove wrong time and time again.
As NOTHING is beyond comprehension – nothing is beyond declaration – and hence nothing is beyond system supported execution.
There is no getting away from that someone must understand the problem that is to be managed by a software system.
MDriven raises the level of abstraction so that once you do understand – you are done. The fact that you can refine your understanding indefinitely is another story – but MDriven has you covered here as well.
MDriven also keeps a high level description of your understanding in a timeless non-aging standardized format : UML.
This leads me to claim that MDriven is no-code in an even bigger way than top-brand-no-code-products because all?/most take your understanding of the problem to solve and helps you codify it into their own proprietary format – albeit with visual tools – that then is executed.
None of these tools claim to be a clear description of the problem to solve – they only claim to be a solution for the implementation of a problem you want solved. Hmm a solution codified from your understanding – an understanding you keep in your memory or other documentation. So they are not really no-code, are they?
