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.