The heart of this complaint is essentially that some people think that the difficulty in implementing something is because it requires code, and they can’t write code. “If only I could code, this would be easy”, they think. Code, as they view it, is incidental complexity, not essential complexity.
For a lot of tasks, this is actually true. Take away the requirement to write code by supplying them with a low code tool, and suddenly people can do lots of useful things that they couldn’t before. So in that respect, it’s no lie.
But of course, there are a tonne of other situations, where code is not the only complexity present. Sometimes you’re just trying to solve a big, complex problem. Take away the coding requirement, and you’re still left with a tonne of complexity to manage. And low-code tools aren’t the best for handling that. In those cases, you’re better off hiring developers.
I’ve seen a few people build very complex things using low code tools. Modern ones, but also going all the way back to the original low code tool itself, spreadsheets. People really can build huge things with them. But after a certain degree of size and complexity, it’s more trouble than it’s worth to go with low code tools.
But that doesn’t mean low code tools are useless – they are great for the first set of problems, where the code required is just incidental complexity. You shouldn’t write off this substantially useful product category just because people get into trouble using them for problems they aren’t suitable for.
I work for a guy now who basically picked up some coding in his 30s because he found the previous business team he was on was more successful because of it.
His code isn't great, but he can express what he wants in giant SQL blobs and then we can build scalable solutions against basically his mockups. He can also unblock himself for a while with his own code while we build the real production flavor, etc.
It's great because he is basically expressing his requirements in something that works.
I think just like the coders should learn the business they work in, if the business learns some code.. everyone can be a lot happier.
In the low code context I think if you can all agree to treat whatever is generated there as throwaway prototypes, then it can be a value add. Ie - instead of writing a 20 page document, I'm going to show you something that sort of works here.
The pain comes from people thinking its going to replace developers, getting stuck, and then forcing the developers into the low-code tool too.
In these scenarios these low code tools feel like the evolution of excel. How many times did people who couldn't write full on apps throw something together with some excel formulas to do a version of what they needed?
At a previous company, where we developed and built medical devices that were not just a toothbrush, we couldn't install or build any software that did anything that made almost any decisions about the design or production of the devices. In other words, we were stuck using Excel spreadsheets to make decisions then we had to validate the decision and sign off on it as the human who was deciding. Basically, we could build prioritization and tracking "software" out of spreadsheets, but anything other than that, such as the software used to log inspections, had to go through the same process our medical devices went through in order to be used for the design or manufacture of the actual devices. Excel was an absolute life saver there for at least the stuff we could use it for!
Yup. The rule of thumb I learned was that at a FDA regulated facility, "anything that touches the product" is regulated just like it's the product. And when the FDA audits a facility, they focus primarily on software.
Yep, and for one spreadsheet that prioritized some work, we had to show the FDA that the spreadsheet didn't materially affect the devices we were manufacturing. Basically, this particular one just told us which lots of goods to inspect first, so at worst case it would have just slowed down our line, not affected the device's quality. We still had to take 1 hour to walk some inspectors through our use of it, and why it wouldn't fuck things up.
I also started a project to upgrade some software from some old in-house developed stuff to an SAP module (gross, but effective) and it took about 18 months just to make the development and rollout plan, since it was incoming inspection software so it was super important to get right. I left before I saw how long it took to develop, but I think that's the easy part of the whole process.
I don't think I could do FDA software, it sounds so painful. Same with voting machines that are properly regulated (had a CTO at one point who previously did that sort of work and he had stories to tell). Fintech is hard enough.
This was (and may still be) the foundation of tax software: domain experts in each province specifying tax formulas in a spreadsheet with an interpreter that takes those formulas and translates it to code libraries in Java, C, C++, etc.
I honestly believe everyone working at a tech company should know or learn how to code even if it's just SQL or basic Python.
I'm more than happy creating some views in a SQL database and give business people access to a read only replica instance so they can do exploratory work on data without much involvement from engineering. I've seen so much developer time spent on generating reports for the business which takes time away from feature development.
And sure we might complain about data scientists handing us spaghetti jupyter notebooks or business analysts giving us rube goldberg excel sheets to productionize but I vastly prefer that over them telling us what they want in words. They are POCs and prototypes. It's fine if they are messy.
So if low code tools are thought of in the same vain as excel or jupyter notebooks, they can be pretty darn useful.
> I honestly believe everyone working at a tech company should know or learn how to code even if it's just SQL or basic Python.
Why? They should already know the native language like English in the US, which is perfectly capable of describing a problem. Unfortunately, many people are poor at communicating in the native language, which is a more fundamental problem. However, how does learning another language like Python or SQL make this any better, if they are unable to use their native language sufficiently?
While I agree that English or any other spoken language is sufficient to describe technical requirements, many people have trouble communicating what they actually want because the language itself is very forgiving and so there is room for misinterpretation.
At least with a programming language, which is more precis e and limited and what you can express, you are forced to think more precisely the desired logic.
I've taught and gave workshops to business people on programming and database query languages for data analysis include non-SQL ones like Mongo. And I can say that those that took to time to learn the query language communicated more effectively because they can send over a query and then use English to give more context, mostly around the presentation layer.
Yep, I'm working with a guy on the business side who is amazing with Dash. It's the best example of a skill set being greater than the sum of its parts that I've seen.
The problem with throw-away prototypes is that often don't get thrown away and become the actual system. 'Hey it works, mostly, why spend money improving it?'.
I spent a couple of years not that long ago basically wrapping a proper production system around a low code system because it had grown so complex by the time I joined that trying to just do a rewrite was not feasible in a reasonable amount of time given our small team. Instead we built two-way sync of the data and built new functionality in a proper system and gradually replaced function by function when we could justify the time cost.
This articulates well something that's always been in my mind - code is just a precise expression of business logic. Programmers are actually business administrators making low granularity business decisions.
You could make programming less complex but it doesn't obviate the need for making those low-granularity decisions -- you're just choosing to go with the "defaults".
I understand your point, but I really intensely dislike the term "business logic" when used as some sort of universal. A bunch of us write code that nothing to do with any "business logic", even if there is some other sort of set of workflow rules & design that need to apply.
I write a DAW, and we face two major fundamental problems:
1. most DAW users don't use many features, but they do tend to use different sets of features. So if you want to be useful to lots of users, you need a LOT of features.
2. the corollary of (1) is that there are, unlike in "business logic" applications, oodles of workflows in use, and the application needs to support as many of them as possible without friction or bugs.
It's true that it's a bit of an expansion of the word "business", but it doesn't really mean "something to do with commerce". It's just the parts of the code that handle the rules of the system that directly enable the user's goals, and not any of the auxiliary, supporting infrastructure. So for a DAW business logic is pretty broad, true, but it would be stuff like, faders or muting a track and the effect on the mix, whether you can copy-paste a snippet of audio, and routing audio through plugins. And not things like the file format of a project, or the code that interprets hardware interfaces.
I mean business logic in a very broad sense. You have your DAW and it does something. That's the abstract model. You could define what it does in a high-granularity sense (point 1), but you also need to define what it does at lower levels of granularity. What you define at those lower levels is still part of the the abstract model of the DAW. Hence it's "business logic". Whether you use a while-loop instead of a for-loop, that's not business logic but an implementation detail.
Programmers make a ton of "implementation detail" type decisions but they also make a ton of decisions that affect the abstract definition of the thing, and these I define as "business logic".
The point is there isn't really a "thing the program should do".
If you compare to e.g. some sort of data entry or data analysis UI, you can describe the process the user is intended to follow, and that defines your "business logic".
With creative apps, this "process the user is intended to follow" doesn't exist. We're not implementing the rules of an employer or a company, we're providing open-ended workflows for people who don't know what they're doing.
It's still "enter data/modify data" along with suitable UI/ux and views to enable that.
Of course a DAW can probably be viewed as a low code tool for programming sound - so implementing a DAW is more similar to implementing a spreadsheet - than using a spreadsheet.
Still, the user has a goal, a process of achieving that goal - and the software needs to support the process and achieving that goal - eg output a track.
The fact that there are many users, with different goals and processes - doesn't mean that it's not "business logic" both to "crossfade" and "shift pitch".
"Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values.
This doesn't apply to creative apps. Do this then that, or that then this, or the other and then that and the other other, etc, etc.
> It's still "enter data/modify data" along with suitable UI/ux and views to enable that.
While I agree that this is technically true, I'm not sure anything useful comes of viewing things in this way. Undecided, but doubtful.
> Still, the user has a goal, a process of achieving that goal
This just isn't true. Talk to creative people. Even someone doing a task like audio mastering, which is not particularly creative, doesn't begin with a goal. Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish. That will change over time as they work on a piece and the process coalesces into "I'm trying to ..." as opposed to the earlier stage of endless "let's try ..."
> "Business logic" normally dictates the relative ordering and contextual legality of certain operations and data values.
Wikipedia gives the following definition for "business logic"
> In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.
I (and i believe op) lean on the "domain logic" end when talking about business logic.
So the fader toggles bits in the raw data, but in a way that input and output is sound data that can flow through the application. Your DAW needs both the bit fiddling - and the "flow input through the fader and out to file" parts.
> Musicians typically have only a vague idea, if they have an idea at all, of what they are trying to accomplish.
I'm talking much more abstract here - "improve recording" is a goal - there's a current domain state, and the goal is to modify it in some way. I'm talking about user intent in interacting with the domain.
> ... determine how data can be created, stored, and changed.
So you can record sound, store it in a "track", transform it to "mono" etc?
> ... It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.
You might store the sound as a wav, export it as an mp3 - the undo tree might be in SQLite...
Ed: might make more sense with the term "domain"; domain logic, domain rules.
Ed2: somewhat tangential, but see also the original model-view-controller-(user) paper - the user holds a mental model of data/objects in the domain - and the application holds raw data in ram/disk - the UI needs to bridge these two domains so that a user can "apply reverb" from the domain concept to the actual data model (modify a wav file).
this is a failure of abstraction. over time, the platform detail handling gets separated into the runtime (for example memory management, now cloud provisioning, my startup is a language that abstracts distributed state). the reason we get ahead of the abstractions is that software is so valuable that we will spend $100M to bring a product to market by force of capital and its worth it because historically the winner takes most, this is just economic imperialism/conquering and barely a level removed from physical violence. it is sad actually how self interested we all are, imagine the world if we could figure out how to cooperate!
Sometimes writing a full web application is the right solution, other times you just need a database with a front end and a low-code solution is best, other times an excel spreadsheet will be the right solution, and other times just physical process change is best.
>other times you just need a database with a front end and a low-code solution is best
Until you need it to do something slightly beyond its capabilities and then you are trapped with an app that needs to be rewritten with data that needs to be migrated in order to implement one small feature.
That's the same thing with all technology choices though - if requirements change substantially you always risk a rewrite. If write a full-code application with all your logic in server-side .NET and suddenly your users have a requirement to use it offline, and then you are trapped with an app that needs to be rewritten with data that needs to be migrated in order to implement one feature
This is all part of having a good level of intuition for what capabilities you are likely to need, and then picking appropriate technology.
There is a vast difference between the things which are blocked because youre not using a turing complete programming language and things which are blocked because of the nature of that language though.
You'll probably run up against the former quite quickly. The latter possibly never.
The problem is someone elses toolbox, who often isn't an engineer, when that someone hits the limits of that shiny, sparkly tool he put in his box.
Because at that point, software engineers have to figure out how to interface some extension with that thing. Which may be easy. Or it may be next to impossible, because the tool usually doesn't have things like version control, standard interfaces other than outgoing HTTP (if it even has that), compatibility with common IDEs or the ability to unit test. Bonus points if it doesn't even store the box-and-line-diagrams in something vaguely grep-able like XML, but uses a proprietary binary format...or stores them on the vendors servers making them completely inaccessible other than through the vendors interface.
Right tool for the right job? No problem with that. If it "empowers" someone to do something he couldn't do otherwise...great, full support.
But as soon as someone wants me to interface my toolbox with it, I will demand that it offers the same qualities that I expect from every other tool that I use. Because these qualities aren't arbitrary, they evolved over decades of hard earned lessons in software engineering.
I completely agree with you and this is the crux of it. Even if you know how to code, there situations where a nocode tool (like retool) is the best tool for the job
>some people think that the difficulty in implementing something is because it requires code
On the contrary, being forced to clarify your thoughts under the constraints of a formal language, and be able to execute and test them, helps tremendously to figure out what you actually can do and want to do, even more so when the problem is complex (and excluding already well understood tasks).
also going all the way back to the original low code tool itself, spreadsheets. People really can build huge things with them. But after a certain degree of size and complexity, it’s more trouble than it’s worth to go with low code tools.
The problem with spreadsheets is that they end up with 5 lines of formula code wrapping over a fullhd+ screen. If it was a regular code, which isn’t hard to write at all, they could grow much further and get help from professional developers. When I see that 5-line formula, I say “sorry, you have to figure it out by yourself”.
What low-code should actually be is what we called RAD back in the day. Excel is a good idiom and a platform for doing things. But its language actually sucks. What regular people are afraid of is boilerplate and wheel-engineering, not code itself. I disagree with the second paragraph. Most of our “starter” complexity is highly incidental, in a sense that we always start in a forest, cold and naked.
Google Sheets is of course a little more than Excel, but the fact that large sites are still going this route and seeing success is legitimately impressive.
For me, people get mislead that 80% of the work only leaves 20% to go.
You can use any platform, language, tools, paradigm and it will not be enough because software development/engineering is solving problems
Back at the start of my career I didn’t know how to code, but I got offered a role at a startup after I came up with a solution of integrating google cals in a way that was crucial to the business - using Zapier. (The requirements were complex, but Zapier could handle it)
This was after the outsourced dev team that built the company website said that it wasn’t possible without significant cost. Here comes me, not knowing how to code, pointing out a solution that cost a few pounds a month.
During the next few years I built a ton of other solutions for the company using Zapier, to the point where we were running over 50000 tasks a month, easy.
I learned how to code in the process (I now work as a software engineer), but I always consider low-code or no-code solutions when problems arise, because I’ve seen them save massive time and expense in a real world scenario, and working really well.
It’s like the OP said in the end - we are problem solvers, and I would add that low-code/no-code tools should be part of your tool chest. Your decision as a problem solver regarding when and how to use them are crucial to whether they work or not - but I wouldn’t dismiss them outright.
I often try to do the same thing.
But usually end up regretting it.
From these experiences, both the successful and the failed ones, come a few gripes against most low-code / no-code tools.
To name a few:
- Often poor, or completely absent, testability
- Often poor, or completely absent, versioning
- Conflating “saving” and “deploying to production”
- Lack of environments
- Often sorely lacking, sometimes poor, debugging tools and visibility
- Ridiculous choices (looking at you, Zapier and your absurd handling of JSONs and arrays of objects)
- Poor reusability
- Poor collaborative features
It is my understanding that for some products some improvements have been made on some the aspects I’ve mentioned.
But it also feels as if those behind these tools have completely ignored the progress we’ve made in software engineering best practices over the past 20 years.
Often just getting it kind of working is good enough. I don't like these solutions as they don't really give me full ownership of the problem space but I understand why people use them
There is also a danger in relying on a third party tool for essential business processes.
If the third party tool makes changes and breaks your solution, or gets sold to an unfriendly owner that jacks prices, or decides to sunset their tool — you're screwed.
And the person who established their bona fides integrating that solution wants to preserve the resulting status, so you'll hear some variation of "I don't think that will happen, but let's cross that bridge when later".
What are low choice options when it comes to serverless functions?
For example I make static sites and there's always times when I want to use an API that's either blocked by CORS or requires the use of an API key. But I don't know how to setup a server or how to deploy AWS serverless functions and I really don't have any interest in learning.
I'm working on a product right now that targets this exact use case. I have contact information in my profile, I would love if you would be willing to reach out and just talk to me about your use cases. I already have a day job at a tech company, so I promise I won't try to sell you anything, ever.
Programming tools have a continuum between power and simplicity (or, lines of code, or developer efficiency). You wouldn't (couldn't) write a device driver in Python, but you also wouldn't want to develop a dynamic website in assembler.
Low-code tools are a level beyond high-level languages. They are particularly useful where they are domain-specific, and offer focused functionality that makes them more effective for certain applications. Additionally, commercial low-code software can offer batteries-included solutions that you would have to pay for anyway.
As an example, my company's product is a low-code platform for pdf workflows in finance. The language allows for rapid implementation of form workflows, including validation, pdf manipulation and e-signatures. It also includes features like sso, api integrations into obscure financial databases, whitelabeling and various tailored user and admin interfaces.
Could you build arbitrary form workflows with a web service like RoR? Sure, but it would be a much more complex and expensive project, and you'd have to pay for a docusign API license anyway.
I checked out Outsystems that the OP mentioned, and it seems like one of these more generic all-purpose services. I don't really think you can square low-code with all-purpose. The lift in efficiency you would get is stunted by the requirement to maintain the power to handle too many use cases. If you need to support every single industry under the sun, you can't focus on really good deep native API integrations, or you'd have to charge so much money you lose your value proposition.
Interesting - in my head then for each industry there is a space for reusable code components that tackle certain industry needs - either OSS or prop - and that are so standardised that it takes one dev one day to put them into useful action.
I think what I am saying is that good low code solutions are pre-packaged fixes to well defined common problems - and it's not that important if they are glued together with Rust or a drag and drop UI
We do a lot of thinking about the place of low-code or no-code in the industry.
We're intentionally low-code, for example, because we think the accessibility gained by a no-code (graphical programming) interface isn't worth the tradeoff in loss of power. (A lot of people, like some tech VCs we've spoken to, think "well if low-code is good, no-code must be better" without realizing there is a tradeoff here.)
We don't really see any clients deciding to roll their own solution because the value prop of low-code for forms is so dramatically superior. We do end up competing against other low-code platforms like Pegasystems or Salesforce.
Low code software development is not a lie -- it's a trade-off.
You gain (a) canned components / patterns for rapidly performing common tasks, (b) opinionated design that encourages one particular solution, (c) support for any issues from the underlying stack.
You lose (x) open development ecosystems, (y) general purpose flexibility, (z) ability to evolve a tool however you want and fix your own issues.
Given the above, when does low-code make sense?
When you have a common business use case, that happens frequently, and you'd prefer not to train/retain developers to deal with it.
Generally, the dominating value of low code is directly proportional to how much of your use case the canned functionality solves.
Some examples of where it's a good fit: application-application automation (provides interface glue and exposes higher-level actions), CRUD app generation (uses common design patterns to build everything the user doesn't need to change), data flow (allows the user to declare what should happen, then generates the how).
If you find yourself hacking functionality into a low-code tool often or substantially, it's inappropriate for your task.
If you're trying to use low-code to deliver a core business competency, it's inappropriate for your business.
Use it for the boring and less important stuff, that's not worth developer time. In the same way that businesses rent instead of buy carpet (because it's not a core competency), most businesses shouldn't have full in-house development teams to do ancillary development tasks.
Source: worked in UI automation for a decade+ and watched customers and the industry
As an additional point - If I have an entry-level clerk who does 2 hours of work per day that could be automated by putting a dev to work on building a solution for a month or two, it won't financially stack up. I also don't really want to pull that dev off to work on that, because I could probably have them working on better stuff.
If we could build something a bit more scrappy in a low code tool in a few days and pay $40-$80 a month in licencing, that will stack up fast. Will it be as good as the full-code solution? Probably not - but we weren't ever going to build that solution anyway and it's better than nothing.
It's a simplistic example, but there are categories of problems that low-code can solve which full-code can but won't.
Low code is actually pretty dominant in the data integration space. Tools like Fivetran or Zapier that provide point-to-point integration of structured data from a source to a target with some rules for scheduling, filter and transform. If enough people need to move customer data from Salesforce into Snowflake it eventually just becomes a platform.
There are exactly 2 types of lowcode environments:
One is so complex, and allows the user so much freedom, that it is a fully fledged programming language.
The fact that it requires me to shove little boxes around in an interface may make it better for some domain specific task, idk. What it certainly does, it makes it next to impossible to integrate in any standard IDE, usually doesn't play nice (if at all) with version control, and searching through code becomes a game of "Where's Walter?".
The other is so simple and obviously shoehorned to perform a narrow set of tasks, that it is almost, or completely, impossible to do anything else with it.
Which is perfectly fine right up to the moment where the user needs to do something the framework didn't foresee, and suddenly engineers are asked "can we integrate that? we only need one small thing...". Which the framework, being ~narrow and prohibitive~, excuse me, focused and streamlined, usually fights tooth and claw, but engineers somehow get it to work anyway. Until the "one small thing" becomes many small things. And some slightly larger things. And the occasional big thing. And then those same engineers need to rewrite the whole thing, which would be fine, had it not been first "implemented" in the glorious "lowcode/nocode" environment, which suffers all the problems outlined in the first type, so we spend countless hours unpicking a pile of spaghetti made from colored boxes and lines, and the complexity the framework shoved under the rug, to figure out what that thing was supposed to do in the first place.
This is the reality of low/nocode environments. And it baffles me to this day, that this idea, which isn't new btw. (it existed under different names since at least the mid 80s), keeps popping up and dominating headlines every few years.
That's one reason I refuse to consider low-code environments that don't have a well-modularized and standard-following escape hatch to an actual program language.
As soon as you start writing custom modules, it should always be in a general-purpose programming language.
I have an Enterprise story on this. The low code tool I was using increased the price x10 on me after the first 3 years. The price increase was poorly managed, they looped me out and tried to talk directly to the IT leadership which was a disaster for them because they had 0 experience handling Enterprise contracts. I don’t think these low code tools are worth the trouble of dealing with their inexperienced sales people. Maybe some low code tool companies are better, but I am done with them anyways. Most of these tools promote bad coding practices like no clear split of dev and prod, no version control, no testing. I am not sure if these low code companies know what they are doing and how complex it is to maintain an enterprise app over 5/10/15 years.
Not the poster, but Microsoft Powerapps had a massive price jump a few years ago, followed by a pretty large decrease last year.
Through the grapevine I have heard the same about Mendix and Outsystems - in my company we found that hiring internal developers is cheaper than paying the licenses at scale. (About a 10k employee company)
It may work for smaller depts and apps, but Retool or Airtable is often sufficient for these teams, and much easier for non-developers to learn. We do use Appian and Pegasus for some smaller depts.
In terms of Unreal blueprints they may be low syntax but they are not low code - you still need to know software development techniques or you will end up in a pile of garbage very quickly (which you can also do with any other language).
What is required when using Unreal Blueprints is game development domain knowledge, which makes sense for all those tools, doesn't make them less no-code.
To use Houdini effectively, you need to know vfx and a bunch of other domains, just like you need to understand shaders if you're gonna use the shader nodes in Blender.
All of those things can be achieved with coding as well, and that's the difference. One you write code, the other you don't. Both are backed by code, obviously, but it's hidden from the user but usually extensible by code.
These are low-code tools that are specific to a particular domain. And I think low-code tools can add a lot of value here (I work on a low-code, boxes and arrows, tool for data transformation). Where things fall apart is where low-code tools are offered as all-purpose tools for solving any kind of software problem. Especially when they are over-sold by salesmen eager for commission.
Can't speak for game development but in film (specifically VFX) the coding side can get rather involved. In a large studio your pipeline will hinge on dozens of in-house Python scripts or even tools in their own right. Often they'll have their own data access logic for working with databases, asset management tooling or production data APIs. That they're loaded as Maya/Houdini/Nuke plugins is incidental at that point.
It's no coincidence that your most effective TDs will also be strong coders, and that some may even come from a more traditional software background.
Yeah. I think the strength of these kinds of tools is they allow you to separate your team into one that is fluent with code and one that isn't, without the "coding team" spending time on building a GUI for the "no-coding team". Houdini is probably the best example for this cause it has a built-in "interface builder" (the parameters panel for HDA).
To hell! I'll throw myself to the lions. I make "Low Code" software and I think it's useful. It allows anyone who knows SQL to build real-time interactive HTML tools:
https://www.timestored.com/pulse/tutorial/pulse-interactive-...
These people often only know SQL, so can't write javascript/html/react. The example video shows allowing them to create a live updating table that when clicked, draws a chart for that row. The best use-case is for prototyping many more apps than would be possible if they had to run every idea past a UI developer. Eventually some of those ideas get taken to full production based applications, many don't.
I'm open to any and all feedback. If you think it's useless please say why and if you think there are better tools, well I would appreciate that feedback too.
Fellow lion pit enjoyer here. We also use SQL for our product to deal with all the client customization needs. This has been our path for about 4 years now and we still haven't found a better option for our business.
If you build a SQL schema and involve the business stakeholders in that process, you end up with something everyone can understand & work with. The difficulty of writing SQL scales in direct proportion with the complexity of the schema/domain. If the schema is something that is fundamentally familiar to your team, then you already have 80% of the "language" trained into your employees. At this point, showing them a few examples is all they usually need to "get it" and start doing things on their own.
Inevitably, you will run into "how do I write a query that answers 13 questions at the same time and arrive at 1 final binary choice", and need to babysit with decomposition & CTEs. But even with some examples of those the team can begin to take matters into their own hands.
In my experience, the joins are the hardest part. If you can, organize your problem such that even very inefficient nested queries can complete in a few milliseconds. We do things like run SQLite in-memory to achieve this outcome. Allow the team to do lazy crap and get shit done. You can always iterate the queries for quality later on - I think an LLM does this for us in our near future.
Note that SQL is not no-code. You could say it is low code, but still it takes a "coder" to develop and debug it. It is a text-based format not GUI-based.
Prototyping -- and the code generated for that purpose -- needs to be distinguished from production-quality processes and deployment artifacts.
This distinction (which is blindingly obvious to experienced engineers and product owners) is blurred or elided by most of the no-code / low-code sales and marketing materials I've seen.
Your example of dynamic charting for data tables is useful; analyzing the performance characteristics and featuresets of enterprise-grade datagrid solutions (eg Ag-Grid, Bryntum) the chasm between a shallow one-off prototype and a properly-extensible and maintainable solution becomes more evident.
Ignoring or attempting to bridge that gap with insufficient diligence leads to catastrophe.
TLDR I think some of the hostility towards low/no-code tools is less "it's going to take my job" and more "it's going to make a royal mess of things in the hands of people who don't understand".
The problem with Low Code is that it isn't No-Code.
If I have some problem that I can just jam into IFTTT and leave it forever, I will do that and be very happy.
If I then need to do something that requires changing the setup, I am coding. Suddenly I have to think about the requirements developing in the future, where to keep the repo, how to deploy it, how to change dependencies, having someone look after it.
The lie in low-code is that the first thing is like the second thing. If you aren't a dev, I can sell you a thing pretending it's the first thing, and then you are stuck with all the issues when it morphs into the second.
Excel is perhaps the best example of this. You think you don't need to understand coding, because how hard is it to wire up some cells? Time passes and you have a bunch of VBA scripts and DLLs hooked up to buttons on your spreadsheet, and it turns out things were a lot more complicated than you thought.
This is what I call "Bayesian software" - it will get you quickly to 70% of what you want but getting 100% of what you want is a game of diminishing returns. For some companies 70% solutions are ok and it's a tradeoff in terms of functionality vs cost which everyone has to make.
The reality is that a lot of software engineering is moving into the 'low code' space even if they don't call it that. This is part of a general strategy to sell B2B services (like cloud platforms or cloud tools) where engineers aren't really developing solutions from scratch as much as they are configuring tools provided to them via a B2B sale. Is this software engineering? I guess it's debatable but it's clearly not 'applied science'.
I see this as a general trend in any craft - craftsmen get displaced by cheap industrial alternatives (like plastic chairs vs actual decent chairs made by a craftsmen). There is no argument that a handmade wood chair made by a craftsman is better, but for many consumers at the bargain store, they want cheap plastic foam-injected chairs even if they are poorly made and break. Does the argument hold that these cheap alternatives are "more expensive" in the long run? maybe. It depends on what you're doing with the chairs.
I think one serious downside to 'low code' solutions is the brain-drain on new devs. I see so many engineers that don't understand basic software architecture because they've spend their career configuring B2B tools. Overtime this model of software will cause us to loose core CS skills.
Custom software development could learn a lot from the "visual programming" part of low-code development.
I find it odd that we design and understand our software as diagrams on whiteboards, and then we just maintain this big ball of text.
Everyone thinks they are writing clean code, but most projects require huge amounts of time spent poking at it to figure out what the actual core business logic is.
I think the future of programming is two-way sync between visual and code, where every piece of code is visualized in a graph. I want to open a project and see the function call graph, live annotated values from different code paths, and a data dependency graph of how every value in the system responds to events and user interactions.
A few weeks ago I just started building a product that accounts for that new paradigm. So far its just a bunch of R&D, miro diagrams and blurry thoughts. But on a high level thats my goal: bring more visual to coding together with some of the best software engineering practices like interfaces, cqrs, event sourcing, microservices.
I want to enable users to switch the level on which they are operating: no-code, low-code, pro-code, at any point in time. This will allow bringing together all of the stakeholders into the same tool. This should allow them to move quicker, reduce need for alignment and give everybody a way to particupate at the development stage.
Would be great to get in contact with you and poke your brain a bit about this problem and see what you think about it!
Agreed. If we take a step back from the day-to-day and our own
well-worn opinions, the fact that we debate issues like whether a language uses curl braces or indentation or semi-colons or not is somewhat comical.
Ah, management’s never ending dream to commoditize software development; gotta love it. I’ve spent the last several years being paid good money working on various failed “digital transformation”projects and am currently working on another one I predict will fail.
One of the root causes of these failures is viewing the actual software development as a mere afterthought once all the high level boxes are drawn and power point slides created. Tremendous resources are spent on everything ancillary to the software and insuring proper adherence to process is kept no matter how orthogonal that process may be to maximizing the delivery of quality software in a timely manner. It’s really quite amazing.
I make a great living cleaning up the unholy messes made by low code projects! I'm doing one right now that took me a month to convert a project that had been grinding to a halt for several years on one of these low code platforms.
My customers are thrilled I can knock out a couple "impossible features" in a day because the data is now stored in SQL and not some UI driven monster web based "database" with no formal query language.
Another commentator likens these tools to mass produced plastic chairs, but for me, it's more like a plastic car engine that just melts if you go more than 15mph or you try to carry more than one passenger. And these engines are being sold to trucking companies, taxi companies, and food delivery companies. Sure those plastic engines are really cheap. But good luck when you suddenly are carrying more than a few sandwiches a few blocks away.
I've been on this kick for a while now and the pithy version I've come up with is this:
The central conceit of low- and no-code tools is that the hard part of programming is typing code.
I have never liked the term "coder", but it has taken a while for me to be able to articulate it. What it comes down to is this: all coding is programming, but not all programming is coding. Programming is, in very broad strokes, making the computer repeatably do something for you. Coding is typing code.
Some examples: spreadsheets are programming. Yahoo Pipes back in the day, ITTT, Zapier, Microsoft Power Automate and all the rest are programming. Shell scripting is programming. Also, using any of the typical programming languages is programming.
With this understanding, low- and no-code tools are obviously programming. They just involve writing less code (if they are doing their jobs correctly). This helps to understand them.
If the solution domain's implementation is riddled with boilerplate, then this sort of tool can be a boon. There are plenty of instances where this is true.
As the solution domain's non-boilerplate portion grows, the value of low- and no-code tools rapidly drops off. This is because -- pretty much universally in my experience -- these tools, ironically, make the act of writing code very nearly as hard as it can be. These tools, designed from the ground up with the goal of minimizing the (perceived) pain of writing code, make writing code so very difficult.
So, as others have said, it is important to get tool-problem fit. And understand what it is you need to program. And if that programming challenge fits into the box that a low- or no-code tool constrains you to.
Because it might not be coding, but it is definitely programming.
Having worked professionally with low-code tools, low-code is just coding but with less expressivity and worse ergonomics.
In layperson terms, you're still implementing the same logic - just that now you have less flexibility and precision to implement exactly what you want (expressivity), and the UI/UX is "clunkier" than if you just wrote some code in an IDE or text editor.
There are also a few other problems that are prevalent in the low-code ecosystem but not fundamental to it:
- not having good version control
- not being able to port what you built (vendor lock-in)
- not having a good way to collaborate
These are very powerful things that we take for granted when writing code in a version-controlled repo.
> It is actually the result of clients and developers not taking the time to understand the root causes of the problems they want to solve
i certainly agree with this. it seems weird to me that the job title "systems analyst" has disappeared frpm the job market (speaking as someone that used to be a "programmer/analyst") and has been replaced with ... nothing?
I agree with that statement, but disagree with the conclusion ('because of that no-code solutions are not useful').
The benefit of low-code is that you can spend more time understanding the root causes of the problems, and be able to quickly prototype solutions that match the user requirement (and that you can make changes to more quickly) than would otherwise be possible.
Of course if everyone had infinite time, we would build full solutions for everything, but in a world with limited time and resources these tools can have a great place in the toolbox.
"A programmer whose salary depends on being an unsurmountable middle man between boss and machine, declares that solutions for surmounting him are a lie." - The Onion, probably
There are a lot more middle man then that, a lot of CEO and CTO i've met had an almost active disintrest in anything technical or even practical knowledge of there product, not knowing the priorities is in there own backlog or not knowing what an init system is or does but ask you how to start a process when a computer starts. Unbelievable what people complain about in meetings without having googles that problems in MONTHS. Most people just secretly hate technology and will grasp at anything that gives them an excuse not to care.
Even in a world where e.g. LLMs become capable of producing relevant, consistent, and accurate code by description alone - there will be programmers. The person hiring a programmer is not doing so because he himself cannot program (though this may, incidentally, be the case), but because he has other things that he would prefer to dedicate his attention and energy to. When you hire a janitor, it's not because you are incapable of sweeping and mopping. And by BLS numbers [1], 1 programmer is currently equal to about 4 janitors in terms of cost, which is pretty reasonable. So I doubt this calculus is changing anytime soon.
You do realize that low code solutions are actually the middle man between boss and machine here, don’t you? This is like comparing Node and Drupal and announcing that Drupal is the superior technology. Ick.
I've upvoted this because it's funny and mostly true. However, the outputs from no-code and hand rolled are not equal. It blurs the distinction between custom and off-the-shelf. With no-code representing something closer to the latter.
There's a lot of money to be made in first trying to customize an off the shelf solution, then trying to replace it with low code one and finally implementing a custom one.
Sure. Yet any no-code derivative is therefore stuck with a general-purpose implementation. Which admittedly is fine in many contexts.
However, the distinction is important. You "assemble" no-code. You cannot buy a dog puzzle and reconfigure it to be a cat puzzle. IMO, this is the inherent limitation of a no-code toolset.
Also, users are handicapped by the developer's capability. That is to say, the efficiency and specificity of the tool's internal codebase represents an invisible glass ceiling for its users.
Very nice article, as an experienced software developer I feel this to the bone. I also feel the same applies to all-in-one cloud platforms aka fire/supa/megabase, which are promoted to an extreme these days. It enables fast-forwarding system design decisions and getting something running quickly. It lowers the barrier substantially, but configuring and using it in the right way – from the good data model to safe and secure so-called cloud functions – takes the same skill and time as setting up your own custom solution for your problem using a handful of open-source Docker containers, the compose file and a VPS. Of course, it requires you to be more mindful and aware of what you're building, as well as to subscribe to the requirements of your problem more deeply.
I'm of the believe that low code is for small and low complexity software. Often I find myself wanting to do something that is relatively simple but it needs to be done many times. I often have to weigh the complexity of writing a script vs doing it by hand. Let's say it takes 2 hours to write code vs 1.5 hours to do it by hand in some situation. Low code could make my decision much easier if, as it promises,writing the code took less effort. But I don't think anyone would pick it to write complicated and long code. I think it has its place as a code writing tool.
The big issue to me, and the article's author, is that you are locked into whatever tool you use. That and the never ending subscription makes it a very unattractive choice for any project no matter how simple it is.
A few effective counter examples I can think of, off the top of my head:
- the Apple Shortcuts scripting framework built into iOS 16 and above,
- gnuradio - a block based signal processing environment for software defined radio
- Scratch - the learn-to-code block language that’s evolved into its own programming environment
I suppose you could call these programs’ no-code premise “a lie” based on the premise that all of them have text based code under the hood.
But I also realize you can rebut that pretty easily by saying that the graphical flows can address a lot of custom functionality required by their user bases.
Speaks to me of those programs solving problems with a relatively well defined set of constraints.
I wouldn’t describe current web apps, and the rich frontend functionality required, as meeting the criterion of having a “well defined set of constraints”.
Apple Shortcuts is just rubbish shell scripts with an excellent GUI. Scratch is certainly a programming language: it even has a textual representation. https://en.scratch-wiki.info/wiki/Block_Plugin/Syntax. I haven't used GNU Radio.
Some of these "no-code" systems aren't programming languages, but the examples you've given are definitely programming languages. They've even got their own Wikipedia article (https://en.wikipedia.org/wiki/Visual_programming_language) which lists GNU Radio (though it also says behaviour trees are programming languages, so I'd take it with a pinch of salt).
My day job is security engineering, and I just keep encountering the same problem over and over again: the code is the easy part, it's all the other shit that sucks. I don't want to write a bunch of terraform, set up a CI pipeline, and have to justify why I haven't updated a docker container's dependencies in like 6 months. I just want to write a little Python and make it available on the internet somewhere. Why is that hard?
I'm working on a side project to basically make the tool I wish existed: https://integralcloud.io
If you have a use case that you are willing to talk to me about, please reach out (contact info on my profile). I won't try to sell you anything, ever. I just want to hear about business use cases and try and make something people want to use.
Nonprogrammers used to use FrontPage or Dreamweaver to develop websites. Now they use things like Google Sites or Wix for that matter, which works well enough for a lot of individuals and businesses. This is a real thing that has been happening for decades and is not a lie.
> I've been writing custom software for a long time and one of the things that annoys me most is when a client adopts the position that there is a silver bullet which will reduce or remove the inherent complexity of this task. This happens more often than you'd think and guess what? They are almost always wrong.
I concur. It's not new, either. I have been writing software professionally, since 1984-5 (depending how you define "professionally"), and have heard this claptrap since Day One. I'm sure it was around before I was in a position to hear it (tree, forest, sound, etc.).
AI will generate the same BS, until people figure out that those skilled in writing really good prompts, get much better results than your average C-Suite dork.
> Designing a solution worth a damn is actually the most difficult part of the software development process. Low Code tools lie to customers by implying that the writing of code is the hardest part.
I don't think there is a lie here. Writing 'production-grade' deployed code is the hardest part for people who can't code, but that do understand processes and how to design them.
There are plenty of people I have come across who cannot write code, but who are still intelligent and could design a robust process.
This is the benefit of low-code and AI tools: liberate the ability to develop software tools to people who are capable but don't want to spend years learning to program.
It depends on the capabilities of the low code tool and the problem domain.
Just today I created a "flow" in the Android app Automate to add "auto-sleep after 30 minutes" functionality to YouTube every time I toggle pause/play after 11pm. Dead simple with a very easy to understand ui control flow. I could have written an Android app/service to tap into the various APIs and accomplish the same, but for this use case this low code solution was clearly superior. I could see a lot of software development being replaced with low code tools.
The problem always becomes one of extensibility --- if you use a lot of modules, while functionality goes up, the expressiveness/communicativeness of the code goes down because you're back at a wall of text --- it's just one in pretty blocks.
What does an algorithm look like?
The Drakon folks sidestep this by claiming that there should be one desired path and just connecting blocks in a straight line.
“Low code” is such a blurry definition. Is excel low code? Is a shader graph in a game engine low code or no code? Regardless of which, they’re useful.
What I’ve found is people who use low code tools are more willing to lower their expectations to the capabilities of the tool. This is in comparison to your typical customer of bespoke software development who has a long laundry list of requirements that they’ve imagined up based on their
perfect vision. If “good enough” was good enough for these people they would be using low code tools
To make it worse, the customer's "vision" is almost always wrong. It takes great skill to extract from them what they really want - otherwise you allow the customer to be a tech product manager, which is a no-no.
> Low Code tools lie to customers by implying that the writing of code is the hardest part.
Not true. Low code tools often excel at fast prototyping at decent quality -- if you feel comfortable enough you can ship them as is and you have a functional product. That might be all what customers want or care about. They don't produce the best code, but nobody really cares in the real world.
Sure thing, if you're building something complex, you have to deal with complexity, there is no way around it, low-code doesn't change it.
But I've seen lots of non-coding professionals who spend hours every week just looking up some info on various websites just to copy some text/number/address from a well-structured page and paste it into a spreadsheet. Could this be automated? Absolutely! Do they want to learn how to write a program, handle errors, manage the deployment of their scripts? Absolutely not.
Low Code has its place, and there are no conceptual downsides to starting with a low-code solution and then hiring software engineers to flesh it out and handle all the special cases. All we need is a low-code platform built around some real programming language that you can put into git, review, debug locally etc — with a no-coder-friendly interface built on top of it. This part is missing, and that's what causes people to dislike the low-coding in general.
I don't know why people like to blast low code developement on HN in general. The US and worldwide software development market is big enough to support both full software engineers and low code developers. Each has its own place in the enterprise.
As somebody who has worked a lot in the low code development area for almost a decade, these tools give a lot of capabilities to non-engineers. I usually see low code software development being used in the government sector where it is used by epidimiologists to track disease spread during covid, policy analysts and even environmental engineers to track pollution and build dashboards based on that data.
If not for these low code tools, that money would have been spent by the goverment on expensive consulting engagements to IBM, Deloitte and other government software vendors who charge $400/hr just to gather business requirements.
The problem with no-code or even LLM-driven app development (so far) is that the tool, or the language, isn't precise enough to tell it exactly how to behave so you can only really implement stuff that is extremely basic and pre-canned. Even then, just building a thing isn't really the goal. You want something sustainable.
Sustainable means the ability to build and reuse internal and external libraries, security best practices, version control, unit and integration testing w/ continuous deployment, monitoring, etc. You need to be able to reliably change/extend it over time as business requirements change. You could build a 'low-code' solution that tries to address all of these but it just starts to become another programming language. And because it was never designed with that intention, it's usually a pretty poor programming language.
This is a really poor generalization. Does anyone really think every company is a snowflake with a truly unique set of business processes? Of course not.
Anyone who has worked at more than 1 company in their career can see lots of similarities for themselves starting from the onboarding process. Dig into that and you’ll find some low hanging fruit for automation with no code/low code platforms.
If you’ve completed the discovery and requirements gathering phase and try to implement a complex application with a no code/low code platform, you’re probably early in your career or this is the first time actually using no code/low code platforms for something besides a pet project. So you made a mistake and should just be more cautious in the future, not write off these platforms entirely.
As anybody who went through the 80s/90s knows, the prototype almost invariably becomes the production artefact. "Why should you rewrite what already works?!?"
Actual building engineers don't have this problem, since the prototype is so obviously not the real thing. Software engineers have to make an actual effort to keep "civilians" from mistaking a prototype for the real thing.
I'm quite bullish about low-code tools now. Especially for building back office systems like ERPs or operational tools. From my experience most failures in such project implementations have been due to mismanagement in the requirement gathering phase and also development happening in silos where the team building has no real understanding of the business process workflows.
But with gpt-3.5 - these tools can really inlock the ability of non technical people to build products. Maybe outsystems should have a gpt chat interface that builds software on its platform directly from the requirements of the end user instead of any intermediate human development team.
Yeah? I'm working with a class using a lot of visual/block coding in Microsoft MakeCode. But then, I've also spent time writing code at various places in the (abstract) chain:
In terms of size, C is lower code than asm. TypeScript probably less, depending on what's being done. MakeCode uses blocks instead of text, but the logic concepts are the same. At each step up that stack it gets easier to do some things and harder to do others. Where along that stack does it become 'low code'?
As a developer writing a low-code data transformation tool, I have some skin in the game here. I believe that low-code tools are only good for creating a small subset of software systems. This is because software systems are incredibly varied and they often don't fit into the restrictive framework set by low-code development tools. On the other I believe hand low-code tools can be very useful for more restricted domains, such as data transformation, 3d animation or audio design (although they aren't always a better alternative to code based tools).
I have pretty extensive experience in this domain.
Personally, I found there is a application complexity ceiling above which LabView was not viable. It is pretty great for rapid data collection and analysis, and it is well integrated with a variety of hardware. But once there is a few things going on at once the "backplane" abstraction becomes unhelpful.
So many vendors provide python libs these days, and python plotting is good enough in these that it is harder to justify LV.
Labview is awful, I joined a lab that had attempted to build instrumentation controls in labview. Replaced with pyvisa and was able to write much more complex controls and automation without crying.
I suspect they would agree! LabVIEW is code, just in a truly awful format.
Simulink is perhaps a better example because it is at least relatively good, unlike LabVIEW, which is the worst thing ever.
(And if you're wondering why people use it, it's because NI makes a ton of very good (and very expensive) lab equipment and the software they provide to drive it is all LabVIEW based.)
“It therefore falls upon our shoulders to validate the approach suggested by the client before we possibly waste both their time and money developing it.”
I agree with this statement, but who pays for this analysis of the customer’s analysis? Customers expect to pay a developer for their time actually writing the code for the solution. Within most companies, developers are expected to build according to the specs from the domain experts and not argue about the specs or rehash the approach requested.
- workflow where items flow from one role to another
- less "code" for things like dependent drop-downs...where one field drives the drop-down choices in another field. Excel can do this, but with fairly complex macros
On that last one, I imagine there's more examples where Excel stops being "low code" because you're using complex macros. It's more flexible, but that's the tradeoff.
It is incredible in some teams how difficult it can seem to be to get from "we need a 1-page website" to "ok, it's online and you can update it simply without any more of my help. Here"
And with the difficulty going up, the likelihood that you'll do this when it's needed and makes sense to do goes down. I can't tell you how many times I said "I need a website" and didn't end up posting one, because we didn't have a ready answer to this question, and nobody could be bothered to go out and build one.
Just a simple one page website. I can think of at least three "easy" ways to do it (and that's my whole problem in a nutshell, thanks for coming to my TED talk.)
Low code is still a code. It is just matter of time before some office worker will create large and humungous low code project which then will be used by half of the office. Because worker never coded before, whole project will slowly (or quickly) become unmaintainable mess where one change will brake 3 features.
Then they will call a developer to sort this mess out and it needs to be done yesterday.
People who have spent years coding are also perfectly capable of creating unmaintainable messes where one change will break 3 features, thank you very much.
When you will be now "maintaining" 1000+ row VBA macro script in Excel linking dozens of files to generate a report and office folks will ask you to fix it because it does not work properly and author was laid off month ago, you will have different opinion.
Perhaps same opinion as if you're maintaining a, I dunno, 50K+ line software package as a development-team of one, which was developed by a single developer (who learned to code on the job) over a 10-year period and he left a few months ago. (Yes, this happens).
Many "low-code" solutions definitely give you enough rope to hang yourself. In this regard, ironically, they are more similar to than different from other kinds of coding. I'm not even sure Excel should count as "low-code". A multi-thousand line VBA macro script doesn't sound "low code" at all, right?
As I wrote in first post, low code is still a code. And there will be some office worker who will have enough time to pile up a massive project which is not documented, nobody knows how it works, the worker is gone, but half of office is dependent on it.
I once worked at a company with very complex business processes but no ERP to solve them. Everything was Excel documents in shared drives and emails. We provisioned a low code "quick wins" team to start automating these manual processes while we were implementing the ERP. There's a space for both low code and high code solutions.
I started using chatgpt last week for coding problems, and while it's not perfect, with very specific questions and code examples fed in, the results coming out saved me a lot of time, even if i'm rephrasing a question 5 times
With the dawn of LLM, I think low-code will be mainstream again. Of course it all depends on the applications. For applications where scripting is all you need, you can pretty reliably generate code with prompts.
For a lot of tasks, this is actually true. Take away the requirement to write code by supplying them with a low code tool, and suddenly people can do lots of useful things that they couldn’t before. So in that respect, it’s no lie.
But of course, there are a tonne of other situations, where code is not the only complexity present. Sometimes you’re just trying to solve a big, complex problem. Take away the coding requirement, and you’re still left with a tonne of complexity to manage. And low-code tools aren’t the best for handling that. In those cases, you’re better off hiring developers.
I’ve seen a few people build very complex things using low code tools. Modern ones, but also going all the way back to the original low code tool itself, spreadsheets. People really can build huge things with them. But after a certain degree of size and complexity, it’s more trouble than it’s worth to go with low code tools.
But that doesn’t mean low code tools are useless – they are great for the first set of problems, where the code required is just incidental complexity. You shouldn’t write off this substantially useful product category just because people get into trouble using them for problems they aren’t suitable for.