Hacker News Reader

Comment by kgeist | Hacker News Reader

The codebase of an internal system our team inherited is pretty old (14 years) and large, and there's a feeling a lot of the stuff is unused (dead code or unused ancient features) and can be deleted. Fortunately, it's a monolith and all that matters is HTTP endpoints defined in a few config files. So we've made a script which downloads all access logs from the live server for the last 3 months and tries to find endpoints with zero or very low usage (it did find quite a few unused or rarely used endpoints). I'm planning the second step to be a script which builds a dependency graph and finds everything which is only reachable from unused endpoints. I wanted it to be a one-time endeavor but this blog post made me think it should be run on a regular basis.

View on HN

Be very careful using this methodology. This is how you end up deleting stuff only called in rare but critical cases:

- during outage

- at end of year

- during audits

- when the one special customer that paid a fortune for an obscure feature decides to use it

It might be the case that none of this applies to your application, but it’s why “check what got hit recently” (3 months is an eye blink in the business and govt world) is dangerous.

Any important enough would be automatically tested daily, in a prod-like environment, and/or at release time, with humans on call

That seems an ambitious expectation for a 14-year old system.

This is why some sort of blacklist feature should exist to ignore such critical cases that are not intended to be deleted (but then again this defeats the purpose of the methodology).

This feature would then be abused by everyone and making the deletion script useless.

It's an internal tool, so if we delete something actually used by accident, they will let us know via the support desk or by visiting our office :) Sure it's dangerous but the code will still be there in git history, so it can be reverted, it's not deleted permanently. We're not planning to delete data. Before me, there was already an experiment when they modified code on a few pages to always return an error, to see if someone would complain - and no one did. In any case, there will be a human in the loop to double-check HTTP endpoints suggested for removal.

To add to that, it might be a net benefit to remove unused code even if it ends up breaking something for someone for a while.

This endeavour probably won't advance your career much, but making one's co-workers lives easier is worthwhile too!

"even if it ends up breaking something for someone for a while."

It really depends how urgent those people need that something at that moment (and how much they paid for it).

Otherwise this is just making dev life easier on the cost of their users.

Before deleting code, why not check who would call that code and why? But yeah, that is also work. (And not always worth the effort)

>Otherwise this is just making dev life easier on the cost of their users.

Not necessarily so, I'm expecting removal of dead code will enable faster delivery of new features, and also enable easier refactorings to make code more robust, because the dev team won't have to take unused features into consideration. The code we inherited is very complex and very brittle, so adding something often breaks something else and devs spend way too much time figuring out all the interdependencies. A major complaint is that the dev team doesn't deliver fast enough.

"I'm expecting removal of dead code will enable faster delivery of new features"

Well, for sure it does. Getting rid of bloat is always freeing energy - but only if it is really dead code. Otherwise you can introduce rare bugs, or break things in unexpected ways. And yes, sometimes the fastest way is to just try it out and see how things run. If it is not medical equipment, it might be fine even on a live system. It really depends on your project and users. But most users really like stability. Especially if they need that software at that moment, because they have deadlines as well.

>unused code even if it ends up breaking something for someone for a while.

There are industries where this mindset is business ending. It’s pretty much only high volume consumer markets where you can afford to have so little indifference to your customers.

Breaking customers in this way is also immoral. You have no idea how you are impacting their lives with your previously-working but now broken software. Everything is mission critical to someone.

It’s so refreshing to see that written out. This is my reality. For my business, which variously runs email, e-commerce, DNS, and similar for other businesses, our services are mission critical for every customer, and they don’t expect us to touch things we don’t need to touch, or to do things they haven’t asked for specifically.

The idea of deleting code without a _thorough_ review of exactly where, why, and by whom it is used for what, is a non-starter. I wouldn’t think of deleting anything unless it was truly dead, and even then I’d take it offline and archive it so I knew what code touched customer data.

