2 ms·

In my experience, the best way to have a "low-code" environment is to use a high-level language with rich facilities to build custom abstractions, and to use th

In my experience, the best way to have a "low-code" environment is to use a high-level language with rich facilities to build custom abstractions, and to use those facilities to build a DSL that domain experts can program in their business logic. And I'm not just trying to say "use lisp". I've seen it done in Erlang (for example). At the end of the day, it doesn't matter to much the specific language. I'm not sure what concrete examples the author has in mind for "low-code" or "MDD" solutions, so this criticism may be irrelevant, however I will say that drag-and-drop GUI tools for building business logic tend to fail for the following reasons: * They have poor version control integration * They have limited facility for creating new abstractions, which results in a lot of duplication * the amount of inherent complexity that can be tackled with these tools is surprisingly low

bob1029 6y ago
We do this with C#. Layers upon layers of abstractions that ultimately wind up in data-driven points of control that align perfectly with the business questions. This allows for someone to reconfigure their business workflow application by logging into a web portal and adjusting a few settings. For instance, if our application were used in a retail environment, we would have a way to add and remove products from inventory using a web-based workflow as opposed to sending a change request to developers each time. Ultimately, the key to producing a low code solution for us is to identify all of those points of change across business owners and contexts, and then to expose them in a way that the business owners are able to understand and manage themselves. This is never a perfect solution but you can usually get very close to no-code after a while. Also, you can never start with a low/no-code solution. You have to start with the option of full-custom and slowly work your way into low/no-code. Developing Data-driven contracts which implement the various aspects of the business processes are the key to moving the slider down the spectrum.

bob1029 6y ago

We do this with C#. Layers upon layers of abstractions that ultimately wind up in data-driven points of control that align perfectly with the business questions. This allows for someone to reconfigure their business workflow application by logging into a web portal and adjusting a few settings. For instance, if our application were used in a retail environment, we would have a way to add and remove products from inventory using a web-based workflow as opposed to sending a change request to developers each time. Ultimately, the key to producing a low code solution for us is to identify all of those points of change across business owners and contexts, and then to expose them in a way that the business owners are able to understand and manage themselves. This is never a perfect solution but you can usually get very close to no-code after a while. Also, you can never start with a low/no-code solution. You have to start with the option of full-custom and slowly work your way into low/no-code. Developing Data-driven contracts which implement the various aspects of the business processes are the key to moving the slider down the spectrum.