There's More Than One Way To Do It
I envision a world in which I can set things up in the AWS console (or really, any cloud vendor’s) via the magic of clicking things. The provider captures what I set up and renders it into code or configuration somewhere, similar to the way that the Console Recorder browser extension does. The provider becomes aware of what has been provisioned previously (and how!), then automatically generates diffs in the correct repository, or updates its CloudFormation/Terraform/CDK expression of the environment as it exists at the current moment.
– ClickOps on Last Week in AWS
This idea strikes a chord with me. Firstly, I’ve done my fair share of both manual and automated AWS wrangling, and so am very familiar with the frustrations Corey talks about in the article. Secondly, it has strong echos of my PhD work, the core idea of which was to allow programs to be manipulated via various different representations (textual, graphical, physical), allowing you to pick the most appropriate for the task at hand.
It’s long been settled that both GUIs and programmatic or command line interfaces have their place, with their own strengths and weaknesses, and each is better than the other for some tasks. However, there remains a fundamental disconnect, a bright line between the two domains. Moving between the two often involves starting from scratch, and even when it doesn’t is usually a one-time, one-way process that comes with mismatches and loss of fidelity.
A much better approach, of which ClickOps is an example, is to allow a variety of tools to be used together, working on the same underlying artefact, with minimal overhead switching between them. Projects like MakeCode Arcade and Mito are already showing fruit in this area, as are perhaps AirTable and its brethren. It seems like this is an idea who’s time has come, though there’s a lot still to do.