Low code sounds like the worst of all worlds - non developers can’t do shit in it bc they don’t write code, and developers would hate the guts of it bc it’s all using some custom dsl with unknown quirks and limitations. And management will be wondering what are they paying for in the end if all these people can’t <do that damn one weird thing that I got asked about in some customer demo>, and then would fire everyone and scrap the tool.
I use a low code technology for a living and this is spot on. You can give people options and knobs to play with but anything resembling coding is not going to work. And ultimately it slows down actual development because the low code is a bad abstraction. Often hiding what's happening in the actual code making it difficult to develop and debug.
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
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.
Equating MDD with low/no-code feels like classic tool tunnel vision, with confusion on one particular notion of How for the broader Who/What/Why.
-- Who/What/Why: From a design perspective, Low-Code means productivity for someone like a BI Analyst who will jump crazy hoops to stay in a UI + SQL and never go deeper, while No-Code is not-even-SQL. It's not even that clear cut in practice: Even if a no-code UI allows visual coding, many users will still consider that "someone else's job" for most of their work.
-- How: Whether it's MDD, neural nets, program synthesis, or the latest VC-fueled JS-is-the-new-VB dumpster fire ready to implode, it's the devs who care, not the user.
Interestingly, as soon as you appreciate the constraints of the Who/What/Why, new implementation dimensions open up for the How. We're picking our own pieces for the How part of no/low-code (rejected the MDD + JS approaches), but IMO just as important, working through design considerations for the social & collaborative nature of code, esp. as it enters team/org/OSS/etc. scenarios. It's sort of like, all social networks are basically the same from 10K ft, but it's not easy getting the design decision right of how 140 characters for dense broadcast x AI-mediated voting will define a successful niche like 'community newsfeed for between tasks on your laptop + on-the-go'.
Edit: Historical note on the How - MDD is from a fun era when folks were figuring out domain-specific workbench tools and what becomes possible with them. While some of that is continuing even today (esp. in Europe!), most R&D here has largely advanced to program synthesis (esp. via SAT/SMT), and much more nascent, via neural nets. That's far out enough that I can count on my fingers how many startups are here, vs more VB/Excel/Hypercard-in-JS
I don't think they're the same, but I do think low-code has become synonymous with incredibly special-purpose tools that barely resemble programming.
We've been building Encore [1] to improve on this. It's a backend framework that simplifies not only how you write code, but also integrates with your cloud provider and automates the infrastructure management.
I work with low code solutions and they are not model driven, they are just drag and drop GUI builders with some workflow capabilities. Pega is low code, Appian is low code, but they all need code in the end to do clever stuff. Typical Appian team is a couple of BAs and twice as many Java developers.
It isn't low code, it's BPM, and it's always more trouble than it's worth. But they currently have some of the best sales teams in the world. TBH big businesses should only pay for commercial Kafka and RPA.
"The world needs more {model-based,model-driven,low-code} software engineering", cried the dumbass sitting in front of Matlab screwing up a signed comparison. sigh
That being said, SIMULINK is probably the best of the bunch because you can output actual C code from it. Maybe not super readable, but at least it's something.
Words meaning often depends on implicit context. Low-code marketing is about allowing non-coder to do programming, whereas model driven is the old dream of backend developers to generate code from a model. Some editors who were in this business since a dozen years profit from the trend to wear the low-code trousers of course :)
As for me I don't care I'm building a meta-tool (so not yet another low-code tool) which will help use any traditional programming languages, frameworks or EXISTING OR FUTURE low-code, MDD because I'm agnostic to technologies, what matters to me is to get the job done both in quality and productivity.
Not there yet I'm in proof of concept phase but I'm now more sure it will fullfill its promise since it's built by eating its own dog food.
They are the same, if you ignore the VC-driven buzzword use of it...there are far more products that have nothing to do with developing applications being called low-code than there are actual development platforms.
Basically any solution that gives you a decent amount of configuration options is increasing falling under the low-code banner.
TLDR: Yes, or better said, low-code is a "style of" model-driven development.
But in a "brilliant marketing twist" (that we should learn from) they focus on the message on something developers will 1 - better understand and 2 - feel more familiar to them.
It's much easier to understand the concept of low-code (I still code if I want but less) than something more abstract as "model-driven development"
> This is a short position paper and should be read and interpreted as such. 2 – It is probably controversial. If you feel offended when reading it, I did a good job
lmao, no one's getting offended over a discussion this benign.
First thing my eyes fell to is a big XML document and then a bunch of async functions. I'd have a hard time believing this is truly low-code but instead just another layer of abstraction upon a subset of things that a general-purpose programming language can do. You always hit a wall with these things the minute your business case genuinely demands any advanced data structure or god forbid (gasp!) you genuinely need to multi-thread something. Like, how am I supposed to tell one of these low-code things to use, say, an AWS SDK, or manage a DB transaction--like, totally pedestrian/everyday needs of software?
Good software engineering is all about managing what subset of the project should be an abstraction and what part of it needs to be a custom data structure/algorithm/multi-threaded processing routine to meet the behavior and performance requirements. The question is how much of your time to you want to spend writing the abstraction to suit your needs or how much are you willing to bend the requirements to fit something off-the-shelf.
If few of the operations your software needs to do are just business logic and database transactions, you expect to be called each time the thing needs changing, and the only people making the changes are going to be programmers, then it would be foolish to import some heavy-handed external framework: You should then abstract only to the extent that it makes the business logic easy to understand and makes the tedious part go faster.
If, instead, you have a 'typical use case', with database inputs and database outputs, and an army of domain experts who aren't programmers using the tool, then it absolutely makes sense to use some heavy, featureful, off-the-shelf abstraction. If you've never had that situation, then that tool does probably look unfamiliar and undesirable.
But be aware that both kinds of environments exist. Also be aware that it's the tendency of a growing or acquired business to move from the former to the latter.
Well, I am not sure if that is possible. You should stay within the comfortable confines of the platform and its features. Then you can build CRUD applications on it that scales to thousands of users each using the app on their phones or tablets.
