I've looked at a whole bunch of low code tools in the last two years and my opinion has shifted from high grade bullshit sold by the clueless to the even more clueless ('Now: coding for managers') to where I believe that the current crop of low code/no code platforms has something real to offer and has staying power for some use cases.

Specifically: lots of forms based processing backed by relational DBs with occasional excursions importing/exporting data to and from other systems where the flexibility outweighs any kind of performance and integration issues.

Have a look at: Mendix, Betty Blocks, Outsystems. Each of these has something to offer the others do not, and all of them help non programmers or beginner programmers to roll out working applications for themselves and their peers.

Sure. Tools like that have been around since the ‘70s. They have their uses — building forms and reports point-and-click. But the limited scope and inevitable low ceiling of capabilities means they did not spell the end of programmers. Instead they expand the market because the non-programmers will need help when they outgrow their tools, or even sooner when they can’t figure out a JOIN or GROUP BY or how to handle record locks.

No, this is a lot better than what was sold during the 70's, 80's and up to the mid 2000's. I'm aware of all of those developments, was regularly pitched about them and have evaluated the bulk of the solutions on offer, from Mimer, Mapper and other mainframe based solutions to the various offerings on PCs and UNIX platforms. Those are not to be compared to the three I mentioned above.

Agreed on the fact that these lead to market expansion and that they typically are only good up to a certain point but the examples you give are solved problems for a long time now.

"Mendix, Betty Blocks, Outsystems"

Interesting. I've never even heard of any of those products. They must be in some completely different space than I'm operating in.

In 1980 I was a database consultant, with a long-term account at NY Telephone. Their marketing department mainly used a 4GL called NOMAD. I have to say, it was really great for creating hierarchical databases and for formatting complex reports from it. In fact, when I moved on from that world, I've always missed it since then.

Nothing I've used since then has actually worked as well as NOMAD for the purpose of generating reports from data. SQL did many of the same things, but not as easily. (And even though it was based on a hierarchical DB, you could do operations that were basically SQL's joins. So it was both relational and hierarchical. Although I'm not sure whether the word "relational" was used in that way at the time.)

And at that time there was talk about how in 10 or 20 years even those 4GLs wouldn't be necessary any more because software would generate itself from specifications. I sure haven't seen that happening. In fact, my personal experience has been that, at least for what NOMAD was built to do, nothing since then has even done it as easily.

But then again, I haven't even heard of the tools you named!! Are they just not popular yet because they haven't had time to reach their full audiences, or are they only used in very specific niches such that they don't have a lot of presence in places such as Hacker News?

I'm aware of NOMAD, fond memories in fact :)

Yes, they are somewhat niche. Mendix got bought out by Siemens, Betty Blocks is an interesting dutch start-up. I came across all three of them in the last year and they've made me re-consider my point of view towards no-code/low code environments, which I used to believe are niche and/or toys. I think they are entering the mainstream and will find a spot somewhere between 'excel' and proper programming (in so far as stringing together API calls is still proper programming ;) ).

We’re not disagreeing. The new batch of no-code/low-code tools may find a niche and help some non-programmers solve real problems. I see that with Excel, WordPress, Shopify, even SalesForce and Hubspot all the time.

I don’t agree that “80% of tech” (whatever that means) will be built by non-programmers in two years. The hype about new tools (or AI) replacing skilled programmers comes around like clockwork because lots of managers and executives would love to see that happen. Programmers are expensive, in-demand (so hard to find and keep) and often temperamental and hard to manage. That part of the dream is bullshit. If these tools do find a niche they can only expand the amount of software out there, creating a larger pool of work for programmers.

Microwave ovens didn’t replace regular ovens and stoves, nor did they democratize cooking for the masses. No chefs hung up their hats and said “game over.” They are a convenience, a shortcut. If you want a real meal you cook or have someone who knows how cook for you.

Mapper - I've still got the t-shirt somewhere :-)

There is an assumption that code syntax is the difficult part about building applications.

For many people this is true.

It may be true that syntax is difficult for some to master, but in that case it's still not "the" difficult part; actually understanding requirements, use cases and implementing logic will always be more challenging.

Perhaps this is a cultural thing, but I'm comfortable saying I've taught at least 250 people to code and absolutely 0 of them were capable of programming right when they had learned just the syntax. For most of those students the difficult part was structured thinking without deviation and carefully stepping through their own code mentally to figure out if they were going to write something that made semantic sense.

I have seen SaaS application owner who was thinking he could do SaaS with low code and cut the costs.

On his place I would be selling "low code" but that guy was severely shortsighted.

I'm sure there are countless examples of this. But even so: there is a vast number of applications out there that are more complex than 'excel' and much simpler than 'bespoke software', and that niche is widening as these platforms become more capable.

