| It's critical that; what ever you're trying to accomplish in a low-code environment; can be accomplished with minimal abstraction-based concepts, like variables and methods. You environment should be as easy / hard as Excel programming. In the 1980s there was a major effort to make programming intuitive through visual-based programming tools. There was even a journal dedicated to visual programming. I happened to read through some of these articles in 2002-03 for a college project. The conclusion in the last journal was that programming requires concepts that can only be expressed in words. Visual (intuitive) programming eventually failed because it wasn't expressive enough. At the same time, Excel took off. Although it doesn't have "variables," it does allow for expression of abstract concepts. > I'd expect the software engineering team to manage these apps, so the benefit I can see is the quick turnaround on the UI, rather than handing over to non-engineering users for development. IMO, make sure the team that's going to manage these apps is involved in choosing the toolchain and has complete buy-in. (Or at least has a healthy skepticism.) There's nothing worse than an edict coming from down on high to use a bad tool. Also, keep in mind that, if you're using well-educated software engineers; lightweight scripts in languages like Python, Javascript (via NodeJS), LINQPad (lightweight C#), ect can go very far. Because you're working with mature languages, you can minimize your technology risk. When I was at Intel, we had a rather robust batching system for VBScript. It could call into custom COM objects, usually written in C++ or C#, when needed. |