Low Code Software Development Is a Lie
jaylittle.com
jaylittle.com
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.
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.
Why take something out of your toolbox?
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.
This is all part of having a good level of intuition for what capabilities you are likely to need, and then picking appropriate technology.
You'll probably run up against the former quite quickly. The latter possibly never.
(In quotes because many/most no-code environments are Turing complete, but you still wouldn’t want to develop certain apps/logic in them)
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
The problem isn't my toolbox.
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.
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.
SQL is still dreadful, apart from all the alternatives.
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'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.
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?
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.
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).
It's as if we lumped together the creation of everything "made of wood" as similar. Shelf, doll, table, boat, grandfather clock...
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.
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 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.
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".
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.
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".
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 ..."
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.
> the real-world business rules
what are these for creative apps, and where do they come from?
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).
https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-in...
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.
I don’t know of a good equivalent replacement that people can use today with such a low entry level.
Excel covers a lot for many people.
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.
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.
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.
Anybody have any suggestions?
https://integralcloud.io is the app.
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.
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.
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.
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.
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.
As soon as you start writing custom modules, it should always be in a general-purpose programming language.
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.
It's like they can't decide if they want to give it away to grab market share or make money off it.
And pricing updates reflect whichever group wins the last debate.
- Unity and Unreal's material/shader graph.
- Unity's VFX graph/Unreal's Niagara
- Unreal's blueprint
- Blender's composition node and shader node
- The whole Houdini
- Substance Designer
- PureData
- Bitwig's grid
- Nuke
- Fusion
At this point I think it's a bit ridiculous that people still are arguing whether low code tools are helpful or not.
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.
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.
It's basically the job of a developer to move concepts that require coding through abstractions over to low code and then no code solutions.
"Low code" or "no code" is just giving it another name, like when people started calling other people's servers "the cloud".
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.
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".
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.
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.
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.
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!
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.
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.
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.
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.
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?
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.
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.
[1] - https://www.bls.gov/ooh/building-and-grounds-cleaning/janito...
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.
- 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”.
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).
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.
This article is a lie.
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.
https://respiroc.com/blogs/software/how-to-make-your-own-cus...
Basically:
1. Airtable (low-code) to be a database + submitting new data 2. python code to sync to shopify 3. frontend liquid code to display reviews.
I have built a lot of low-code with Airtable for a 5-6 million dollar business (revenue per year). Product development system, warehouse management++.
And just to be clear: The good no-code systems are still built by coders.
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.
My current favourite is BlockSCAD:
https://www.blockscad3d.com/editor/
which I've been using to explore 3D design and joinery:
https://willadams.gitbook.io/design-into-3d/3d-project
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.
I'm currently working in OpenSCAD Graph Editor:
https://github.com/derkork/openscad-graph-editor
which exposes _all_ of the OpenSCAD language, and allows me to loop in RapCAD and am trying to balance visual display and complexity.
I really wish there was a block programming or node graph interface for making a graphical application for Windows or Mac OS.
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.
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.
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.
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.
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.
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.
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.
hardware <- uCode <- asm <- C/C++ <- TypeScript <- MakeCode/Scracth
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'?
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.
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.)
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.
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.)
The user specification requires those tools to interact with the website, without technical help, in perpetuity. That's a MONSTER requirement.
- Allow significant/good multi-user access
- Change control
- Less fragility
- Allow editing large datasets (e.g. stored in Postgres) in a controlled way
- UI elements without diving into VBA code (once you are in VBA then anything is fair game obviously)
- Easily connect to external API's and integrate with other internal systems (again without VBA)
Assume other low/no code tools are similar.
- role-based rules about views, edit rights, etc
- 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.
I guess my point is alot of people outside of software development the goto for low/no code is excel
Then they will call a developer to sort this mess out and it needs to be done yesterday.
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?
I've used this app for a few months last year and the UI is simply awful.