The ultimate no-code tool is Excel. It is the beach to code ocean. It’s about lowering the threshold of results possible to the widest possible group of people. You can have extra modules and plugins and you will always see people who have never dabbled with code before snorkel down to more and more complex functionality. No code done right is a gym - you get users willing to do something, and you enable them to do whatever they are willing to work for. I was one of those users - started with Flash, then trickled into action script, then trigonometry and animation, then JS, PHP. Stereotypes and preconceptions about code are the biggest hurdle for many. All you have to do is let them play and see whose brain naturally carries the load and asks for more. So Id say no code doesn’t replace engineers, but makes more of them.
I’m still on the fence. He claims no code has a niche “concretizing workflows”. The problem is vendor lock-in, as well as the myth of the non coding business analyst. I’ve seen enterprises sink millions into BPM software to crank out a few forms a Dev could do in open source code overnight. Inevitably the “business analysts” can’t use the tool either, so now the company gets 300/hr specialist Dev who only knows this bpm tool. Finally they realize the costs and absurdity, but are faced with upgrading or scrapping and rewriting these processes in custom code or the new hot tool.<p>Concretizing workflow is good, but take care what concrete you use and who pours it. Could end up pouring your company a new pair of boots if you know what I mean.
> In general we have started to figure out how to make the DNA of software systems resilient against the changing tides of time. No-code seems to reject a lot of those learnings, for better or worse.<p>When I was a kid we had Microsoft front page, a no-code solution that allowed you to create a web page. A few years into college my brother-in-law started making money writing web pages in plain CSS and HTML and a little jQuery. I asked him why he could make money when I could make the web page in front page. he said it was much as easier to change the web page over time when it was written in code than changing the auto-generated garbage HTML that front page produced. No code, then, stood up poorly over time back then and I doubt it will today except as a way to make standard parts out of modular pieces of software, sort of like Unix did back in the '80s with its modular command line tools.
I find it a bit weird that people are treating all this as a new thing. There have been no-code/visual programming tools for ages, especially in creative industries, e.g MAX & Reaktor (music DSP), Grasshopper (architecture), visual shader editors (most 3d software + game engines), visual game logic scripting (e.g. Unreal), etc...<p>IMHO in these fields people care about getting results without all the software dev ceremony (which probably would add very little in this context).<p>Obviously there's a ton of code machinery behind the scenes to make it work, but the same is true Javascript so that's neither here nor there.
> No-code seems to reject a lot of those learnings, for better or worse. I haven’t seen any no-code company or product that allows source control<p>Bubble.io offers source control in a somewhat limited sense. Although the utility is quite limited. You can create save-points and revert to them as required.<p>You can also export versions to json and commit them to a git repo. I do this for fun and some code hacking. It isn't as useful as traditional code maintenance but can come in handy.<p>Coming to where nocode is useful? Few points based on my experience:<p>a) We had to create a prototype with a single member techno-business team (me) and few business guys on a very undefined problem. I managed to get it done with Bubble. In fact our business guys tinkered with the layout and design while I was asleep (I gave them not to mess anything up from a functionality though :-))... for e.g. I could spend days/weeks discussing colors, fonts, layouts etc or they could just do it themselves to their visual satisfaction<p>b) Limited use-cases. I am working on a side project for freelance recruiters. Goal is to help them launch their own indie-business. I can quickly put the system together with visual feedback and perhaps finish it in less than a week during my side-project hours. I think it would take me week to do it the first time. Perhaps 2 days for similar apps from then on.<p>I plan to supplement it with more involved sophisticated data mining hacks from the backend. Works neatly!<p>In essence, many businesses are not technologically sophisticated (in the coder sense) and need not be. They need to deliver value in utility, organization, reduced friction, etc.
no-code can shine in these areas. Coders can hack on top of it to try to reduce the gaps.
The ideal mid-way frameworks offer both, a library of patterns that work for internal applications that are almost no-code, and ability to write code where business logic is required. There are some things that are still best expressed as code. I am not sure if a truly "no-code" framework is possible for real-world applications.<p>We have built Frappe Framework [1] as a platform to re-use code for our massively complex application (ERPNext with 900+ models). While it does not have a drag-and-drop UI builder, object creation and migration is fully automated via configuration. The key reason why this works as low-code is:<p>1. Automated UI generation (via metadata)<p>2. Automated database management (schema and migrations)<p>3. Abstracted functionality that can run on any object (like permission rules, workflows, assignments, file attachments, PDF generation etc)<p>The configurations are stored as JSON files that can be used for source code management [2]. Frappe Framework is still under the radar, but of late we have seen many teams using it massively for internal tooling.<p>[1] <a href="https://frappeframework.com/" rel="nofollow">https://frappeframework.com/</a><p>[2] <a href="https://github.com/frappe/erpnext/tree/develop/erpnext/selling/doctype/quotation" rel="nofollow">https://github.com/frappe/erpnext/tree/develop/erpnext/selli...</a>
I would add another example of a use case. Access already solved most of the no-code issues. In our SME I wrote a key business application using standard Access forms and a database. There's a few lines of VBA code but that's it. I could of wrote a bespoke app in a modern language which would of taken days and weeks. But access allowed me to get a system working in a few days. We're still using that system years later.<p>Developers will complain this system isn't scalable and lacks testing, but for a small business or small team that's all that's needed.<p>Another key problem is that with simple tools you empower non-technical users to do their job faster. If you obfuscate the data behind an application you become dependent on software developers for maintenance which increases cost and reduces resiliency. For large corporates, this can mean removing an army of low-cost administrators and replacing them with an army of high-cost software developers.
When teaching the rudiments of programming to children -- like Scratch -- maybe.<p>In all cases, once again, "no code" doesn't make the programming go away, it just puts a visual skin on it that makes it prettier to look at but more difficult to manage over a system's lifecycle.<p>In the 1970s, secretaries at MIT used a version of Emacs -- Multics Emacs, which predated GNU Emacs -- to type up documents; and what's more, they automated common tasks with Emacs Lisp. They were only ever told they were <i>customizing</i> the editor, though, not programming it, so they could approach Lisp without fear.<p>The representation could be anything -- literally anything at all -- and as long as the end user doesn't believe they are doing "programmers' work" they will use it if it makes life less tedious.
The same people who hate on no-code also often hate when they have to develop some simple CRUD app (which is where no-code excels). I personally think that there will be a huge no-code revolution, because of the simple fact that there are still a lot of manual paper-based poor efficiency processes in businesses.<p>Without no-code software, the cost to automate a simple business process which takes a low paid admin worker 3 hours per week might be:<p>* Requirements Gathering (Let's say 1 day)<p>* Development time (Let's say only 5 days)<p>* Testing time (Let's say its fast and only takes 1 day)<p>* Bug fixing (Another day)<p>* Ongoing Support and changes (estimated 25% per year)<p>So at $500 per day and this incredibly conservative timeline, let's say that solving that simple business process costs $4,000 capex with $1,000 annual costs including infra. This saves 3 hours of work for someone on minimum wage... $2,340 per year.<p>A few problems:<p>* Problem Number 1 - This doesn't meet most companies hurdle rates (>2 year payback).<p>* Problem Number 2 - The problem wont be deemed 'big value' enough to get IT resource assigned<p>* Problem Number 3 - People in general want to work on 'bigger problems' and will hate going solo on a tiny piece of work to reduce a single workers week very slightly.<p>Ok, so that's fine from a company perspective, but look at it from the minimum wage workers perspective - They might be doing something that they KNOW they themselves could automate, but their IT department won't do it because they deem their time too valuable, and they aren't allowed to do it themselves because they aren't deemed knowledgeable enough.<p>No-Code shouldn't aim to solve all problems, it should aim to solve the problems that are below IT's threshold but still deliver user value, otherwise there is value left on the table and you have people doing work that could be better automated or put on a better platform.<p>It's not to replace everything, its to build something that's better than excel and paper, when your IT department can't/won't build it because of capacity/hurdle rates/investment.
Great article!<p>I have a different point of view.<p>There are two assumptions I disagree:<p>Assumption 1: No-code will not benefit from code learnings (or do some equivalent progress)<p>Probably, because the nature of domain (code vs GUI), the solutions may be different, but it's possible to attack the same problems.<p>many no-code tools have some type of versioning plus real time sync<p>many no-code tools have some type of abstraction level extensibility with plugins<p>...<p>Assumption 2: Software development is mainly solving complex problems<p>The other force no-code in the no-code side is, as software industry gets more mature, more patterns are discovered.<p>Just look how much boilerplate is in each company or unnecessary rework with bad abstractions.
Most of companies doing software today are just rearranging things on screen, or creating some simple pipelines.<p>Even though RAD, low-code, model driven, etc.. is not a new thing, time has a important role here:<p>Also as software is getting more popular in last decade, we saw a lot of space for "almost the same" solutions to coexist, allowing more of the production process to be "productized"<p>This can be different to silicon valley style startups, but most of the market is solving the same old problems everyday.<p>Full disclosure, I actually have a no-code/low-code startup (<a href="https://abstra.app" rel="nofollow">https://abstra.app</a>) hence I'm very biased!
Does Mathworks Simulink count as "no-code"? Because if so, then "no-code" seems to be incredibly useful across a diverse set of critical use cases.
Every app that you ever built for the end user is a no-code tool. Reframe your question and you get your answer.<p>With that said, no-code is jumping the gun. Start with <i>less</i> code.
Three forces are in mostly at play in any no-code solution.<p>- Abstraction<p>- Flexibility<p>- Cost of labor to produce functionality<p>Higher the abstraction lower the flexibility. However, for enterprises the ability to produce functionality without requiring a skilled work force matters a tonne. The success of Airtable & likes speaks volumes. That's because the world is not as complex as the article likes you to believe.<p>As developers, we underestimate nocode solutions. And enterprises probably over estimate.
I know Fortune 500 companies using online databases like QuickBase to operate their businesses. QuickBase is a sort of web-based relational database meets excel formulas. Business owners love tools like this. I know of a handful that run $50M+ ARR online businesses using no-low-code platforms where the only technical person on payroll is the IT guy that reboots the phone system each day.
This is a good take. To add to it a bit, there's another perspective that makes no-code solutions useful: team decoupling. You know Conway's Law about how the software is structured like the organization that produces it? No-code is that, but it's giving "coding power" to parts of the team that didn't have them before. E.g. a design team can accomplish a reasonable number of funnel tweaks using an A/B testing tool, and it means they get their job done faster (= more effectively), and the engineering team can focus on other problems. It's not a panacea and there's definitely risks, but I've seen it be helpful in this way in many contexts.
A ton of businesses have been running on no-code for decades. Excel, MS Access, Squarespace, Gmail and many others. Not every business is heavy on writing code. They just want to get things done quickly.
>reifying workflows<p>In my experience as a software contractor, non-technical and even <i>semi</i>-technical people always underestimate the complexity of even the most mundane task.<p>I wonder if the author has ever written a sales order processing system. It <i>seems</i> easy on paper, and you can probably crank out a naive implementation in a single morning ...
meh.
Its deeply patronizing to hear gate-keeping developers discuss when is 'no-code' acceptable...<p>Talk to a first line employee or manufacturing factory worker end user who wants to make minimal data apps on fly without the extra time or baggage.<p>Google Appsheets or Microsoft Power Apps are fantastic tools of this nature.
In a practical sense but not intentionally so most JavaScript work is no code. Original work is not expected and developers are both terrified and bitterly hostile to writing original code. The result is frustration for everyone involved, including the end user.