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 when someone changes the function , do you fiddle about with the weird-ish 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 are not ephemeral. Indeed, they can be imagined to be more permanent than the system they test. They may confirm that a system continues to be valuable, and a system's value can outlast any part of its code.
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.
Testing is a business of experimentation.
To set up those experiments, we regularly deal with ephemeral data. If your organisation supports it, ephemeral environments enable new classes of experiments. Ephemeral tools open our access to further experiments – allowing us to trigger and to observe in ways that we can't with our slow and impatient senses.
Ephemeral tooling isn't for production. That would mean that it's nether ephemeral, nor tooling... but that's semantics. And I learnt a bunch of tiny tools from midnight ops gangs who kept various very-production overnight batches running.
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.