5 ms·

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 s

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.

gonzo41 2y ago
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 2y ago
  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 2y ago
    They're designed for purchasing departments and VPs, unfortunately.
jayd16 2y ago
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 2y ago
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 2y ago
  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.
  - quantadev 2y ago
    Oh, I definitely agree that's what should be done. You'd have generated code and non-generated code that way.
  - HelloNurse 2y ago
    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.
ajcp 2y ago
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.
- gardenhedge 2y ago
  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 2y ago
    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.
- urban_winter 2y ago
  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.
anonzzzies 2y ago
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).
- creesch 2y ago
  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/2021/02/d26_03-1714302.png?w=750&ssl=1 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.
matwood 2y ago
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 2y ago
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.
siva7 2y ago
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.
jillesvangurp 2y ago
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.
rsynnott 2y ago
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.

gonzo41 2y ago

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 2y ago
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 2y ago
  They're designed for purchasing departments and VPs, unfortunately.

jayd16 2y ago

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 2y ago

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 2y ago
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.
- quantadev 2y ago
  Oh, I definitely agree that's what should be done. You'd have generated code and non-generated code that way.
- HelloNurse 2y ago
  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.

ajcp 2y ago

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.

gardenhedge 2y ago
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 2y ago
  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.
urban_winter 2y ago
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.

anonzzzies 2y ago

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).

creesch 2y ago
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/2021/02/d26_03-1714302.png?w=750&ssl=1 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.

matwood 2y ago

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 2y ago

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.

siva7 2y ago

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.

jillesvangurp 2y ago

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.

rsynnott 2y ago

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.