We have been evaluating how to scale our company (software agency) to be able to quickly build out mvps for some of our projects. The topic of no-code has come up and the one product named Unqork[1] has been mentioned to us. Has anyone had success with these solutions, if so what type of projects have this no-code paradigm excelled at?
I don’t think no-code exists. It is a fools errand. No matter what the tools are for your profession - Photoshop, Unity, SolidWorks, Wordpress, or some new No or Low-code stack - you will quickly realize that having someone skilled in the tool is extremely desirous. For software development that person is a software engineer.
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.
Having seen businesses refactor out from low/no code providers to their own code base once there is traction, the value is in the product market fit discovery without shelling out to build a full blown app stack before you have traction. Fundamentally, it’s about capital efficiency.
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.
“Any sufficiently advanced tool eventually recreates the act of programming”
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 :)
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.
Run don’t walk away from no-code tools. Seriously. I have never seen or heard of a case where no-code tools increased productivity long term. Instead, hire good developers who knows how to be more productive with real production languages.
I was at one point on a team building out infra integration with Appian, which touts itself as a low-code / no-code platform. The sales pitch is the no-code example which executives really love, and the pitch is that they can get some "business minded people" to write the "low-code". But the complexity was enough that we ended up throwing a bunch of junior software developers and hiring consultants for it, so you ended up with something like 25 software developers on a "low code" platform.
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.
To your experience I wonder if some of these low-code/no-code platforms are succeeding because of successful salesmanship and networking rather than technical merit.
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.
Microsoft's SharePoint went through this exact same routine ten years ago. The salespeople loved it, the customers bought it and the tech folks trying to implement the customer's needs were tearing out their hair and delivering super expensive and super terrible solutions.
Ofcourse, that is how professional product organizations work. They define user personas and buyer personas, and then make sure they have a compelling story and features not only for the user personas, but also for the buyer personas.
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.
> 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 doesn't have to be a huge crumbling pile of debt. It's just a tool that can be used to create useful applications if used in the right way. I think of it as a visual IDE to build opinionated apps, i.e., visual ruby on rails or visual django.
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.
I see every command to tell computer to do thing is a YesCode, neither low or high, it's code. A form button click is akin to assembly `interrupt`, instead of doing routine with data in registers, UI event tells servers to compute data from form inputs. It's all programming languages in different styles.
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.
It's not all poor programming. There's a lot of repetition in software development. If you can find the right abstractions you can make software engineering a lot more efficient. This works, regardless if you visualize the abstraction or you put it in a function in a library.
I'd say that in an ideal situation low-code is a visual DSL that lets you declare in business terms what you expect the application to do.
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.
One thing I was thinking about today with low-code or node-based programming languages is you miss a really important organizational tool: directories and files.
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.
I've been around when these tools are being recommended or trialed -- the champion is never someone that understands anything about writing code. It is a way to reduce labor costs by getting Product Managers, Project Managers, Business folks and QA to generate code. I have never seen this work out.
It is a very common way these days to deliver enough barebones functionality to get enough money to then hire a team to build the product. For example, you are selling a service that monitors for mentions of your social media account. You start with something that looks like a web app but is actually just an Airtable form that sends you an email, and you do the service manually by just Googling their social media handles every day. Once you get enough customers you then raise money to go actually build the web app.
I was recently involved in evaluating a no-code UI toolkit. It did what it said it would, but did not (could not) solve certain key business logic problems (mostly related to domain-specific authorization).
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.
Microsoft Dynamics tries to be a no-code platform (although you can add DLLs if you want to) and it's a nightmare. Your entire app is built into a giant XML file. It can take 45 minutes for this XML to be imported. In the repo, the XML is taken apart into thousands of small XML files. Any change to the app has to be done as follows:
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.
Oh lordy, this is waking up some bad memories of using Dynamics for a huge project. As a team of 50, we started having to extend the crap out of it with c#, which made me question the use of the tool in the first place. So we called in an expert, who proceeded to tell up that if you didn't stay as close out of the box as you could with as little c# customization as possible, then we'd run into problems, which of course was the issue. That was in 2015, and the tool may have gotten better, but at the time, it was only capable of some basic crud applications, along with some pretty good interop with msft office. Point is, if it's a no/low code solution, the whole solution ultimately better be in the box. Otherwise you're screwed.
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.
This is typical enterprise stuff, Sitecore, SharePoint, SAP, LifeRay, AEM, ....
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.
The whole scene was funny because while the MSFT Dynamics sales guy was really trying to be helpful, the MSFT Azure sales guys couldn't give two shits about the tool and wanted to give it away as bait to get customers into Azure. That was my take at the time.
Our company tried to replace our decade old custom-built legacy CRM with Microsoft Dynamics but for some reason their enthusiasm quickly evaporated, they abandoned the project and now decided to modernize our legacy CRM instead. Now I know what could be the reason, thanks.
The biggest no-code app I see in companies is Excel. It doesn't matter what you feel about it. If the data can fit an xlsx, it will be an excel sheet with macro.
Are there any good examples of these amazing excel files that get passed around in companies? Nearly all examples I've seen are toy examples from college, simple imports of large csv files with some graphs added, or rarely interesting projects where someone creates a work of art with the cells.
Friends and colleagues seem to manipulate data using tools like panda, R, or even Power Bi.
I used to work in a team for a risk management department of a large bank.
The excel sheets that the modellers were coming up with were pretty, shall we say, interesting.
They basically built the app we were supposed to be building… but in Excel and then handed us the file saying “Here’s the spec”
Those sorts of Excel projects generally aren't available in open source (or source-readable) projects.
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.
A manufacturing company I consulted with had an excel file with VB for generating labels and code in a very specific way. A realty company had the whole post sale process driven off three excel files referencing each other. Each file belonged to a different department in the company (engineering, finance, collection for example). It all comes down to a few macros, vlookups and sometimes a bit of VB magic sprinkled in.
I do resource planning for my team with Google Sheets and it's been OK so far for my needs but often I wish it was more automated and less error-prone.
I've watched a lot of folks try to build a new product with no code tools, and when they want to add any kind of important feature for their use case... they have to learn how to code.
> Currently, the supply of no-code developers and agencies is far greater than the demand. Anecdotally, I'd estimate in the high hundreds or low thousands of entities explicitly marketing themselves for this service. Then when it comes to ones who've worked on apps that have scaled 2-10x farther than yours (assuming you have a few thousand rows in your primary database table), there are far fewer. Most of the freelancers experience is centered around prototyping. All of these variables mean you'll be quoted in the range of ~$150+/hr for these freelancers.
> 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 completely agree with the assertion that it's easier to hire normal devs vs no-code devs.
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.
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.
> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
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.
The rule, for a YAML-based no-code tool, would be:
"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."
I find that quote true regarding the linked example yaml.
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.
I think Ant (the Java build tool) might be a good example of what you are talking about. As I said above, I haven't experienced it in any software I have worked on myself, but Ant might actually be a good example of the "rule" in practice. Except that (AFAIK) Ant doesn't have Lisp style macros for example.
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++.
> 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."
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 still misunderstanding the point. It's not about implementing ALL and EVERY high-level language feature on top of C++. It's that large projects (note when the quote was made) OFTEN implemented something like HALF of the features of a language like Common Lisp in an adhoc way in that project. There a multitude of examples for that. Many of them were written in C++ and many of them were later re-implemented in Java (or similar).
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++.
I agree with what you are saying. So I am not sure what it is you think I am not understanding. My objection was to the “rule” claiming that implementations of higher-level features in lower-level languages are always inferior (“poorly on both counts”). That is simply not true. For example, a high-performance AAA game typically use a number of different custom garbage collectors all optimised for specific purposes. Solving a hard problem that higher-level languages can’t solve. There is nothing inferior about that. So that part of the “rule” is wrong. And if we remove that smug incorrect parts of the “rule” then all that remains is a claim that complex systems often implement higher-level features in lower-level languages. That part is obviously true. But not very interesting.
Yep those are good examples of how not to do it. Games typically instead link in Lua or Python and get on with it. That’s a much better approach. Another good example is the Unity game engine, using C# as the scripting language and then compiling it to C++ for high performance. That works really well.
In my opinion, low-code or no-code cannot be easily used as a general purpose solution. It is suitable for niche problem domains where some basic plumbing can be organised in basic logical workflows. For anything advance it is best to use a proper programming languages.
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.
From a 30.000ft view, this "no-code" thing looks like those "4th generation" RAD languages. They let you do what they were designed to do easy and quick, but the barrier around their scope was tall, specially for the "casual developers", their primary audience.
The issue is not technical per se: the issue is the bad evolution of IT toward a net separation of users:
- 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.
I've said this before, but the biggest issue with no/low code solutions is how they get abused. One of my past comments on HN:
> 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.
To hop on the maintainability point: The same is true for "High-code" solutions. If you want the ticket done quick and dirty, it'll be done in a quarter of the time. But good luck ever iterating on it with additional features.
> 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
Because writing requirements (as a business domain expert who doesn't code) or interpreting requirements (as a developer with no business context) are very difficult tasks.
For those looking for more general reasons why "No Code" works for some tasks but doesn't scale (i.e., to present to a boss), I did an article series on No Code:
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.
I think the only real advantage of no-code/low-code stuff is the lower friction to get started, but these tools invariably suck. I grew up with Game Maker (before Studio) and just having clear icons to add events and draw sprites and such made things so much easier to learn. That to me should be the focus. But from what I've seen these tools are mostly vendor-lock-in scams for non-coders. Sad.
74 comments
[ 3.1 ms ] story [ 122 ms ] thread[1] https://www.unqork.com/
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?
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.
What was the authors methodology?
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.
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.
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.
Friends and colleagues seem to manipulate data using tools like panda, R, or even Power Bi.
It worked quite well actually
https://github.com/SheetJS/enron_xls
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.
> 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.
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.
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.
- 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.
> 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
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.