[throwaway42668]

I never understood the "low code" microbubble that was being inflated.

We went through that era already. We called them RAD tools, and they targeted the same sort of strange, mythical end user profile. Someone so technically capable and apt that they could navigate a dizzying domain of deeply buried checkboxes, property fields, and sprawling relationships & side-effects, but who was also simultaneously unable to understand source code or program structure.

When using them you would quickly hit a point where making changes to relatively simple things would take mounting an archeological dig of GUI controls that would have otherwise been a few simple find & replace operations on code in a regular environment.

[anonzzzies]

RAD is a broadly used term, but tools like Delphi were good at it and not restricted. You could build anything, but the dream of dragging and dropping little boxes and filling properties to build applications with the client and having, possibly another team, building other little boxes to satisfy the features you couldn't deliver, was a successful way of doing things.

I would say especially in modern day guy in some cases: I have not seen anyone happy changing modern code (nextjs or so) that has not been touched for 5 years. The 'just drop in a new component' won't work because 9 billion dependencies had updates and break everything (seems modern devs in the npm ecosystem have serious issues keeping things compatible even across minor versions); that issue was never there with delphi; you just make the change; either in code or gui. Many components I used for 2 decades to create and fix applications without the pain I feel these days. Unlike others apparently, I have no interest in actually maintaining applications: I want to make them and if no changes are needed, I don't want to update them; security fixes are meant to be compatible with what there already is, so that's just a recompile. It's not anymore though so it causes work and work costs money. It's not very nice unless you get paid by the hours then it's brilliant.

Commenting on your general use of rad tools, the rest you say i agree with. I see (i googled a bit) that things like Outsystems are RAD tools now, and yes, those are hell on earth to work with (we did a massive project with it and everyone basically thought it was terrible).

[rob74]

Then again, I wouldn't say Delphi was (is?) "low code". Certainly easier to use than some of the alternatives available for building GUI applications at the time (looking at you "Visual" C++!), but that just took care of the boilerplate, you still had to code the application's business logic.

[anonzzzies]

Yes, I agree, but they were talking about RAD tools and Delphi was the posterchild for RAD tools. I was solely responding to the term RAD tools (and their abuse/misuse).

[creesch]

Oh man, I totally forgot about the delphi IDE and the drag and drop editor for making GUIs. I only ever did encounter it in college (early 2000s) and for group projects it was really nice. Simply because it allowed you to prototype GUIs in the IDE and then instead of having to re-implement them in your markup language simply use those prototypes to build the functionality behind it.

https://i0.wp.com/blogs.embarcadero.com/wp-content/uploads/2...

It's a bit of a different perspective as you describe.

> I have not seen anyone happy changing modern code (nextjs or so) that has not been touched for 5 years.

Yeah... even if you do faithfully update dependencies it isn't straightforward. The sort of stuff I work on is mostly used internally and overall is fairly simple as far as the UI goes. So, for a while now, I have done away with most dependencies where I can and switched to vanilla JS, HTML and CSS for this sort of tooling. Not only does this help me with future maintaining of these tools, it also makes the whole development process a lot smoother as there is no building involved.

I very much realize that I am in a somewhat luxury position here as I don't do client facing applications and most of them are fairly simple. But that's also my point, all too often I see very simple single purpose applications that make use of a complete ecosystem of modern frameworks where the same can easily be achieved without them.

[ajcp]

I think you're taking the intent of "low-code" too literal, or have not worked in an organization of sufficient size for its value proposition to be evident. It's not to solve a solutioning problem; it's to solve an organizational one.

While any "low-code" is marketed as a WYSWG, business friendly solution platform, what it actually is is a way for the business to get access to capabilities IT otherwise gatekeeps as "domain expertise", but fails to actually produce with.

Case-and-point: IT quotes an organization $75 million for 30 projects in fiscal year 20nn. By 20nn+1 IT has completed 5 projects for $75 million. Sick. Org gets "low-code" on their own dime for $1 million, hires a couple "business systems analyst" for a little less, and in 20nn+1.5 has completed 25 projects. In 20nn+3 IT looks incompetent, gets pissed, cries foul, the "business systems analyst" are ingested into IT and taught Java and CRUD circa 1998, and the life-cycle continues.

