3 ms·

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 - duri

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.

tantalor 4y ago
Any important enough would be automatically tested daily, in a prod-like environment, and/or at release time, with humans on call
- ukuina 4y ago
  That seems an ambitious expectation for a 14-year old system.
- deleted 4y ago
  [deleted]
am1n0 4y ago
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).
- ishan28mkip 4y ago
  This feature would then be abused by everyone and making the deletion script useless.
kgeist 4y ago
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.
- tasuki 4y ago
  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!
  - hutzlibu 4y ago
    "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)
    - kgeist 4y ago
      >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.
      - hutzlibu 4y ago
        "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.
  - 4y ago
lrem 4y ago
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.
mberning 4y ago
Exactly my though. OP is going to go from hero to zero at year end close.

tantalor 4y ago

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

ukuina 4y ago
That seems an ambitious expectation for a 14-year old system.
deleted 4y ago
[deleted]

am1n0 4y ago

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

ishan28mkip 4y ago
This feature would then be abused by everyone and making the deletion script useless.

kgeist 4y ago

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.

tasuki 4y ago
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!
- hutzlibu 4y ago
  "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)
  - kgeist 4y ago
    >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.
    - hutzlibu 4y ago
      "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.
- 4y ago

lrem 4y ago

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.

mberning 4y ago

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