I've been working in and supporting low-code environments off and on since the 90s (Lotus Notes -> Sharepoint -> Salesforce, if it matters) I've been the guy who does those re-writes when needed. I can confirm that the biggest and worst of them need re-writes, but most just need a little cleanup. Most are like you said, a non-programmer does something unwise. I spent much of my time giving people a "Dev 101" course to help them do it better, and they'd build heaps of apps that never needed re-writes.

Even when they did need taken over by IT because they scaled to a level of being business-critical, they rarely needed a full re-write, they most often just needed enhanced. Adding in validation, data integrity, backups, UX, testing, and simply streamlining the app with features that needed "real" code. And once a decade we'd re-platform them all as the underlying platforms become outdated and were eclipsed by something new.

It was amazing how well the non-programmers could do if given a weekly opportunity to just come in and show their work, ask questions, and get advice. Some of the people I coached even went on to learn how to code and have become successful software engineers in their own right.

If you ever end up supporting such environments again, I'd recommend considering yourself a mentor to new developers more so than someone who is going to clean up someone else's mess. People might surprise you with how much they are capable of.

100% agree with you.

I really enjoy supporting people who have already built their own tool, but need a programmer to take it to another level. Such projects tend to be well scoped, and the project owners are heavily invested in and understand their actual needs.

In 20+ years of professional programming, projects that started with the end user solving their own problems have nearly a 100% success rate.

Yes, no-code solutions almost always become ugly, buggy, monstrosities, and there are technical limits that mean it needs wholesale replacement, but pragmatically I too have seen them getting jobs done. I'd also wager it will not cost more to rewrite it, especially if you deeply discount the non-developer resources that were used to create it (often salaried employees' time, and even then those individuals likely came out ahead compared to the tedium of doing it manually). Consider it a prototype. Also, the functional spec of "do exactly what the domain expert made this convoluted Excel spreadsheet do for the last 2 years, but with better validation of inputs" is often far more accurate than some daydreamed RFQ.

The part that confuses me is why this makes sense as a separate enterprise product. Had the original author been interested in learning a new tool, they'd have probably been better off starting with Python. I recognize that non-developers are silently building their own tools, some of which will be a hit and later need replacement by developers, but are there really sales teams going around to big enterprises suggesting that they buy licenses for all their employees to be able to build their own tools using their particular low-code solution that will eventually be replaced? Seems like a difficult thing to sell IMO...

Not everything is a large ugly, buggy monstrosity that needs to be rewritten into "real software". There are may business processes served quite well by excel which might be enhanced with a low code solution like this and could stay that way for over a decade.

Usually significant low code stuff is more reflective of organizational politics than anything else.

Individual or small team productivity is one thing, the bigger low code monstrosities are usually a way for a vendor to weasel in and sell services under the IT peoples noses. The power automate bullshit cements whatever legacy junk it is feeding into and makes Azure the happy path for modernization.

On the flip side, there's plenty of ugly, buggy, code monstrosities that have to be rewritten or refactored. This just means the professional developer gets to start with a clean codebase with the UI & processes already laid out as an example. Almost like the no-code is a working prototype in place of a requirements doc.

In the last 6 Months my workplace has started heavily using Power Apps. The first impression I got was 'holy crap, this is MS Access on steroids'. My workplace heavily(ab)used Access in the 90's and we got bitten very badly when support for Access was discontinued. We also had a lot of VB6 code which was similarly orphaned.

In the mid 2000's someone in our IT department decided all new business apps were to be written in Java I believe this decision was made partially as a reaction to what happened with Access and VB6. The result was everything stagnated our in house apps became massively bloated, buggy and almost no one did anything 'to fix things. Any changes had to go through external contractors because no one knew Java or how to support these apps. If they had mandated Python like the post I'm replying to suggested I am sure the results would have been the same. Probably worse because harder to find cheap contractors to work on business apps in Python.

You are not going to get HR people, you are not going to get Finance Accountants, you are not going to get commercial team or legal to learn a full on programming language. That is why these products have such a niche in large Enterprise orgs.

Yes you get buggy monstrosities but you can also very rapidly develop working tools that solve real business problems.

I think what makes Power Apps attractive is the whole Azure ecosystem Microsoft have built around it. There is a whole suite of tools that all talk to the same common backends, Power Automate, Azure Databricks, Azure ML, Power BI, Power Apps etc. From what I've experienced as all of this stuff has been rapidly rolled out across my org is it all "just works" and seemingly solves real problems.

My real fear is that 5 years down the line it will have all be abandoned and we'll be left with MS Access 2.0 and a bunched of orphaned unsupported apps again. I hope Microsoft have learned from what happened with Access but at the moment it remains to be seen.

Yeah, this is pretty much the use case for low-code solutions like Access. Being a developer is an exception, rather than the rule, and there are a lot of smart BAs out there who know software could improve their lives.

I feel like if AI gets really good, low-code is the future. In the future we won't eliminate software engineering but it will become increasingly less technical until software devs and BAs merge as one profession.

But that's decades off if it comes at all.

"Low Code" is a new (to me) buzzword, but Microsoft has targeted that niche for a long time. Specifically I'm thinking of the older Visual Basics (3-6) and the advanced scripting and database features in Office.

I have seen first hand on some lifescience consulting gigs how VB.NET takes away people from R, Python and similar tools.

It is the Excel experts that have outgrown the macros and VBA capabilities, and get IT to install Visual Studio with VB.NET on their computers.

They then double down on their VBA skills and somehow get to produce something in Windows Forms, or an Excel AddIn for the task at hand and then get going with the actual work.

Then one lands on the lab and it is full of such small utilities.

