Somebody typed it into a text box

There were six things on the list and I’d checked five of them properly.

The sixth was a callout style, 30 lines of CSS whose class name appeared nowhere in the repository. I had my finger on it for most of an afternoon.

It was in use on exactly one page. The page was the one about their accreditation, which is the page the whole business hangs on, because without the accreditation they don’t get to do the work at all. Somebody had typed the class into a text box in the CMS five years earlier. It had been coming out of the database every day since, invisible to grep and therefore invisible to me.

That was three days in November, on a maintenance retainer, spent almost entirely deleting. A campaign microsite from 2016. An integration with a mailing platform they stopped paying for in 2018 and which was still initializing on every page load. Two JavaScript libraries. A print stylesheet superseded by a better one and never removed. About 900 lines of CSS.

The site does exactly what it did before. It’s about 140 KB lighter for every visitor. It makes four fewer requests to other companies, which is a number I’d been going on about for a year without ever getting to do anything about.

Then the question came back through our account manager, which is where these always come from. What did they get for the three days? Not unkindly and not suspiciously. It’s a completely fair question. It’s the question that makes this kind of work vanish everywhere it vanishes, which is nearly everywhere.

So why does nobody delete anything?

I don’t think it’s laziness. The payoff is genuinely hostile.

If you delete something and nothing happens, which is the successful outcome, nothing happens. There’s no demo. There’s no screenshot for the case study. Nobody in the business notices, because the whole point is that nobody was using it.

If you delete something one person was using, you broke the site, and it’s identifiably your fault, and there’s a commit with your name on it.

So the expected value of deleting is a small invisible gain against a small visible catastrophe, and every rational person leaves it alone. Multiply that by a few years and a couple of staff changes and you get every codebase I have ever inherited.

The other half of it is that you can’t prove a thing is unused, which I ran into from the other direction when I was arguing myself into utility classes. Not from the code, anyway. The class might be typed into a content field. The endpoint might be hit by a script somebody wrote in 2017. Absence of evidence, and all that.

Which is true. It’s the reason to be careful instead of the reason not to bother, because “we can’t be certain” is how an attic happens.

Ask the site, not the code

Four things I do now, in the order I reach for them.

Ask the analytics, and ask about features, not code. The events page with 14 visits this year. The filter nobody touches. The account area with 40 registrations, 38 of which are staff. This is the highest-yield source by a distance. It belongs to the client, not to you, which makes it persuasive in a way your opinion isn’t.

Use the coverage panel in DevTools. The browser will tell you which bytes of the CSS and JavaScript actually ran on a given page. It’s a snapshot of one page, not a verdict. So you have to walk the site and accumulate, and it’s still the fastest way to find a whole stylesheet nobody has needed since 2018.

Search everywhere, not just the repository. This is the step people skip and it’s the one that saved me in November. Grep the codebase, sure, and then go and search the content too, because a class name somebody typed into a WYSIWYG field in 2015 is invisible to every tool you own. I’ve written before about the CMS undoing the site, and this is the same mechanism pointed the other way. If the content can add markup the code has never heard of, then it can keep markup alive that the code thinks is dead.

And when you still can’t tell, instrument it. Add a line that records a hit, release it, wait a month, go and look. It’s the honest answer and it’s the one I use for anything that makes me nervous. A month is nothing on a codebase this old, and “this was called zero times in November” is an argument nobody can counter.

One deletion, one commit

This is what makes the rest of it cheap, and it’s the one I’d argue hardest for.

A deletion goes in a commit that does nothing else. No tidying while you’re in there, no small fix, no rename. Just the removal, and a message saying what came out and how you established it was dead.

git log

Remove the 2016 campaign microsite and its assets

6 templates, a stylesheet and 9 images from the fall 2016 push. The
routes were already 404ing; these were orphaned when the URLs were
retired. Instrumented for a month and got zero hits.

If something turns out to have referenced these, revert this commit
and nothing else is affected.

Text

That last line is the whole trick. An isolated deletion is the most reversible change in software. One revert, a few seconds, nothing to untangle. It’s the mixed commit that makes deleting frightening, because reverting it takes three things you wanted with it. Same argument I was making a couple of years ago about a commit that does four things, except the reader here is somebody in a hurry who has just found out something is missing.

Which means the fear people have about deleting is mostly fear of the process, not of the deletion, and the process is fixable.

Selling a subtraction

Back to the question, now that I’ve had a month to think of the answer I should have given.

“Removed unused code” describes my afternoon. It isn’t a benefit. I’d be skeptical of it too if somebody handed me a statement with that on it.

The version that works is risk and speed, in the client’s own terms:

“We removed a connection to a mailing service you stopped using two years ago that was still loading on every page. That’s four fewer outside companies your site depends on to draw, 140 KB less for every visitor to download, and two fewer things that can break at 3 am. It also means there’s less to update when we do the security work in January.”

Every clause in that is a thing they can evaluate without knowing what a stylesheet is. None of it mentions code.

I also asked for it to go on the statement as its own line instead of being folded into “maintenance.” I’d argue for that again. A line item is a thing that exists and gets discussed. A fold is a thing that gets cut the first month somebody goes looking for savings.

What I’d take out first

Dependencies come first, because every one of them is an update obligation and a supply chain nobody audited. Then features, because a feature is a thing somebody has to keep working and answer questions about forever. Then settings and flags for experiments that concluded years ago. Then dead CSS, which is the biggest by volume and the least important by risk, and which is where everybody starts anyway, because it’s the one you can see.

Commented-out code doesn’t even make the list. Delete it on sight. That’s what git is for and has been for 15 years.

The callout style is still there. I put a comment above it naming the page that uses it and saying how I found out, which took two minutes and is probably the most useful thing I did all week, because the next person to open that file gets to skip my afternoon.

At the risk of sounding like a weirdo about it, this is the part of the job I enjoy most. I don’t get anything like it from adding. A week that ends with a smaller site doing exactly what it did at the start of it is the only kind of progress I can check all the way down. The problem was never that I don’t want to do it. It’s that I’m bad at saying out loud what it was worth. I’d rather get better at that than keep leaving attics for whoever comes after me.