I actually enjoy this stability. I previously worked for a company with tens of millions of end users (at the time, on-prem and cloud solutions) and a code base stretching back for (at the time) almost 15 years. I don’t miss the pressures that came with that.

Edit: typo

Noticing that this is a real issue with your service, finding who to email, writing an email and waiting for the fix to be made/deployed can be a non-trivial amount of work that you seem to expect all of your users to be willing to donate.

OK, some context: it's a homegrown CRM used by sales, analytics and marketing departments + additional infrastructure services. We have a dedicated JIRA service desk just for it, with at least 1 dev always on call (because it's very buggy). All users learn how to open tickets during onboarding, so there's no need to find who to email. There's also direct communication between the team leads of CRM and other departments (+ monthly meetings). I agree that if we break their workflows it will waste everyone's time - that's why I'm not planning to make removals fully automatic without a human in the loop. The script's suggestions will have to be approved first. The thing is, during its 14 year course, there were added countless integrations that are long obsolete, features for very specific workflows which were asked by people who no longer work at the company, etc. Code was also written in a very brittle way ("big ball of mud"), so supporting all that code is a burden for the dev team - adding new features, or doing major refactorings to make code more robust, take much more time than it should be, because devs have to account for features no one actually uses. For example, currently there's a dev porting it to PHP8 and they have to go through every file to fix code which is broken by backward-incompatible changes in PHP8 - although some of that code is never actually called.

Once the code isn’t being continuously integrated, it will quickly stop compiling if you restore from vcs. Leaving endpoints in the codebase but intercepting calls and returning deprecation errors like your predecessors did is a nice middle-ground. Leave that running for as long as the stakes and usage patterns demand, then delete.

As others say- not suggesting you don’t delete. Delete is the best refactoring! Sounds like you’re already doing the sensible extra work of chasing consumers to check endpoints really aren’t used under any circumstances.

It would be great if consumer-driven contracts were more widely adopted, so we could move more confidently when deleting stuff. It’s a constant source of annoyance in large orgs how quickly we lose track of dependencies. Keeping visibility of lineage and dependencies has a great payoff if you can build it in from the start.

I'm a Googler owning a system with a "stop the robot uprising" button that we seem to press every couple years. Needs code in _a lot_ of microservices that looks dead for all intents and purposes. It gets a bit annoying in various reports, but telling Sensemann to never ask about these files again was as simple as copy-pasting a line from the description to a comment on the PR.

Exactly my though. OP is going to go from hero to zero at year end close.

I wonder if APM performance traces could be used to determine unused code paths.

A lot of these tools sample stack traces at intervals, collecting statistics of how often functions are used. If you had enough samples, then with very high confidence you could find code paths that are never used in production.

Another option is tail based sampling which allows you to make the choice at the end of the request whether to keep the trace.

With that you could configure the APM to keep the first $N traces for all endpoints and then start sampling after that

That’s an interesting idea! Reminds me of how Pyroscope’s continuous profiling data can be linked to OpenTelemetry traces[1].

[1]: https://pyroscope.io/docs/java-tracing/

Happy to see someone applying some science to our field instead of just going with a hunch.

That said, as kortilla already mentioned, in most cases 3 months is too short time to get a complete answer.

IIRC "Principles of Network and System Administration" by Mark Burgess has more about it, but intuitively you have to look for the largest cycles that exist, but there is also, again as mentioned by kortilla, events that doesn't happen on a schedule.

One thing I try to do is, when I come across code that I have to research is to write down in the documentation for the function (Javadoc or similar) why it exist and the conditions when it can be deleted.

You can also try to add some instrumentation code that notifies you when something is called. That way you can end up like me who, every new years day get a weird sms message at 14:00 or 14:01 from a system that no one can find, but at least I know that some system I cannot remember anymore still runs somewhere :-)

Seems a good methodology, a caveat would be the deletion should start in coeff * 14 years from time of watch start, where coeff is a project complexity coefficient. If the watcher doesn't see a part of code called in another coeff * 14 years, then it's probably safe to delete it.

Reply on news.ycombinator.com