When No-Code Stops Scaling (2020)
head.ai
head.ai
The "low code" option, which isn't really less code than just writing it in a terse language like python (so really only code compared to java). So for this company moving to Appian, we ended up writing a ton of integration work in Java, and tons of AWS services. Then with a bunch of custom, vendor locked, appian language for their platform. And in the end we could have saved money if we had just rewritten the whole platform on AWS for our own use case using just a rules engine in postgres and some service.
Similar to how vendor A can wine and dine the right person from firm B to get the firm to adopt vendor A's tech, rather than having the right internal people vet the solution.
It isn't the developers that are pitched. It is the people over the heads of the developers, this seems to be crucial.
It's not about wining and dining, but about knowing what your buyers value in the products they buy. For low-code, buyer personas value time-to-market and reducing dependency on limited available software engineers. Management often has more software needs than the IT organization can deliver, and new engineers cannot be found easily, so they look for other ways to build the software they need.
That may be the case, but building a huge, crumbling pile of "low code" or "no code" technical debt is not a sensible way of "reducing dependency" of engineering.
It will significantly improve your productivity on repeatable tasks (crud pages, domain model to tables, querying, etc), and you can usually add custom coding for those things that aren't handled by the low-code platform. Or you write a separate service for those parts and call these through REST.
- Client has complex-ish billing rules that need to change periodically
- Their desire was a system that would allow business bods to implement new and modified rules without pesky IT involvement
- Client was demoed a low code / visual programming tool, and fell in love
- We were brought in to team with the company that produced said tool to deliver the system
- client's IT department were Java-oriented, but were specifically overridden by the business for this project !
Well, we delivered, but the emergent reality was very different:
- It became clear very early on that the tool required specific programming skills and training, and there was zero chance a non-programmer could make any headway
- Because of the limits of the tool, the codebase ended up far more intractable and complex than it would have been using a regular language / setup
- The tool required regular version uplifts, which necessitated some code changes and other shenanigans, all extra ongoing cost on top of the licence fees
- The only people who could do anything with the tool were consultants from the company that made it (and a few of our folks who did training) - vendor lock-in with a vengeance
In a bitter irony, for test purposes I wrote a parallel implementation of the billing rules in Ruby, using that language's superb DSL capabilities, and that was a million times clearer and more maintainable. If I had a time machine, I would go back and persuade the client to instead go with a Java solution with Groovy to do the billing rules, as its DSL capabilities are on a par with Ruby's.
The so called low-code is just poor programming language. If I create a language whose only feature is `print` without debugger, I can call this low-code as well.
That is not going to be "low-code". The right abstraction is a bunch of small modules and functions. Visual programming is not low-code.
Kinda like pseudo code that you would expect from a business analyst, that only defines what business outcomes you expect, but technology independent. So it could still be implemented in react native, or veujs, or angular, or native swift.
1. build the giant XML file 2. import it into the platform 3. make the change (e.g. update a form or database column) 4. export as XML 5. shred it into thousands of little XML files
Then you discover that one simple change in the app has turned into dozens of changes in XML files. And you have to figure out which of those changes to include in your commit. If you guess wrong, then unpredictable things can happen.
If you're tempted to bypass all this by just editing the XML directly - sometimes it works, and sometimes the whole thing is deemed invalid, which you discover when importing it and you get an extremely unhelpful error message.
The original idea was that you can define a data model, forms, and some business logic in a no-code manner. But it's a nightmare when you have a team of software developers working on an app.
So how do you come up with a uniquely competitive product from no/low code if the whole solution must already essentially be in the box? Maybe the best use case is internal IT needs.
Out of the box they are always very generic and then it is expected that a team of consultants, certified from agencies with vendor partnership, drop in to perform the actual customization.
> I've seen "low code" and "no code" solutions running at huge enterprises and it always inevitably ends up resembling a house of cards. Proponents often cite how much quicker they can ship things and how it lets users define and automate their own workflows without waiting for engineers. The reality is that these time savings come by cutting corners from the development cycle. Because you're not doing "code", the code review step gets skipped. The authoring of automated test suites get skipped. The authoring of performance regression testing gets skipped. There's no waiting for things to bake in non-prod environments because people are changing settings directly on prod. No ones doing phased deployments with automated rollbacks here in these low code and no code environments. No design reviews mean you get solutions that are the absolute worst hacks.. Why go through the work of making "priority" a first class property on your ticket type when you can just string scan for "high" | "medium" | "low" on case titles when doing assignments?
> Engineering teams could also move fast if they just threw maintainability to the wind. There's a reason they don't. If you do things the right way in these low/no code environments, the complexity is even worse, because the features are so half-baked that you can't setup proper safeguards without doing crazy amounts of escape-hatches.
I get the appeal of how it seems easier to train people with business domain expertise on how to be no-code devs than it is to translate requirements to an engineering team or wait an indefinite amount of time for a dev team to prioritize work. But until no/low code solutions start focusing on how to maintain and operate the apps users build, they'll continue to be a landmine.
Why do you think this is the case?
If it stops scaling; that's a pretty good sign engineers should start actually building the thing
Friends and colleagues seem to manipulate data using tools like panda, R, or even Power Bi.
It worked quite well actually
My first "real" programming job was to convert an Excel based report into one done with a general purpose programming language (we chose Python) because the reports were taking hours to generate in Excel and each report file was over a gigabyte in size.
If it were simple static reports it would probably have been easy, but minor modifications were necessary every week, and the analytics team was terrible at conveying what was actually required without actually doing it in the excel, so management decided our program had to generate a more optimized version of the original Excel file as output to give to the analytics team to then work on. After like 3 months of work on this, I figured out how to just write a tiny python script to remove the unnecessary data from their excel files. It made it so they could open it on their cheaper laptops without grinding to a halt and generate the modified report in few minutes. And we didn't have to try to replicate an Excel formula structure that had been iterated on for over 5 years into python, and our team was moved to better tasks.
I've also worked on complex language localization projects that probably would have been most optimally handled by a database connected application, but it's way easier to send an Excel file to contracted translators, so that's what we used.
I've heard other horror stories from friends who work in finance. But they work, so whatever.
- programmers on one side
- users, powerless, and hopefully ignorant
that can't work. Any net separation can't work in practice. Specialization is needed for commerce, a bit of specialization is needed in practice because we profit from division of labor since some are more skilled in something while others in something else but not without all parties knowing a bit the so called big picture.
That was in IT history the original desktop vision from Xerox to Symbolics passing through Bell Labs. Some, more skilled design desktops, their operating systems, others are users-programmers so not skilled enough nor interested in system-level development but soft-skilled enough to profit from proper end-user programming systems they got from the more skilled ones.
That's the real "no code of the future", witch is actually from the past, witch have live today with Emacs for instance, playing with Lego-bricks "visual" tools, graphs, various modern UIs is just the proof that the elogium of ignorance and division into watertight compartments wanted by modern economic-driven management do not work properly and make bigger costs for bad outcomes while stating the contrary. No ML tool can solve that. We just need to ADMIT that for 30+years we have followed bad ideas and that originals one was the real solution, time to go back in time starting from now.
https://mindmatters.ai/t/no-code-software/
Additionally, as an anecdote, I've seen organizations get burned on the security side because they had people who knew nothing about web security trying to build apps.
Originally when I was designing the low-code solution for our security platform, I wanted it to be as generic as possible. Through trial and error I found out that such a solution is never going to succeed. Similarly some programming languages are better in some problem domains than others. You just need to know which tools to use.
A low-code tool that let’s you build web apps using yaml. In v4, you config is run in a lightweight nextjs app, so should scale as well as nextjs for the most part.
A lot of the issues that people are talking about in this thread have been address, mostly because with lowdefy we’ve focused on making the schema easy to read, write and understand. Currently we write all our apps by hard coding the yaml, and it’s scaling really well in our team.
For writing apps in yaml, you get advantages like: - Apps follow a structured schema, thus easy to pick up where others left off. - Nothing is hidden in a GUI. You can copy, paste, find, replace, review changes, duplicate repos, etc. - Create and manage apps with code, develop scripts, like automating app updates. - YAML / JSON files work with all dev tools, devs are more efficient when they use their favourite tools.
With Lowdefy v4 you can extend blocks, operators, actions, connections, adapters and providers with plugins, because sometimes custom code is the right solution.
We’ve built enterprise level CRM and MRP systems using Lowdefy and our clients love how fast we ship features that they need in their business processes. It's really working well for our small team!
> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
I write a lot of Ansible playbooks (yaml as well), been doing that for almost 10 years and I still have to jump to the reference manual. YAML DSLs are a pain to work with. Jetbrains software might have a plugin for GitHub Actions, Ansible(, and what have you), etc but that only makes slightly bearable.
I think you might be to close to the core of the project to see that YAML without some autocomplete (intelisense) support is a though environment to work in.
[0] https://github.com/lowdefy/lowdefy-example-case-management/b...
I call BS on that “rule”. 25+ years of experience here working on very large C/C++ code bases used by large commercial companies. And I have never ever seen this happen in practice. I know that the often cited “rule” makes some Lisp fans feel all smug and superior. But it doesn’t seem to be based on reality.
"Any sufficiently complicated descriptive-declarative programming language contains an ad hoc, informally-specified, bug-ridden, slow implementation of a Turing-complete programming language".
In Concepts, Techniques, and Models of Computer Programming, Roy and Haridi define descriptive-declarative programming as:
"The declarative 'program' just defines a data structure. This language can only define records! For example, defining graphical user interfaces. Other examples are a formatting language like HTML (Hypertext Markup Language), which gives the structure of a document without telling how to do the formatting, or an information exchange language like XML (Extensible Markup Language), which is used to exchange information in an open format that is easily readable by all.
The descriptive level is too weak to write general programs. So why is it interesting? Because it consists of data structures that are easy to calculate with. HTML and XML documents, and declarative user interfaces can all be created and transformed easily by a program."
Applying it globally might as well be BS. Where I've seen it in practice is in software that allows end-user configuration.
At the intersection of classic directive oriented configuration and the dynamic configuration file, but not quite an embedded language.
Another example is when you allow users to input rules, or have rule builder systems. You're going to build something similar to a lispy evaluator fir those rules.
Maybe because you don't understand what it is about? It's not about including an actually instance of a Common Lisp subset (that that has been seen, too), but that the application programming language (C++ was popular in 1993, when this came up) of complex applications will be enhanced by all kinds of dynamic features incl. custom higher-level languages on top of it. At some point in time it was popular that the projects invent this stuff by themselves. There are really zillions of examples for that.
Vassili Bykov explains: "...that complex systems implemented in low-level languages cannot avoid reinventing and/or reimplementing (poorly on both counts) the facilities built into higher-level languages. Like garbage collection in OLE or keyword arguments in X."
Other examples: dynamic loading of code at runtime, serialization of data, a built-in scripting language, complex error handling, configuration languages, a dynamic object system (dynamic = extensible/introspective/...), meta-level features, extensible syntax, ...
Many larger programs needed this facilities: A CAD program in C++ will usually add a multitude of these features incl. a scripting language to C++.
Nope. Not true at all. Games for example implement “garbage collection” all the time but it is not the garbage collection typically used in “higher-level” languages. It is instead carefully tailored to the task at hand to achieve the kind of performance players expect from games. This is something you can not do in most “higher-level” languages. Which is the reason why most high performance complex software is not written in “higher-level” languages.
So there is a reason why smart experienced developers start new complex high-performance projects in C/C++ every day. They simply use the best tool for the job.
That's even seen in games: Many games have high-level sublanguages or use them in deep in the game production process. Stuff which was implemented in Scheme (a Lisp-like language) for "Uncharted: Drake’s Fortune" which was otherwise written in C++: Particle definitions, Animation states, Gameplay scripts, Scripted in-game cinematics, Weapons tuning, Sound and voice setup, Overall game sequencing and control, ... Other game studios use other high-level languages in or for games, even self-invent them. Earlier versions of their games engines even were implemented in C/C++ and were providing a Scheme-like runtime with special memory management.
This does not mean that all of a game or any game is written in a high-level language. It also does not mean that every game has a garbage collector like in, say, Java. The Java GCs are also often not written in Java themselves. But JVM usually have one or more different garbage collector implementations for a wide variety of task - even for server applications with complex performance needs. It's a feature of those JVMs. There are zillions of server applications which are not written in C++, but in Java (or Erlang, Python, Ruby, ...) , but still using C++, since parts of the runtime can be written in C++.
Instead of using a real Lisp, he invented his own, poorly.
Stallman later rewrote Gosling's Emacs: he added a Lisp runtime with real GC and a Lisp, which was based on Maclisp.
That's now GNE Emacs.
When we told people: we're happy for you to use this tool as long as you also write as something else that solves this necessary business problem, it took a lot of wind out of the sails.
The hard stuff is still hard.
> Now looking at a code-based developer (like one who builds apps with Node or Rails apps), you can hire great ones for $50-100/hr. This is simply because there are millions of developers out there.
this is the first time i've ever heard someone argue that its easier to hire normal developers than nocode developers. made me seriously question the piece.
I used to work at a company building one of the bigger low-code platforms (Mendix).
Lots of our platform was "dogfooded", i.e. built in Mendix itself. Control plane apps, that kind of thing. This was a very bad idea for many reasons, but one major problem was hiring developers to work on it. There were simply very few competent specialized Mendix developers available on the market. The really good ones (that you wanted to hire) all became contractors earning >$150/hr. The other devs on the market were very junior.
The alternative was to train up our own regular developers to use our low-code platform. But that didn't work either, because your average Java/Python dev recognized that low-code was a career dead-end, and didn't want to learn it.
This is specifically in the context of Unreal Blueprints.
Files let you organize, group, and provide context to things in an intuitive outline-like way.
This no-code thing has existed forever. It’s a base set of software that is customizable as needed to fulfill the needs of your specific use-case. The rebranding to something that never requires custom work is once again a big lie.
Any sufficiently advanced tool eventually recreates the act of programming - putting pieces of building blocks together logically in advanced ways to fulfill a task. Dragging widgets around and typing conditionals in form elements is just another (slower, worse, more error-prone, restrictive) way of developing applications.
By all means, if you have the skill set and are confident to get there without a workflow tool, do so, otherwise (maybe you’re biz and product heavy vs tech capability heavy as a team) prove it out and then invest in your tech stack. As the saying goes, you’re not writing code, you’re solving business problems for money. If you don’t have to write code to solve the problem, don’t (or write as little code as possible).
TLDR your workflow tool is either the equivalent of scripts run by cron but more accessible to the team or a spike you intend to clean up and operationalize long term. Treat it as such.
I think that quote in your last paragraph really hits the nail on the head.
I’ve become pretty adept at a few no/low-code tools and have thought after a particularly challenging project “wow, that was a doozy. There’s no way somebody new at this tool would have been able to work that out. The only reason I could is because I have months and months of daily hands on experience with the tool”… which at that point, I’ve realized the learning curve can be similar to just learning how to write all the code.
Always fun to learn new tools and methodologies though no matter what :)
I don't disagree, but to me you unlock your true potential by learning to code. Once you are proficient in the art, the framework / language / tools don't matter anymore as they are all the same. Once you understand computation from bottom to the top, you realize it's all the same thing re-done in endless variations.
We're having great success with it as a software agency, it really scales well with projects because you can organise files and folders the way you like, and do code review because you are working with a app schema that is easy to read, write and understand. Which enables all the advantages of coding as well as low-code.
Or pick an existing starter kit on the market and base all your MVP projects on that?
What was the authors methodology?