Ephemeral Tooling
There's a place in our world for tools that we throw away.
Which makes a nonsense of RoI. The investment is negligible, and we all know about divide-by-zero. So we don't seem to talk about them, and we don't necessarily share them, but we use them nonetheless.
Ever thrown a .csv into a spreadsheet, filtered it to know something then closed without saving? Ephemeral tool.
Ever piped a log into a grep to look for trouble with tail -F log.log | grep 'trouble'? Ephemeral tool.
Ever pasted a bunch of (sanitised) data into a regex website to build a regex, get immediate feedback on whether the regex is right, then use the regex to look for data – and when you've found the data, chucked away the regex? Ephemeral tool.
Ever asked an LLM for a web page to make a graphical interface to a new function? Well... only since 2024, at a guess. And if you have, is it easier when the function changes to fiddle about with the slightly weird LLM-generated page code to make a matching change, or do you just... regenerate it?
You see where I'm going here.
Since the advent of LLMs that can barf out fairly-OK code, fairly-OK code has become vanishingly cheap (if one ignores for the sake of rhetoric, the environmental impact of one's query and the social impact of having the tool at all). And if code is cheap, then it might be cheaper to chuck it away and start again than to engage in maintenance. Ephemeral tool.
Automated tests, when designed to be run throughout the life of a system (more properly, run while the values they reflect are still in play) are not ephemeral. Indeed, they can be imagined to be more permanent than the system they test.
Risks, though, should be temporary. I've seen a weird resistance to tooling up to look for trouble, perhaps because the Return part of the RoI is lumpy – generally zilch, occasionally zillions. Once the Investment part is tiny, though, off we go.
So we're perhaps at an inflection point; it's time to talk about how we do this.
I think that – in testing – we might often know how to do ephemeral environments, and we certainly know how to do ephemeral data. Some organisations can spin up collections of servers in patterns and with configurations to suit targeted experiments, allowing them to anticipate what their customer-facing systems will do under usual and unusual conditions.
Ephemeral tools give us access to still more experiments.
Let's be clear that ephemeral tooling isn't for production. That would mean that it's nether ephemeral, nor tooling... but that's semantics.
These tiny tools offer swift access to novel experiments. The results of those experiments are likely to be as weird or weirder than the more-sold software they might test. We don't trust the output. We use the tools to hint to our judgement that something smells funny.
Sometimes, we use them to do jobs we can do (because they're faster, more relentless, more precise) so that we can free up our minds – ephemeral tooling lets us to use that power on one-off jobs, too.
In both cases, ephemeral tools don't need to have high quality to some end user: their value is in their high relevance to us. Easier accessibility and lower cost don't make such tools more useful or more compelling – they make them more feasible.
Weirdly, while I was planning this, I found an article I'd written in 2022, spun out of an idea from a writer named Mike Caulfield, and which I'd published in such a way as to be unfindable. I read it (didn't remember it), jiggled it and re-published it. Imagine my astonishment when this popped up today from his Substack:
Mike Caulfield
Different take, but how lovely. It ends with this, which reminds me of all the wrangling we do before we ever see a test pass, or fail.
My daughter took an AP computer class about 4 years back, and wrote a simulated card game — half the project was getting the Java development environment to compile the right dependencies. She went in excited about building things, and came out never wanting to touch code again. That stuff (IDE, dependencies, object-oriented design) is all important, but there’s just a lot of people who could at least start to engage with programming if the entry point was a bit easier.
There's more to come, and I'm hiding it behind a paywall that nobody but me can see. So you can subscribe to see more, but not from this article...
Comments
Sign in or become a Workroom Productions member to read and leave comments.