ClickOps: It's the worst

Me starting a project: Oh, cool, look at the gorgeous UI. I click everything together, until I’m done. Two years later, I want to change some features to keep the solution useful. Returning to the project, I realise the UI has been redesigned. I’m entirely out of luck to understand the default settings and my configuration. I have no idea what I’ve done before.

To update things, I have to relearn the UI and reverse engineer what I've done. This gets even more complicated when the solution involves authorisation. It is the perfect spot to change something that now leaks sensitive information or allows privilege escalation. A horrible place to be.

Configuring a system by clicking through a UI is called ClickOps between engineers. And we hate it. Through all my years of engineering, I learned: Never ever do ClickOps.

The better alternative is called Infrastructure as Code (IaC) and Configuration as Code (CaC). Use configs, check them into version control and automate as much as possible. It helps to

understand infrastructure without having access to the production systems,
replicate entire application environments with a click of a button,
rely on stable APIs instead of brand-related UIs that change frequently,
scale infrastructure without repetitive monkey work.

It sneaks in faster than you think. #

In various applications and software development environments, ClickOps quickly sneaks in without often realising it. In other words, it seems to be everywhere.

Cloud #

The most obvious ones are about infrastructure, especially the cloud. The core of the cloud is an API to deploy infrastructure. Yet, people use UIs to configure cloud environments. Why?

When you start with the cloud for the first time, the UI is the easiest and most straightforward way to get started. That's what the UI is for. You can explore, and you learn. So, no bad feelings here. But, building this way a production app is a bad idea. Please use Terraform, Pulumi, CloudFormation, etc. for infrastructure deployments or Ansible, etc. for low-level instance configuration.

Desktops #

In desktop development we use Visual Studio for Windows or XCode for macOS. These IDEs have buttons everywhere. Sure, these buttons change a config you can put into version control. Yet, the config by itself is internal jibberish. I can't read it without knowing about it's internals.

You find tons of articles^[1] explaining how to configure something, showing plenty of screenshots where to click next. These are great blog posts, but it runs cold down the back of my neck looking at all the screenshots. I have to search in a picture where to click next. It just feels wrong (so wrong). Luckily there is community driven work and advanced build systems which help to improve engineering practices.

Don't get me wrong, with a Linux setup, you get really weird commands. You have no idea what a flag does just by looking at it. For example, when configuring the SSH client Dropbear, use -s to disable passwords. What? Why s?! That makes no sense.

But this is a big one: When you work through the CLI, you end up with a shell script. It contains all necessary commands and comments for additional explanation. At best it highlights the version of the tools used. This setup can be executed, understood, recreated and even adapted in the future. It saves tons of time down the road.

And so many more #

There are so many more areas, which would blow up my article. Embedded development helps with some quick and easy setup of IDEs for beginners. They are great. Yet again, it'll hurt in the long run when you want to scale and go to production. And then there are so many legacy apps across all the stacks. They basically require ClickOps...

Shoutout to all providers offering an API, and shame on you if you don't #

Shoutout to all the providers and software vendors who embed APIs and IaC tooling for their customers. You rock.

For all others, by not shipping an API for your customers to use, you

slow down your customers. They can't innovate with you in a fast and scaled environment.
force your customers to ignore good engineering practices. It causes a complexity debt on their side.

Luckily, Developer Experience (DX) is an emerged job position. Startups heavily invest into it because they recognised the limitations listed above. Many of them who have to scale are on track here. But a lot of software is legacy, where it looks very different.

I have a list of some article examples which show images how to set something up. But I didn't link any of them, because it isn't their fault that they show screenshots. The authors did a great job. It's the providers building the ecosystem to blame. ↩︎