Some History of No-Code & the Current No-Code Attitude

Pretty much since the beginning of computer science, coders have tried to invent ways to code less. If you haven’t had the conversation with your fellow developers about how long until we have an AI system spit out a no-code UI integrated with some sort of low-code automation system, then you probably haven’t found yourself on the bad end of a 24-hour coding binge on the project that just can’t be saved. 🤣

While the explosion of Zapier and IFTTT feels like a watershed moment in the history of no-code, its roots are, of course, much deeper.

For myself, I was first mind-blown on a project where we made use of Together/J from TogetherSoft.

Together was, at first impression, a pretty decent UML modeling tool. Plenty of other modeling tools existed, some might have even been better. But Together’s killer feature was a really good round-trip engineering engine that let you go from diagram to code and from code to diagram - and it was pretty darn good.

But alas, there was so much more to writing good code than what Together could generate - at least without making your diagrams ugly. There wasn’t a good way for Together to know when catching and handling an exception was a good idea. So, in the end, it was great to lay down some boilerplate code from a diagram that you would later help grow up into real code.

Arpit Choudhury, in his history of no-code, places the beginning of the movement at the feet of WordPress.

Server-Side No-Code, or automation and orchestration, has a fuzzier past because it’s hard to say when it really began. Some BPM tools had graphical designers and I’m thus far unsuccessful trying to locate the first.

For my part, the first automation tool that slapped me in the face as to what the future might hold was Yahoo! Pipes. Pipes was a visual tool for mashing up internet data and creating an aggregated output. Within a few years, the likes of IFTTT and Zapier were formed and shortly made major waves.

Why Engineering Shouldn’t Hate (the idea of) No-Code

Focus on the fun parts

As an engineer, I’d rather focus on what makes my company great. If I can offload what isn’t core to my business that’s a win for me. More than just the tedious tasks, even some very important, very impactful software is still not part of the core business - it should be analyzed for opportunity cost. As a leader of engineers, I’m constantly watching for what I want my engineers to actually write and what they might be able to buy.

Of course, there are caveats here, but more on those later.

Much easier to document/understand

Our industry spends millions of dollars on documentation around APIs. To make APIs easier, we wrap them with SDKs. Then we spend a few more millions of dollars documenting, packaging and maintaining the SDKs. And still, we find sites like StackOverflow filled with Q&A about working with services.

As a consumer of no-code tools, they allow me to consume an API without any of the startup costs - I only have to learn the actions available and what I want to pass into each parameter.

As the producer of an API, integration with no-code tools allows me to better express how my API was intended to be used.

Put these together and it seems like the software development world should love no-code for integrated SaaS type web services.

Turn over a bit of control 😬

In contrast to my first point, there are also many tedious tasks that go into running a business. We’re not talking mission-critical, must-be bullet-proof, real-time processing code - we’re talking about the registration form for the preview webinar of the upcoming release. These are the tasks we love to avoid.

No-code offers the promise of actually allowing us to turn some of the control over to those who deserve to control it. Have a CEO that likes to change the landing page every third day? (I don’t, I’m just thinking you might) No-code CMS tools might save you some headaches. Not settled on how your sales funnel will work exactly? Use an automation tool to let you easily change it.

Why Engineering Should Hate (the current state of) No-Code

No-code has really come a long way in the last 7-8 years, led by founders seeking to find product/market fit quickly and nimbly. Dozens of tools have emerged helping to fill this specific gap. Unfortunately, the current view by most IT professionals is that no-code tools provide stop-gaps to a “real engineered solution” - often, the no-code solution is cataloged as technical debt to someday be remediated. Unfortunately, this isn’t wrong thinking. Given the current state of no-code tooling, it’s impossible to engineer a solid platform. Here are a few places I think the industry is lacking:

Loss of flexibility

