1) Where is the data (beyond an anecdote) that shows that no-code solutions generally cost 10x more to build?
2) Putting aside these initial implementation costs, do these no-code solutions have other advantages, such as being less costly to maintain, or being far quicker to customize when needs change? There's always some tradeoffs to take into account.
No.
I have some experience with low-code work flow -esque tools. BizTalk, Talend, SeeBeyond ICAN / Sun Java CAPS, a few others.
Categorically, they're an angry 800lb gorilla sitting between you and your work.
Their sweet spot is demos for PHBs. Their purpose is to create a lifelong dependence on the consultants proposing these tools.
All of the many legit criticisms (leaky abstractions, poor version control) boil down to this one simple truth:
At some point the tool won't suffice and you'll have to drop down to code.
Which is likely buried under layers of XML obfuscations. Now you have two problems. (h/t JWZ)
So what started as a very simple data processing problem {1}, requiring nothing more than some scripts, has now metastasized into: schema compilers; magical error handling; wrangling XML thru ancient textarea forms; fighting yet another framework/API {2}; debugging thru trace statements and grepping logs; some almighty backing database which no one can access; endless fruitless conversations with nominal DBAs about indices and workloads (and "has anyone done a backup?").
On the bright side, some days you can actually manage to fulfill a customer's use case.
--
{1} Input - Munge - Output. Cut & paste strings, some light type coercion, modest value mapping.
{2} Another greenfield half-baked zero-validated notion of the world's greatest workflow engine ever, belched forward over one long kids-free weekend by an esteemed principle senior software solutions architect (they wrote a book!) who is now deep into their mid-life crisis and way past burnt out, with a code base now maintained by a fearless project manager (and aspirational future VP of product) snagged from some travel related startup, with the mandate to deliver some results, so then reluctantly brought in a team of agile mercs, just to appease the over eager execs, who are trying to fast bulk up to legitimize their efforts to secure another round of funding.
The sweet spot is of course demos for PHBs. The allure of inner-platform effect in almost every case has always been that drive towards "we can save money by not hiring actual programmers". It is a delicious vision for business people that remains forever ironically unaware of the "law" that is a direct corollary for the inner-platform effect: any sufficiently advanced configuration is indistinguishable from programming.
The perceived "advantage" of "No Code"/"Low Code" is increased ability by companies to "move fast and break stuff" with process testing or data visualization or "one-off" tools.
The true "advantage" of "No Code"/"Low Code" tools is how well they shift tasks from senior developers to more junior developers and/or business users that want to try amateur/semi-pro programming without the requisite bump in salary. But if you are going to need a senior developer to come in and properly productionize it anyway how much are you really saving? How much are you instead over-expending on "ejection" and rework and rewrites that might have been avoided just going to more senior development staff in the first place? (How much of the senior developer anguish could be avoided by realizing that "move fast and break things" includes accidentally breaking senior developer morale every time they are handed some strange "Low Code" thing from business people playing amateur coding adventure hour and throw it over the wall with "we need it in production stat; it's mostly done so should only take a few hours, right?")