I believe that you are not the target audience here.
Isn't the point of dry.io that a business analyst can replace a developer? :)
Isn't the point of dry.io that a business analyst can replace a developer? :)
Only within the set of predefined functionality that can be specified in the dry.io JSON config file. If you want anything outside of that you'll still need a developer. I guess it's possible dry.io will have thousands of components that covers 90% of what each and every app does eventually, but until then most people who try it will bump up against it's limitations very quickly. The hard part will be keeping them on the platform.
Many apps we won't be able to handle at first can easily be handled by our approach with more work.
For some capabilities, we will have ways of filling gaps in the platform. We have some easy-to-use and fairly flexible hooks where you can add a lot of UI customization. We've also discussed mechanisms for catching events in dry and triggering external code developers can write. But that's almost certainly not going to make v1.
I've heard that promise before, from BPMS vendors. I don't think it ever pans out, and usually results in a hobbled system that usually still require developers to actually deliver the desired functionality. I think developing software requires a specific mental skillset that can't be replaced by technology, and promises to the contrary are snake oil.
Is it a stretch to say that dry.io would enable these people to take on simple development tasks that would be currently done by programmers?
From that you construct the required model, which is then generated as code.
Getting from a model to code is pretty well covered.
Parsing the business requirements into a model whether via decision trees, or a generative adversarial network is the tricky bit.