To talk about what no-code is good for, we need to first take a digression on what makes no-code fundamentally different from “yes-code” software.
The grain of abstractions
Software – yes-code software – has been around for a while. One of the things we’ve learned as an industry is how to write software that gracefully evolves. We’re not perfect – sad, legacy systems still proliferate – but we as a technical industry have learned how to build and evolve software systems against changing requirements and constraints that span years and decades.
When we first solve a problem with software, we write some code against the constraints of that particular day. We don’t necessarily know how the problem is going to change. Maybe there will be different customers or stakeholders tomorrow, or maybe the product will expand to serve a related, but different, problem space. We need to be able to change software to accommodate changing circumstances without rewriting it, and that is fundamentally what software engineering is: how to change software systems. Change is the name of the game.
We’ve gotten decent at change. We’ve built tools like Git and patterns like continuous integration and code autoformatting to make it easier to change code and remain stable. We’ve learned how to operate large software teams, especially in open source. We’ve also learned to use better abstractions. Abstractions are conceptual wrappers that isolate different parts of a codebase – say, a data source from a user interface – so that one part may change while another doesn’t. 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. I haven’t seen any no-code company or product that allows source control (and I’ve seen many no-code companies, but you’re welcome to prove me wrong.) I have yet to find no-code products that allow for natural construction of abstraction between layers of a no-code workflow. No-code software is also scarily ill-prepared for large scale development: we have software systems being worked on by tens of thousands of engineers – what does it look like for a team of 1000 engineers to be working on a set of thousands of no-code workflows? Chaos.
Traditional software has learned the abstractions and patterns that make software resilient and adaptable to change and scale. No-code software is not ready for changing constraints nor development scale.
Despite these limitations, I think no-code has a few niches where making tradeoffs in adaptability and scale allows no-code tools to be much, much better. So, given this, when is no-code useful?
1. Transitionary, ephemeral software
The obvious answer, and one I had before our conversation, was transitionary software, software with a defined lifetime. If your software system has a finite, pre-defined lifetime and team, it doesn’t need to worry about changing constraints or team growth. It just needs to worry about solving a problem well, now.
Lots of software has predictably finite lifetime: a product prototype for an early-stage company, a game or app used as a part of an interactive online ad, a quick sketch or solution to patch a particularly urgent problem in a product, an app built for an event or a conference or a recruiting cycle or a quarterly goal tracker… all of these are projects with a pre-defined, maximum lifetime. They don’t need to last or grow or change – they just need to work now, and by giving up some of the adaptability of software abstractions of code, no-code software benefits from way faster prototyping speed. This is a plus.
I think we see lots of finite-time software in transitions. Transitions from having no product to having a product, in a prototype. Transitions in the process of brainstorming a solution and trying multiple designs. Software with a finite shelf life is a good fit for no-code tools.
2. High-churn code
There’s another category of software for which long-term maintainability matters little – code with high churn.
By high churn, I mean that requirements are changing almost daily, and very little of the code written today will exist in a month or a quarter’s time. If the code you write today doesn’t have to last and evolve, because something new is going to take its place tomorrow, what matters is the speed to build, not resilience to change.
There’s lots of high-churn code in businesses. Marketing websites and landing pages, data pipelines for analytics, e-commerce storefronts, marketing campaigns, payment portals – requirements for these kinds of solutions change quickly enough that code is constantly being rewritten, and if code needs to be replaced more than it needs to last, no-code tools are a great fit.
Avoiding the same mistakes
I think “no-code” is a misnomer. It leads us to think that no-code software is the start of a trend in which general software will involve less coding, and software engineering will become easier. This is not the case. Software engineering is not about building solutions, it’s about evolving them. But change resiliency over time is not the focus of no-code tools, and I think that’s ok.
I think no-code tools are instead an extension of a different trend: reifying workflows. Business processes and workflows used to be documented in Word docs strewn about the office or on a shared folder, or even just passed down by oral tradition in companies. Now, we have tools that allow us to build these workflows, talk about them, edit them, and share them more concretely. This is a huge boon for more repeatable business processes and for getting things done quickly! I think this is the true win of no-code tools: concretizing workflows.
If no-code wants to be a serious competitor against “traditional” software – though I don’t think it should try – no-code needs to learn from the mistakes of early software. No-code tools need to understand that products and software systems need to live on for decades against changing teams and requirements, and against products and companies and standards that die out and get replaced. This requires a cultural shift, a tooling shift, and a new class of abstractions in our toolbelt as no-code engineers. Anytime we try to introduce more tooling and abstraction to no-code, I think no-code gets just a little more “code” in it. And perhaps that’ll bring us right back to where we started, discovering that code is good.
After all, the world is complex. And when we build software against the complexity of the world, that complexity needs to go somewhere. Software is complex, but only as much as the world it attempts to make sense of.
It feels like we’re getting off the edge of a discovery phase of no-code, and into a time when we’re starting to understand what problems no-code tools are great for. I think it’s important that no-code tool builders focus on those strengths, or risk falling into the trap of repeating the software industry’s mistakes from the ground up.
← What makes Twitter different, and other thoughts on identity