It also helps the other teams understand the complexity of there problems (sometimes), and helps IT teams understand the use-case or idea.
I have seen project lead times reduce from month's to days.
All said and done though technical oversight and management is still required.
I'm increasingly beginning to question how this is even an advantage. If your IT team is overloaded... hire more and pay them better.
Another way of saying "allowing non IT teams to do the work themselves" is "taking a specialized job that can be efficiently done by a dedicated professional, splitting it into thousand pieces, and distributing those pieces evenly to everyone". Sure, it's nice that a marketing manager can no-code some automation without having to bother an overworked IT person, but now no-coding that automation becomes yet another little bullshit task that distracts them from their core competency, i.e. marketinging.
This is one of those trends that feel beneficial on the surface, but less so if you look closely, at least in job context. The OG one are office suites - particularly word processors, spreadsheets and calendars. Yes, it's nice that I can write my own reports, tally stats on my own, or manage my own meetings. It's less nice that I have to do it all the time, where in the past, there were people hired specifically to handle this job for everyone else. How many highly-paid software engineers are being distracted and waste their time on this, only so that corporate can save on hiring lower-paid secretaries?
I don't think it even adds up economically, but the trick is, once you eliminate a job with software by outsourcing it bit by bit on everyone else, even though it's now much more expensive, it disappears from the company books. Not having to pay extra salaries is legible. Overall unexplained productivity drop is not.
What happens when stuff evolves and becomes integrated?
I’ve, several times, seen the result of tangled lc/nc stuff gone production critical and… it becomes an unmaintainable mess that no one wants to touch. This becomes a massive roadblock for agility and change down the line.
A simple, discrete, crud app that could have been an xls - sure. Great for PoC and demos; horrible in a live business setting. IME.
Also, there are apps that are useful but don't need to be used enterprise wide. No code will change the work environment similar to the way the the spreadsheet changed it.
I’m in such a situation as we speak, and I’ve worked with low/no code workflow tools for more than a decade.
I’ve been part in building two: one BPM(N) workflow based and one graph-based data-modeling, form-building, event-sourced nightmare (like Alan or structr [1], both probably 10 years old by now, btw) - it goes for a great sales pitch but never touches on the finer points of maintaining and iterating on systems over time; a.k.a ownership!
Coding is usually not the issue, especially in business settings. Rather it’s about accumulating domain knowledge and expertise and figuring out boundaries.
It’s perhaps even more about owning the end results over time.
There’s a sort of quasi-competency built up around tools like this - you still need to understand how to build and govern systems, which is the hard part.
You end up with non-system thinkers that can build opaque stuff in a DSL. This ends badly.
Yeah, I’ve been around. Also blockchain will change everything. ;)
1) produces a just wildly, horribly inefficient solution, just doesn’t care about optimization or big-O at all.
2) guides the user through producing some reasonably sane design docs that describe what they are trying to accomplish
Then you’d pass those docs and the toy implementation along to a programmer