One reason engineers like to have good old-fashioned code available is that we can do almost anything our minds can conceive. We can’t imagine a programming language without branch logic, looping and other flow control tools. As engineers, we prefer to organize our logic in manageable chunks to maximize reuse and increase maintainability. And we’re certainly anxious about any black boxes that don’t let us glimpse what’s really happening and offer no easy path to exit.

Depending on your selection of no-code tools, you might get some of these needs met, but you won’t find anything that gives similar flexibility to code.

No real error handling

Also stemming from our natural desire for control, no engineer is going to feel comfortable without the ability to handle errors gracefully and recover from issues with a clear plan.

Security!

One major area that no-code tools (and, to be fair, many API systems) need to spend more time is the security aspects. This isn’t a simple matter of good authentication practices. Because no-code tools often act as a middleware orchestrating across many systems, the attack surface is large and prize is huge.

No-code tools require connections to all the SaaS tools you require to serve your customers. Because the system you use to build your app is often the same system running the deployed code for your users, the attack pathway can theoretically be extended to include credentials across all your connections.

Executing dynamic code comes with its own set of concerns and if your no-code tool is multi-tenant, these risks are extended across all fellow clients of the platform.

If you plan to use the app integrations at a low level (something like Kafka or database access) and you aren’t deploying on-premises, exposing your internal tooling on the internet becomes a huge risk.

I’m not an infosec professional, but I rely on their expertise and have learned much in my career. If you are building with no-code and especially if you will have customer or private data - please spend some time with an infosec consultant. Sending your customers an apology note for a security breach in the early days of your company can be devastating.

Monitoring & Operations

Hand-in-glove with some earlier points, No-Code tools need better means to ensure things are functioning properly. It’s never long before a small automation takes on a mission-critical role. Or, if you are building a full customer UI using no-code, then responding to outages from your no-code platform is a real thing.

The double-edged sword to growth is that you have clearly found the right product fit but you need the tools and staff to support everything with more and more clients. This may be one of the most sleepless times for technical founders. Every day you wake up hoping everything is still up and running while you are shoring up the foundations.

The lack of ability to monitor and respond to no-code issues is a major flaw. The hole is big enough that startups are popping up to fill this gap for technical operations teams that need to manage no-code deployments.

The Path Forward

At WhenThen we believe in the power of no-code and the future it promises for all means of software development. But for all that promise, it’s time for no-code to grow up into the tool we know it can be. Three things I’d like to see out of no-code over the next year:

Security at the Start

When evaluating a platform or tool to build with, look for one with a proven track record from security and operations-minded teams. Not just a tool that hasn’t had a breach yet - look at the security and data privacy teams for real roots in understanding what it means to keep your data secure. And beyond data security - look for tools that aren’t trying to be a black box but aim to give you the tools you need to sleep at night and dream about the future.

It’s Time for Standards

The last decade or so can rightfully be called the Age of APIs. SaaS as we know it would not be nearly as useful nor as vibrant if not for the attention given to open APIs and standardized connectivity. OAuth, Swagger (OpenAPI), OpenID and many other standards around API enablement helped usher in a world in which developers can generate connectivity code and think about APIs, in the same manner, they would a local library.

Make no bones about it, it was the standards and the adoption of the standards that made it all possible and the same is true for the next phase of API enablement - no-code and automation.

We need a few standards that will help build consensus and adoption. We need a layer on top of the API definition that describes the events (triggers) and actions (operations) a service supports. We need to offer the next generation of API documentation that demonstrates the flow and usage of the API in question. A better way for developers to understand how a service is meant to be used right inside the tools we’re using to call it.

On-Ramps and Off-Ramps

The final standard I’d like to see is one of portability. We need a way to describe automation logic in a portable means. A way to bring logic into my tools of choice and eject my way out when the time calls.

Summary

Folks building no-code tools right now must feel like they are sitting on the cone of a rocket ship; I know I do. The breadth of tools and how quickly the landscape is changing only makes me more bullish that no-code/low-code/automation is the future. If we, as an industry, can start making some important changes, we can avoid many of the troubles paradigm-changing trends have faced.