[urban_winter]

My experience of apps built by "the business" is 13 years in UBS and Bank of America. "The business" cannot be trusted to understand regulatory and privacy concerns, they cannot test their apps, they do not concern themselves with vulnerabilites in their dependencies or the licence terms therof. For those reasons, and more, the ability for the business to deliver apps more cheaply than IT is illusory.

That doesn't stop a cyclical swing towards RAD/no-code/AI when people forget this and then a swing back when we remember.

[ivell]

I have heard this before. But before we assume incompetence, first we need to understand what the IT is producing. Anyone in IT can also build the application in a very short time. What the business do not fully understand is the effort required to implement all the other non-functional requirements they need but they don't know yet. Once the quick and dirty solution is done, and they are happy that the feature are done, they realize it is not compliant. Now they spent some effort for compliance and after that they realize that there is no backup. If the data is corrupted, all is lost. So then they call up their business analyst to implement that. And after a few such iterations they give up and hand it over to IT. Now IT has a shitty application that is not secure, partially compliant and terrible disaster recovery. So it has to be rebuilt. Now it costs much more than if IT had implemented it in the beginning.

The costs of the IT department exists because we have experience on the real costs of implementing production grade software.

For minor throwaway apps, there is always excel and MS access.

[Closi]

100% this! In some companies the 'simple app' that is described in this post will get some ridiculous quote from central IT/tech ('it will take our team 4 sprints') and then never get signed off. IT will also ban anyone spinning up their own servers due to support issues.

No code platforms manage to get around this.

Another use case - I work for a 'non-tech' consultancy. Clients typically won't like paying us to spin up some flask/django/rails app, but are happy to pay us to spin up some sort of no-code thing for them (perception is that it will be easier to self-support, which is also probably the reality compared to me developing some sort of rails app and then leaving the company).

[aitchnyu]

I saw the powers that be sit on requests for access for readonly BI tools on existing DBs. How do the low code vendors get VIP treatment?

[Closi]

In my experience you are right - IT will always deny these requests, so you need to build the solutions in a way that avoids accessing existing DBs.

Usually it’s replacing a spreadsheet, so either the information can be manually keyed in or can be imported from various reports. Sometimes you even get into screen scraping, sometimes scheduled reports that are getting dumped to a drive and getting imported… basically any way that avoids needing to get permission from the IT team.

[jordanbeiber]

Writing the code is NOT the problem with these enterprise project failures.

Usually decades of problem-solving have led to an absolute mess of blurry ownership and accountability.

This in turn leads to corner cutting and a road completely covered in Chesterton fences…

Tearing arbitrary fence down leads to consequences out of project scope, no one can answer questions, and no one can prioritize - this is a business problem, and no amount of fancy code (lo/hi/full/lo/left or right) will help.

If you run a bigger company and rely on IT and ERP flows, well, it’s a part of your core and you’d better treat it as such!

[gardenhedge]

From your first sentence it is implied you have some working experience with this. What are your thoughts on end user computing and the longer term effect in the business?

[matwood]

One of my very first jobs was taking tools that were developed at the team/dept level and scaling them up org wide if they were useful. Honestly it was great to have end users already deeply thinking about what’s needed by building prototypes themselves. This business was much better for it. Looking back I was very fortunate to land in a large business who embraced technology as a key differentiator very early on.

[jayd16]

Low code tooling is alive and well in the entertainment industry. Node graphs are becoming very popular in game engines, shaders, procedural modeling software etc.

The king of low-code, spreadsheets, are still quite popular as well.

[quantadev]

Well said. You are exactly right. Low Code stuff is usually invented by people with a specific set of criteria that they realize can be generalized, and defined by a GUI, but who lack enough experience to realize the entire world of possibilities can't be crammed into their model. Languages (like Python, etc) are already the most compact way to represent most things, and trying to avoid that fact just makes things even harder.

[jayd16]

You're letting perfect be the enemy of good. The low code solutions can simply have a full-code escape hatch with interop. Much like how Python can interop with C.

[HelloNurse]