I don't see it that way.

In the moment that you want to have multiple users working on the same Excel/Dataset and changing formulas/calculations/rules it is basically bespoke software. Well good luck changing stuff by each employee on their own.

Because there will be appointed one employee who will be making changes for that and as such "Excel" grows he will end up not working on whatever he was expert for but on maintaining that bespoke software.

I don't see low code platforms solving maintenance issue, they promise that you will be able to write code quicker and without developers.

When you get one of the employees working full time on updating and maintaining some low code, he becomes developer. Well you pay him the same salary and you don't have to shell out money for Java/.NET guy but you will pay for license on that platform. While you will be able to hire next Java/.NET dev, good luck finding that specific platform developers. Salesforce if probably going into good direction building their "consultants" base, where I don't see fundamental difference between "consultant" and "developer". Maybe you don't need consultant day in/ day out but they still charge like you would have them hired full time.

In the end I am biased because I am a dev and businnes risks I see are from different side than business people.

But as with Salesforce or any other CRM I see it as a huge lie as the system gets bigger and complex there is no running away from dedicated people doing maintanence. You just tie yourself to a proprietary tool where with Java/.NET you still tie yourself to an ecosystem but it is basically for free and you keep unbounded flexibility.

> I don't see it that way

> In the end I am biased because I am a dev

I agree :)

Unbounded flexibility for one party spells 'nightmare' for another... as with every other tool: use where applicable and don't try to stretch it too much to solve something it wasn't intended for and you'll be fine. Your job is not at risk from low/no code tools. It will simply open up a different class of problems to an intermediate level of automation.

Thanks for agreeing :)

Unbounded flexibility is what most of business people expect. I am always a bit sad when I see the look on their faces when I have to tell them that their great idea is going to cost 5x more because they wanted their previous great idea ASAP/cheap/#timeToMarket and we have to build on top of that.

I just imagine how it must look when someone tells "sorry, it is not possible, because our low code platform does not support something like that".

As someone still in the skeptic camp: what's a good example of a small, effective application that one of those products could help someone to build?

Do ETL[1] and data analysis applications count? There are several pretty good visual ETL and data analysis tools around that let non-coders write pretty advanced and useful processes. Personally, I consider FME (www.safe.com) one of the greatest pieces of productivity enhancing software I've ever used.

That being said, as someone who works with those sorts tools, the quality of the solutions programmers can come up with using those tools tend to far outshines the quality of the solution non-programmers make. There is something about the computational and algorithmic way of thinking that programming teaches that most people who haven't learned how to program have a hard time wrapping their heads around.

[1]https://en.wikipedia.org/wiki/Extract,_transform,_load

>visual ETL

The one I've seen, Apache NiFi, is essentially a giant footgun. Giant, cumbersome, and does not deliver on it's promises - requires teams of engineers to make sure anyone won't fuck up the system for everyone else. And of course, possibilities for data loss and duplication are endless.

One example I've seen up close that was quite impressive was workflow automation in an insurance company. Frequent changes to business models, legislation and customer requirements made flexibility the main driver of their development and the people with the most knowledge were able to directly modify the application.

It wasn't even small, it was quite complex, replaced a very large number of spreadsheets and worked - and works - to satisfaction of all participants. Getting that same system built using regular tooling and processes would have cost that company a large multiple and would not have been nearly as flexible.

In a lot of cases, end users are just providing a replacement for things they did manually, and badly, with emails, spreadsheets, and attachments.

The most common pattern I see implemented is a request, tracking, and approval flow. For things like time off, or borrowing equipment, or volunteering for some duty, etc.

I agree, but there is a kernel of truth here, which is making programming more accessible by means of higher level constructs that are easy to use while also being less general. Excel is a great example, in that it opened up the world of macros and programming to a huge population. Yes, you still need technical skills and programming skills, but the entry bar is lowered in exchange for playing in a tighter sandbox. In many cases, this is a good tradeoff. All the no-code/low-code stuff is just marketing trying to promote this.

The entry bar got lowered back in the 80s with cheap home computers running BASIC. Lots of us learned on low-end low barrier to entry systems like that. There’s no gate keeping. Anyone who wants to learn programming has a wealth of tools and languages and resources to choose from, for free.

This is a replay of previous attempts to pretend to democratize programming and reduce the dependence on rare and expensive programmers. Those are real problems but I don’t think we get there by pretending that anyone can build a system out of software Lego blocks. The actual market here is VCs and C-suite managers looking at software dev labor costs, and misunderstanding (and getting misled) about the reasons for those costs.

