No Code is the Future
Do we really want code or is tooling just failing us?
I’ve highly discouraged no-code or low-code tools. Of course I want to set up my infrastructure with an aesthetically pleasing UI. Of course I’d prefer to set up jobs and workflows with a couple clicks. Unfortunately, tools today provide me a UI but I’m deprived of versioning, templating, and making quick modifications in bulk.
Do we really despise no-code, or are we just frustrated at its limitations?
Example 1: Infrastructure as code
Infrastructure as code with tools like Terraform and Pulumi allow engineers to: review any changes made to infrastructure by other team members, version changes which help debug issues, and holistically understand all the pieces of infrastructure being impacted by a proposed change. But why? The AWS console is daunting. GCP is a bit easier, but still unintuitive. Fivetran’s UI is easy to use, but has no sense of configuration history or configuration changes.
When trying to whitelist one IP to multiple services in AWS, it’s unclear whether you are creating just a security group or also an IAM policy and policy attachment. If that one IP changes, knowing where it’s referenced is like finding a needle in a haystack (or extreme trial and error by connecting to services and waiting for the 2-minute timeout).
Code enables engineers to create highly visible and configurable systems that are safe guarded by pull requests. Today’s tools don’t enable the same level of configuration and safe guards because user experiences are meant to onboard quickly, not create barriers. In some cases, like IaC, those barriers exist by design.
Infrastructure as code is a means to an end. IaC allows developers to version and control infrastructure changes, and developers already code and oftentimes prefer it. But if a UI (for instance, Fivetran’s UI) had all the same functionality but could address the issue faster, would anyone really be opposed? The preference isn’t towards code, but rather a symptom of doubts that a UI could really compete with the versatility of code.
Example 2: Configuration as code
Configuration is everywhere in a developer’s workflow. Developers configure containers (Docker), configure unit tests (CircleCI/TravisCI), and even analytics engineers write configurations with dbt. This is all done with YAML, a configuration language that’s coded. It’s meant to be versatile enough to configure everything from containers to tests, while using the features of coding workflows like version control and reviewing changes.
YAML is wonderfully versatile, but who really likes debugging a misconfigured YAML file? There is no UI today to replace all the functionality YAML provides. Developing a UI to replace a configuration language is a tall order. I bet even thinking about configuration as a user experience is making many of you cringe. The cringe likely comes from an assumption that a UI necessarily removes key functionality like versioning and reviewing changes. But what if it didn’t?
Everyone usually prefers the approach that’s faster as long as it doesn’t compromise scalability and governance. If such an approach existed, and happened to be a UI, is there too much bias that there’s no surmounting pre-existing opposition? My optimistic nature hopes not.
Everything-as-code focuses on the solution not the problem
Let’s go back to first principles. Everything-as-code tries to bring version control and reusability to, well, everything. In the current state of the world, version control only exists for code. So really, the issue is no version control for configuration, infrastructure, etc which has often been implemented in a UI. We have version control for code, so I see why it’s a natural inclination.
It’s a solution, but I do not believe it’s the solution. Everyone isn’t going to code, but everyone can benefit from version control. I was inspired by a recent post by Jeffrey Schwab, pushing technical users away from no-code solutions.
In today’s world, I completely agree. A world without version control, diffs, or reviews isn’t a world I want to live in. There’s no denying that code isn’t going to solve these issues for everyone as it does have a high barrier to entry. Learning to code is easier today than it was 10 years ago, but that doesn’t mean it’s easy. The SaaS revolution continues, which in parallel gives rise to no-code and low-code tools. No-code does not have to mean no logic, elegantly put in an article by Greg Meyer. As no-code scales and is increasingly end-customer facing, users of the tools will be forced to develop best practices to make sure manual work doesn’t scale with complexity.
Does the no-code world have to be a world without version control and peer reviews? I don’t think so.
Thanks for reading! If you have any opinions on the topic, please reach out. I’d love to hear from you.