Neither VB, VBA, VBScript nor VB.NET are "low-code" or "no-code", they all were rather code heavy... Some VBA 'apps' relied heavily on their hosted application object-model (Excel, Word, Visio, etc) - but there was still quite a bit of code that the average corporate Excel-wizard was never truly comfortable with.

In the Microsoft space, historically the true "no-code" solutions were Access Web Databases (no VBA allowed - of course they axed that whole service in 365, as they could not monetize it as well as SQL Azure), or web-capable Excel workbooks that rely exclusively on PowerPivot/functions (no VBA allowed), or web-enabled InfoPath Forms (also... no VBA allowed).

In their modern universe their equivalents are; PowerApps, PowerAutomate/Flow, LogicApps and PowerBI - just as the article states.

>>It’s ugly and buggy but gets a job done. This works for as long as they don’t hit a technical limitation then call devs like myself in to replace it.

Or more likely they leave the company, it breaks and no one knows how it worked, how it was suppose to work, or anything about it so they need to call in someone either from Internal IT, or and outside consultant to figure out what broke, and how to fix it...

Yes this happens...sometimes. And, other times, (as reflected in comments ITT), there are many cases where a low-code solution built by a non-dev have brought huge benefit. (I've seen this myself - see below - MS Access apps that saved hours and hours of work, but which IT had not time to look at.) I've also seen the sentiment in your comment lead to an outright ban by IT dept. of all low-code tools, for no other reason than the "slippery slope fallacy" that "if we allow this, we could potentially have a big mess to sort out one day". And in doing so, summarily kill a ton of innovation and productivity.

One anecdote I remember - a regulatory change created a major issue for a billing department. They went to IT to get their help to address it, and were told "sorry, no time to even talk to you right now. Come back in six months. Actually, make that 8 months." So, a tech. savvy person in the billing dept. built something in MS Access that solved the problem. They were thrilled. When IT heard about it, they tried to get the guy fired. Billing Dept. manager had to go to bat to make sure that didn't happen.

My counter, and anecdote, to this is the IT Dept recation is not so much a "slippery slope fallacy" but rather a reaction to past actual experiences

it is ironic that you bring up Access because that is one the tools I despise the most, our helpdesk is routinely indated with requests from people that pass around Access Databases with custom data links either to Excel files, or ODBC connections that are not standard but rather customized by the "power user" that created the database, then they share the database and it generates all kind of errors that the non-power user can not fix so IT gets roped into spending our time fixing not only users system to establish the needed data links, but also moving things around and reconstructing the databases so it actually works in way that is shareable

The IT Dept has also spent countless hours correcting Access Database connection issues, and schema issues when we move servers, upgrade platforms, or do anything on the prod system that end up breaking the Excel and Access "Low Code Applications" that consume data from these services because the end user lacks the technical ability to fix them often because they were created years ago by people that have left the company or retired.

Sure it's work. But is it really more work than developing an entire new system from scratch? Because that is incredibly labor intensive, if not one of the most expensive endeavors in IT you can undertake imho. It's easy to think IT will create the perfect system that has no support issues but TBH there will probably be just as many.

So you'd ban MS Access? Why do people use it as opposed to an "IT Sanctioned" tool? If you IT dept does not have time to provide the tools people need to do their jobs, and you take away one of their tools, what/who fills the productivity gap?

No difference than Excel Macro apps today. When Excel Macro wiz kid leaves the department or the company and it either breaks or needs new features then it goes to IT and they don't work on Excel so they will push to rewrite it into a web app.

The plus is that the use case and value for the program is already proven, so IT is not wasting time creating things people will not use.

I'm sure a lot of projects would never make it to developers if somebody out in the field wasn't trying to solve a problem like this in the first place.

Isn't that survivorship bias in action? Good solutions that not only work, but work well and don't hit the tech limitations would never be seen like developers like you, because they would never need to be rewritten.

I am not sure how this comment contributes to the thread. It is a bias because I write my real-world experiences? What you are saying is true for so many things. Car that does not break does not need a mechanic. Of course, and nobody is disputing that. This comment just made me laugh so hard I had to reply.

I apologize if my comment upset you or was offensive to you in any way. I only meant to notice that your comment paints a picture of all such projects being awful, and this may not be a faithful representation of reality.

If you didn't mean to paint such a picture, I'm sorry for misunderstanding.

THAT comment contributes nothing to the thread.

I think low code works for smaller more routine projects where hiring devs is just not all that feasible.

A lot of people stuck in places like, say, the accounting department have the soul of a dev. They like technology and want to automate things. And often times when they do that, they actually improve their departments quite a bit with stuff like VBA and Access projects (as uncool as they may seem to some).

It works because "real" programming environments have learning curves that are hard to tackle if you have a day job, and even if you do tackle them, IT is probably not going to give you direct database access.

I had a friend like this, who was bored as shit as an accountant. I convinced him to migrate his career to software and now he's in a data science master's program.

if I may be so bold ( and presumptuous my suggestion is of any value) I wondered if your friend would like the risk and structured securities aspects of actuarial catastrophe risk markets. This pretty much has everything in it, from chaos theory to the statistics of the cadence of liabilities upon the different kinds of financial engineering structure that are used to distribute * the liability and fund the most difficult to reinsure policies in the capital markets.

edit : * and package, according to a tremendous variety of fiscal requirements and risk appetites. And naturally covering the most extreme conditions liability payments is historically a fascinating insight into how we developed our world across and binding together such tenuous links.

Actually he's super into stock options and all that stuff. I think he majored in finance. I was the one who convinced him to do programming (although he's heading towards data science I guess now).

Also we had a falling out since then, so shrugs.