I agree somewhat, the problem with "business outcome perspective" likely means very short term thinking, get it done now, deal with the rest later.
The people that cause the mess are not likely the ones that have to clean up the mess, people like me are. I prefer to greenfield things but instead I spend the majority of my time untangling the bad choices people made years before coming at it from a "business outcome perspective"
There should be some kind of middle ground, likely starting with proper, actual training and restricting access to low code solution to people that have at least some technical literacy which often does not happen.
I tend to agree with you in most situations, but I do think there are some counter examples.
The recent rollout of various COVID tracking apps for large companies come to mind. There was no way to predict the need, and low code tools were leveraged heavily to spin up quick solutions. e.g. I believe SalesForce products were used for some of the "Vaccine Finder" types of sites that spun up in my state.
That aside, as a general rule, if these are such important projects, the business should expand its development org and improve internal processes to better react to business needs.
But it seems like an almost universal problem (especially outside of tech) that this just does not happen. There is often very limited appetite to take on the risk of a big dev project without understanding its value. You could argue that building a business case is a better way to prove that value, but on the other hand, if you can build a business case by literally implementing a solution, and bring data to leadership that clearly says "this is worthy of investment, and here's a v1 already working to prove our point", this appeals to the risk averse management types since it proves the need.
I don't think this is a great mode of operation, but I think it helps explain why we see such investment and growth in these tools.
The CCADB https://www.ccadb.org/ is built out of SalesForce. Its purpose is to mechanise the paperwork needed to manage the relationship between the major Root Trust Stores and the Certificate Authorities.
Its members are Mozilla, Microsoft and Google (in principle you could imagine Apple choosing to join some day, or then again maybe not, likewise perhaps Oracle). Clearly any of those entities could build a web site, they already own several web sites, and if this was rocket surgery (and it isn't) they employ rocket surgeons already. But they chose to use SalesForce.
And I've always supposed that one big reason is that you clearly can't let the other guy write the system you'll both use, and yet you also definitely don't want to waste your resources on working together to write it, that's usually even more expensive than either of you writing it alone.
But low code as a matter of principle also makes sense in this space. This is "just" mechanising some paperwork, it shouldn't need to be complicated. There shouldn't need to be a Mozilla engineer working on the CCADB.
The people that cause the mess are not likely the ones that have to clean up the mess, people like me are. I prefer to greenfield things but instead I spend the majority of my time untangling the bad choices people made years before coming at it from a "business outcome perspective"
There should be some kind of middle ground, likely starting with proper, actual training and restricting access to low code solution to people that have at least some technical literacy which often does not happen.