Give your stopgaps an expiry date

We called them temp scripts.

They were for fixing data - a bad import, a bug that caused drift, the system allowing users to get data into a bit of a mess. Someone wrote a script, ran it, and moved on. It was quick and addressed the data issues head on.

The name was a lie. Many of the temp scripts found life beyond that initial run.

Temp scripts were created because there was no other way for the work to happen.

Fields that couldn’t be edited in the UI. Journeys that didn’t exist, so data couldn’t be changed once an account was created. Bulk updates that would take an end user hundreds of hours to do manually, but a script could do it in a few minutes.

These aren’t problems with the UX. The tools didn’t exist at all, so we had to find another way.

What seemed like a routine operational task ended up requiring engineering work. This pointed to a gap we hadn’t filled.

If a routine operational task can only be done by raising a ticket with engineering, that’s a screen you haven’t built.

The script fills the gap, and it does the job. What nothing ever said was how long it was supposed to be there.

Engineers would periodically go through and call out temp scripts that hadn’t been used in a while, so they could be cleared out. This was a message on Slack - and you had to be quick to save a script from deletion.

I was always surprised how quickly we tried to remove the scripts without knowing if they had a long-term equivalent. The job might not be a frequent task, but delete the script, and it doesn’t make the job go away. It goes back to being a request to engineering - and we’ve now lost the code that previously addressed it.

There was a middle tier available - a system job, for things meant to outlast a temp script but not enough to justify a proper screen. Or perhaps they were intended as “we need a screen but we’ve not built one yet”. These were underused, likely because it was unclear when something was suitable for this category.

The result was a long list of tools with no stated lifespan, cleaned up when someone thought it looked a bit too long, and defended in a Slack post.

Years earlier, at printed.com, I built something called Snapshot. A live view of the day’s orders and sales figures, sat as the first screen you saw in the staff section.

Nobody asked for it. I built it in my own time.

Before Snapshot, sales figures were only discussed by a few people, and otherwise sat behind a report that most of the team never ran. With Snapshot, the figures were on TV screens around the office, and people cared about them. There was also a chat box so staff could post short messages to each other. It was the most popular thing I built there.

I left in 2014. It ran for at least another five or six years.

I didn’t go into it with a long-term plan. It was an experiment that worked, and then it kept working. It wasn’t in anyone’s plans, and it outlasted almost everything else I built there.

That is the same disconnect as the temp scripts. The scripts were meant to be short-lived and weren’t. Snapshot was never meant to be anything in particular, and it ran for years after I’d gone. Neither lifespan was a decision. They both just happened.

Snapshot changed how the company saw its own numbers - they stopped being the property of a few people. What it didn’t change was what got built next. The founder didn’t take it as a steer to invest more in staff tools. He kept pushing the catalogue, because adding products drove sales, and everything else was a by-product of that.

He wasn’t wrong, either. That’s what makes this hard rather than annoying. Internal tooling rarely loses to a bad argument. It loses to a better one.

If a tool can’t win on priority, it can at least stop being invisible. What was missing in both cases was not budget. It was a stated intention about lifespan.

Three labels would have covered almost everything:

1. One-off, with an expiry. Written for a specific incident. Safe to delete after a date you set when you write it.

2. Keep for now. Used rarely, still needed. Gets a review date rather than an expiry - if nobody has run it by then, it goes.

3. Should be a screen. A standing gap in the product, currently being covered by a script.

None of that existed in our code or as metadata on the screens. It lived in the memory of whoever wrote the thing, and got resolved on Slack when someone proposed a tidyup.

The third label is the one that matters. A list of “should be a screen” scripts is a backlog of missing product items, written by the people who hit the gap most often, with evidence attached in the form of how often the script gets run. That is a far better case than a PM saying the admin screens need work.

Temporary is a decision. In most of the systems I’ve worked in, nobody ever made it.

You don’t need permission to say how long something should last. You just need to write it down.

Product Notes is free and lands every week. Subscribe to get it in your inbox.