I'm just going to come out and say it, I hate the no-code moniker (or nocode or no code). I have many gripes about how we've decided to name our section of the internet. It seems like I'm not the only one, see the replies to this tweet.
So here goes.
The problems with "code" have nothing to do with "code"
Although, we can say that's not the case, the name certainly feels like we're trying to edge out, even exclude, programmers. It makes it sound as if there is no place for code in our space (forgetting the irony that code is what we output).
How we feel about code —and why we want to avoid it— has in fact nothing to do it with code itself. Code is a language that helps us tell inanimate objects what to do so we don't have to do it. Our real frustration lies with what usually comes with software projects: overblown budgets, long delays and expensive maintenance costs. That's what we're saying "no" to, not code.
These issues have nothing to do with code per se but are due to scope creep, poor planning and underestimating difficulty of a task. Issues which, let me tell you, are also very very present in projects using visual development tools (doesn't have the same ring to it, that's for sure...).
If what we're trying communicate is that no-code helps get things done faster, we should elevate that fact in how we name ourselves instead of objecting to code itself.
NOTE: A few of the replies of the above tweet suggested RAD for Rapid App Development. Although it sounds like something out of the 90s (which I think it is), at least it has the benefit of communicating what no-code stands for: speed, simplicity and prototyping. That may be a good place to start!
No-code pits us against those from whom we desperately need buy-in
Imagine if Quickbooks' tagline was "accountants are useless" instead of "Organize and Manage your Business" (and variations thereof). Buy in from the accountant department, which is necessary in order to automate that work, would suddenly become much harder!
Ultimately, crucial processes in most departments are owned, approved and developed by developers and/or product managers even if they're imagined (or requested) by all departments. The fact that the marketing teams can plug into APIs, for instance, via 3rd party tools is new! Before that, developers and PMs had two routes: point solutions to solve their problems or, bar that, building it themselves from scratch. Now there's a gray area between the two that's opened up. It's no longer an either/or proposition.
How I envision the future of collaboration among developers, PMs and visual developers (hehe) is where we position "no-code" as either additive to existing tools or a product in and of itself. It creates a middle ground between custom code and point solutions on that a spectrum with writing custom code on one end and purchasing a point solution on the other and a middle that looks like:
- point solutions augmented by automations tools to extend their functionality to our workflow
- a horizontal solution that patches together a few automations tools to get to a workflow that works for our use case
- a custom build that scope out parts that can be taken on by no-code tools (and therefore don't require developer time)
All of these should be considered before "let's build it from scratch" or in tandem with purchasing a tool. But ultimately, if we position ourselves against "code", one of the two predominant options today, and the people who's approval we need, we're doing ourselves a huge disservice. Instead we should communicate the fact that no-code is narrowing down the solutions that need to be built from scratch to situations in which it's truly necessary (and so we can do a good job when we do build from scratch)!
So what should we call ourselves?
Huh... good question! I don't know! But I hope it'll have the following characteristics:
- Be inclusive of developers and everyone else (don't start with the word no)
- Communicate that we're here to help developers get more done faster so they can focus on higher value tasks (no more dev tickets for text changes on the website or simple API integrations).
What I hope is that we take a hard think of what we call ourselves because with every day and every new tool it becomes harder and harder to switch. And frankly, I think we're stuck with no-code whether we like it or not. So what I truly hope is we over compensate for our title by being more inclusive and thoughtful about how we fit in the broader tech world.
