3 ms·

Speaking as someone who maintains a fair bit of legacy infrastructure for a living, the hard part is knowing what is unused and what isn't. That's the whole rat

Speaking as someone who maintains a fair bit of legacy infrastructure for a living, the hard part is knowing what is unused and what isn't. That's the whole rationale behind Linus' "don't break user space" policy.

duxup 5y ago
> knowing what is unused and what isn't Or what I run into “Is this used …. and does it even ‘work’?!?!”
- girvo 5y ago
  My "favourite" answers to those two questions at work are "yes" and "not really..." -- that's always a sign I'm going to have a fun week or two...
inopinatus 5y ago
Sounds like Chesterton's fence¹. [1] https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
- ketzo 5y ago
  Y'know, people always cite Chesterton's Fence, but they never talk about ways to figure out why the fence was there... that's the blog post I wanna read.
  - inopinatus 5y ago
    Good thought. Maybe people should learn to put some signage on the damn thing. “Beware of the bull”
    - a9h74j 5y ago
      Always comment your fences.
  - jka 5y ago
    It's a process and culture thing: maintain descriptive context and history about all changes, and ensure that references and hyperlinks within those are temporally stable (that is, they'll still refer to the same content when they're examined by a future observer). "Chesterton's Permalinked Fence" is generally straightforward to reason about.
KMag 5y ago
At my previous job, one of the nicest bits of kit was the moribund code logging system. You put a function call into the moribund logging library from a bit of code you thought was unused. The first time a process hit that line of code, it would fire off a UDP packet to a server, indicating the process name and the line hit. (It's nice to still have test coverage on the otherwise unused code, so it's great to see which processes are actually hitting the code.) Another system watched the version control system for who added that line of logging, and sent them status emails. After the moribund logging had been in production for two weeks, the emails turned into nag emails to either remove the code, or at least remove the moribund logging if you decided against removing the code.

duxup 5y ago

> knowing what is unused and what isn't Or what I run into “Is this used …. and does it even ‘work’?!?!”

girvo 5y ago
My "favourite" answers to those two questions at work are "yes" and "not really..." -- that's always a sign I'm going to have a fun week or two...

inopinatus 5y ago

Sounds like Chesterton's fence¹. [1] https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence

ketzo 5y ago
Y'know, people always cite Chesterton's Fence, but they never talk about ways to figure out why the fence was there... that's the blog post I wanna read.
- inopinatus 5y ago
  Good thought. Maybe people should learn to put some signage on the damn thing. “Beware of the bull”
  - a9h74j 5y ago
    Always comment your fences.
- jka 5y ago
  It's a process and culture thing: maintain descriptive context and history about all changes, and ensure that references and hyperlinks within those are temporally stable (that is, they'll still refer to the same content when they're examined by a future observer). "Chesterton's Permalinked Fence" is generally straightforward to reason about.

KMag 5y ago

At my previous job, one of the nicest bits of kit was the moribund code logging system. You put a function call into the moribund logging library from a bit of code you thought was unused. The first time a process hit that line of code, it would fire off a UDP packet to a server, indicating the process name and the line hit. (It's nice to still have test coverage on the otherwise unused code, so it's great to see which processes are actually hitting the code.) Another system watched the version control system for who added that line of logging, and sent them status emails. After the moribund logging had been in production for two weeks, the emails turned into nag emails to either remove the code, or at least remove the moribund logging if you decided against removing the code.