Yeah, those basic computers were fun, but having an entry level computer you could write basic programs on wasn't going to help you automate business processes, whereas writing an office macro would. That's kindof the point - to embed the functionality with the data and existing applications, so you can think of these "low code" interfaces built into online apps as the cloud version of those old MS visual basic macros. Except some of these added various drag and drop functionality to graphically add some logic, lowering the bar a bit further.

Well anything can happen. Approaching the end of my career after 40 years programming, I’ve heard for decades (no exaggeration) how low code/no code tools would make me obsolete. For the last decade or two I’ve also heard that AI would be taking my job any day now. I don’t hold my breath. I’ll be writing code until I stop, and I predict that in ten years businesses will have more work for skilled programmers, not less.

These low code/no code tools aren’t useless, but the people who are most likely to buy them are not likely to put in the 5+ years to learn more about programming. If they do they will want to move beyond the low/no code stuff. If they don’t they will be stuck writing macros to automate their business processes, which eventually means the business is constrained by the low/no code tools.

Extending programmability does not make programmers obsolete, anymore than putting better cameras into iPhones makes photographers obsolete. It's just more tools, and it will even increase the ranks of developers by giving them more onramps. A friend of mine started out writing ActionScript and now he's a full fledged developer. These scripting languages and drag and drop interfaces are useful and so they will be used. No one will be obsoleted by them.

I knew a business doing just that with a zx spectrum. Even with the horrors of deafening chain paper printers and software on audio casettes. They had a CRMish application written by a student. They could print their own mailings with individualized coupons. Who cares if it takes a noisy hour in a back room to run.

Don't underestimate what people did with those things.

> Yeah, those basic computers were fun, but having an entry level computer you could write basic programs on wasn't going to help you automate business processes

Yes, it was, and lots of people with those computers and small businesses used them to do exactly that. (And others used them to do the same thing with household “business processes”.)

Translating requirements into code - is about language and tools as you have to learn the language, as you noted "few people wanted to learn to use those". Third paragraph is saying about loads of amateur spaghetti code, so turns out it was not that hard.

So third paragraph contradicts things written in the second.

Low-code tools promise to address "problem of the language" so it is easy to translate business knowledge into the tool. Keep in mind low code tool should ideally be used by domain expert, so another promise is that you don't need business analysts and developers so problems with communication or misunderstanding is removed.

Going back to second paragraph:

Good part that was noted, there were loads of spaghetti apps in Access and File maker, let alone all those Excel sheets that are still everywhere. There was no one to maintain them and low code tools don't provide enough means for maintaining complex systems.

Running and maintaining computer systems is 80% of cost for software, maybe translating it into code is hard, but debugging, fixing, adjusting, keeping operational knowledge is much more expensive.

Silly Excel file that architect Jane was using for 5 years and then she quits, you hire John while you can do knowledge transfer - it is still hit or miss just as noted in second paragraph John will be more comfortable doing his own excel from scratch than learning what Jane did.

Even with developers it is the way that everyone wants to do "greenfield" and understanding what other people wrote before in some unfamiliar system is hard work. Low code even makes it harder to understand existing stuff with their GUIs.

Whole DevOps tooling/movement grew just because of that fact, none of the "low-code" tools is addressing it.

> Translating requirements into code - is about language and tools as you have to learn the language, as you noted "few people wanted to learn to use those".

I'd actually argue differently.

It's more about a design process that requires domain knowledge, technical knowledge and the ability to assess a problem contextually.

Coding is only part of this process.

Keep in mind low code tools should ideally be used by domain expert directly as I wrote in my post.

Designing a software product also requires (software design) domain expertise.

The actual, meaningful goal of some of these tools was to make code (via COBOL, SQL) or at least high-level design (UML) easier to audit and survey for non-technical stakeholders, so that one could check whether requirements had been correctly translated into code. In contrast, many and perhaps most "4GL", "low" or "no" code tools actually make it quite hard or even practically impossible to assess the resulting artifacts. Even MS Excel and other spreadsheets can introduce dangerous pitfalls, including in something as simple as correctly inputing data.

In theory it is of course quite possible to introduce special-cased abstractions, conventions or frameworks that really make it easier to both write and survey software for any given problem domain. As a matter of fact though, beyond existing lightweight software modularization efforts (such as reusable software libraries), such frameworks have tended to hurt rather than help.

> Translating requirements into code is the hard part

I so agree. However, I don’t think that a majority of the new generation of developers would.

Technologies, platforms, frameworks, user and system interfaces, and how to best modify persistent data is what many would say is the hard part. With this viewpoint, the pursuit of automation into no-code tools is much more understandable in my opinion.

My thoughts exactly. I remember the hype around 4GLs and CASE.

IMHO, it's the test/validation discipline that makes the difference. No matter how easy the tooling, the 'test before production' mentality is the barrier that proves necessary to overcome.