But people who lack enough experience to realize the entire world of possibilities that can't be crammed into their model aren't normally humble enough to design good escape hatches.

[quantadev]

Oh, I definitely agree that's what should be done. You'd have generated code and non-generated code that way.

[matwood]

I don’t think they were strange or mythical users. Excels and Access gave business analysts enough power to make real tools tailored to specific needs. VB would have been the next step. One thing that made this possible was the ubiquity of Windows though.

I still haven’t used anything as easy and powerful as those tools were even if they were Windows only and lacked easy distribution.

[ozim]

I see it quite often as SaaS platform I work for the configuration grew into small time low code because business wanted to do all kinds of changes skipping dev cycle to deliver faster.

„low code” appeals to people - who are not technically capable, whose numbers are big - who think if they can get rid of this complex writing stuff they will be able to do stuff. Those people are on all levels of seniority so if CEO mandates stuff, company will do that.

Unfortunately essential complexity of an application does not go away and I have seen those people struggling, cursing and shooting themselves in the foot.

proper software dev tooling has all the right solutions for handling complexity like version control, CI/CD, unit/integration testing - no low code tools implement that.

But if people hear my solution „let’s teach you proper dev tools” they are pretty much uninterested.

[rsynnott]

It's particularly baffling because there's currently a _competitive_ "do programming without doing programming" bubble; LLMs. Whatever about one at a time, it's odd to have two approaches to the same false promise going at once.

[siva7]

RAD tools had nothing to do with low-code. I think you're confusing something. You still needed seasoned software developers and you weren't restricted by anything.

[gonzo41]

Everything you just said also applies to all ETL and workflow management tools as well. There's a level of complexity that's never going away.

[stoat_meniscus]

Yes, Informatica was the one that came to mind.

We inherited some Informatica ETL workflows once at work. Nice at first glance with good logging, but peel back the surface a little bit and it was a dizzying level of hidden complexity. Some of this was business logic which was inherently complex, but it was so deeply buried in menus and abstractions with no easy diffing or version control...

Like the comment starter mentioned - who are these tools designed for?

[disgruntledphd2]

They're designed for purchasing departments and VPs, unfortunately.

[jillesvangurp]

Low code efforts go back decades. In the eighties there was this whole movement around 4GL languages. Basically relatively simple languages around databases that enabled relatively quick development of business applications. Before that, Cobol of course was an attempt to come up with a business programming language that was nominally human readable. In the nineties we got things like Visual Basic, Delphi and a bunch of other things which again were targeting relatively inexperienced programmers. And then of course there's a long history of creating domain specific languages for all sorts of things - typically with the goal to let domain experts be able to define things. Tcl/TK is a good example for UI applications on X-windows.

Rails built on all of that. Ruby brought two useful thing to the table (well, borrowed from Lisp) which was meta programming and the ability to use its syntax to build so-called internal DSLs: domain specific languages which were just building on top of Ruby's own syntax instead of needing a new one. Rails is basically a DSL for building web based database applications with server side model view controller style UIs.

Once MVC moved mostly client side with single page javascript applications and rich mobile applications, the MVC bits and bobs became somewhat redundant. And of course the rest of it is basically a nice but otherwise unremarkable ORM framework that you can find for other languages as well. I was never that impressed with it to be honest and I'm not a big fan or ORM frameworks in general. Server side MVC is still somewhat relevant if you are into server side rendering (which reinvents what world + dog was doing twenty years ago) but otherwise not that relevant for most REST APIs.

IMHO the last two decades have been a bit unremarkable for UI development. It seems a lot of things plateaued in the nineties. The average UI projects are still fairly labor intensive for what they do; which is mostly just building a lot of form based crap to input data in some database. We had perfectly usable and relatively idiot proof visual UI builders that did that sort of thing thirty years ago. From a functional point of view, the resulting UIs more or less did the same thing. Was that great code, not necessarily. But it did the job. And most "modern" react/rails/django/whatever code isn't a whole lot better. If you discard the lipstick on a pig that is CSS, you are left with essentially the same UI components and primitives (buttons, checkboxes, text fields, etc.). We had all of those decades ago. You don't need a mustache twirling hipster web ninja to reinvent those wheels.