Intelligent subject-matter experts who are non-programmers can build 80 to 90% of their business info capture and reporting requirements inside the walled garden of their chosen platform.
Programmers are called in temporarily to complete the final 10 to 20% of the LowCode app, and integrate with external services.
It's been happening since Excel, through to Wordpress and nowadays splintered into 100's of directions and platforms from Wix to Podio to Notion.so
I'm compelled to invoke the "Ninety-Ninety" rule when I hear about solutions like that, although I'm sure it works sometimes, in my experience it usually turns out more like this.
The first 90% of the work takes 90% of the time, and the remaining 10% of the work takes the other 90% of the time!
But to hear it explained that way, it just seems like wishful thinking based on a circular reasoning, that invites an invocation of the rule... "We spend too much on our developer staff, so in the future we have adopted a strategy where we will avoid most of the things that we need a team of developers for, so that our developers have less work to do, so that we can have fewer expensive devs (of which we know we cannot dispose entirely, [because we are subconsciously aware without them, there is no innovation to speak of at all.])"
The problem that "Low Code" or "No Code" addresses is a real one, where devs like myself, (surely not myself, but someone more junior...) confuse poorly architected slipshod solutions for innovative ones.
If we could reliably keep our code as simple as it ought to be, the market for tools like this would probably not be as large as it is.
Yes it is, but if you're doing the first 90% properly you have a much better shot at mitigating the difficulty of the last 10%.
I think there's some vague point in any project where it goes from being 'easy' to 'hard' to add new stuff. Basically the only factor that matters for productivity is how long you can delay that point. If you just do the first 90% as quickly and cheaply as possible, you're just resigning yourself to hitting that point as early as possible.
I think this is best explained without exaggeration by the famous Design-Stamina Hypothesis[1], which states the notion that time spent on Design is something which you can trade away to improve development speed, is reliably false in the long-term (even if it seems to be working in the near term.)
The graphic also suggests that there is an inflection point, as you suggest, before where time spent on design really is just slowing you down in the beginning of your project, but also that the costs of waiting too long to switch modes (from doing no design, to doing good design) after you have crossed that line, are substantial and compounding; the longer you wait, the more your lack of good design costs.
And of course, not pictured, is "bad design" which can be even worse than no design. Trying to find that inflection point and put it on your development schedule in advance is also a bit like trying to catch a falling knife (not likely to succeed.)
Kinda, it sounds very similar to the 80/20 rule. The 80/20 rule says 80% of the solution takes 20% of the time. So it's not quite the same.
In other words, the 80/20 rule says the last 20% takes 4x as long as the first 80%. In comparison, the above quote says the last 10% takes just as long as the first 90%. So slightly different.
Both this "90-90" and "80-20" indicate that the devil is in the detail. e.g. You can expect surprises as you're almost done, there's an inherent complexity to the solution, etc.
But saying "the first 90% takes 90% of the time" blatantly ignores these anticipatable unknowns; so it's a much more tongue-in-cheek thing to say.
In my experience, "Low Code" is almost always weasel-wording. It's used to describe products that try to be "No Code", but fall short. It's a way of making excuses for everything you can't do, because you can get a "real programmer" to come in and paper over the cracks. Actually writing this code is rarely a pleasant experience, and the learning curve is a cliff that goes straight from "flowchart" to "writing React" (or worse).
As other replies have pointed out, the really successful tools are like Excel: They have a real programming language at the heart of them, and they don't try to hide it away.
Disclaimer: I founded and run something you could call a "Low-Code web environment" (https://anvil.works) - but I prefer "Visual Basic for the Web" (or "Web Apps With Nothing but Python"). We built it around the idea that writing code is inevitable - indeed, it's the best way to tell a computer what to do. So don't try to hide it - make it a first-class experience!
That is because we've built tools that are good enough for most use cases, and the cases don't actually differ all that much. For every new case however, new software has to be made. It isn't getting any easier, there is just more of it now.
The problem is that a "problem" is essentially a fractal; it needs a defined accuracy and scope to be solvable. Differing scopes and accuracies again require overhauls of software that would otherwise be acceptable for the same task.
About 2/3 of software cost is typically maintenance, not original creation. If some RAD-ish tool makes maintenance more difficult, saving time up front doesn't mean a lot, other than maybe as practical prototyping. Maintenance costs include getting new staff familiar with a tool, and the turnover rate is typically around 4 years for developers. Self-taught programmers tend to produce spaghetti systems, in my experience. My first programs were spaghetti, I must say. I was an IT puppy. I short, consider the medium and long-term costs of RAD/code-free tools.
Intelligent subject-matter experts who are non-programmers can build 80 to 90% of their business info capture and reporting requirements inside the walled garden of their chosen platform.
Programmers are called in temporarily to complete the final 10 to 20% of the LowCode app, and integrate with external services.
It's been happening since Excel, through to Wordpress and nowadays splintered into 100's of directions and platforms from Wix to Podio to Notion.so