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.

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!

>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

"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.

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.

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.

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.

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

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