Embracing NoCode
Should you embrace NoCode? It depends on what you are using it for. Here's how to tell if your use case is appropriate or not.
The NoCode wave is upon us. Platforms like Retool, Airtable and Bubble are changing the way the way we build software...
...said no software developer, ever.
I'm not going to lie: NoCode is a contentious topic. Non-technical co-founders swear by it, career programmers scoff at it. Who do we believe? How do we move forward as an industry?
In times like this, I turn to our technical forefathers, in the hopes of not repeating the mistakes of the past. Here's Alan Cooper, the father of Visual Basic, on his take:
The never-ending quest for programming tools that don’t require code is a clear symptom of our failure to understand what programming really is and how it gets accomplished. Also, it shows how scared we are of code and coders and how we want it/them to go away and leave us alone.
— Alan Cooper (@MrAlanCooper) December 5, 2021
Look, I get it. Programmers are expensive. Getting them to estimate their efforts accurately (and then hold them accountable) is like pulling teeth. And when you ask them why your latest feature isn't done yet, out comes a nonsensical string of technical jargon that tells you nothing.
It feels like it would be a lot less painful to just do it yourself. That is, after all, the promise of NoCode. It is in this promise that we fundamentally misunderstand what NoCode platforms were meant to do for us.
Let's start with problem number one. "NoCode" is a bit of a misnomer. Here's a quick peek at an app in Edit Mode in the popular NoCode platform Retool:
This is why programmers balk; they know the truth. NoCode tools are really better described as "EventuallyThereWillBeSomeCode." And the minute you need to write one line of code, I'm sorry to have to tell you this...but you either need to have a programmer do it, or you need to become one yourself.
This leads to problem number two: doing it yourself. NoCode tools give you the sense that this isn't so hard. You throw a few drop-down menus and buttons together on a screen, spin up a database to store your data, and suddenly you are collecting data...customers are interacting! Our startup is off and running! Who needs expensive engineering departments?
...until things start to break. Data is lost. Performance is poor. Customers are irate. Your department heads need answers, and you can't explain what's going wrong...
Some time ago, when I was just a mere software developer, I sat in a conference room with a team of individuals facing a problem. Those at the table spoke hypothetically of a "solution" that might "look" a certain way and would "behave" according to specific business rules. When they were done speaking, I spun my laptop around and declared, "...like this?"
For a moment, they stared in silence, likely surprised I was able to put something together so quickly. Then, excitedly, they began pointing to the parts they wanted changed...
Memories are short.
It wasn't that long ago that we were all advocating for the advancement of "rapid prototyping" tools – the ability to quickly throw together a functional solution to prove out a concept, minus the cost of building out a team to turn dreams into reality. NoCode tools are simply the next evolutionary step in that paradigm. No, it doesn't make sense to build a business atop a NoCode application. Yes, it does make sense to let an engineering team use a NoCode tool to eliminate a lot of unnecessary front-end work!
At Wrapmate, we've used Retool to stitch together makeshift admin tools that interface with both native database connections and REST endpoints. Are they customer facing? No. Do we plan on using them long-term? Also, no. But perhaps most importantly: Do they solve a problem the team faced with minimal time and effort? Yes.
Like any innovative technology, it is up to us to inform our non-technical peers what strengths and weaknesses lie in pursuing these tools, but that only happens when we have a seat at the table. Non-technical founders that eschew in-house engineering expertise in lieu of NoCode tools to run their business "because it is totally fine" will likely face the music at some point (you have been warned!) By choosing to do it yourself, you've elected to not have engineering in your corner, to be your voice at the table that says "if we do this, here is how we will suffer in the long term, and are we willing to cut that corner?" And to those who choose that path, Godspeed.
As for those in technology that do leverage NoCode, you will discover that much of what you are already doing can be greatly accelerated. As long as you understand the repercussions, why not?
Technology leaders that thoughtfully embrace NoCode tools will ultimately pull ahead of their more bullheaded counterparts. They will be able to solve tooling issues with less effort and experiment faster...at far less a cost to their organization. Leveraging NoCode in this way doesn't threaten a programming staff, it frees them – to focus building the robust, scalable product that a NoCode solution never intended to replace.