The Half-Life of Code (2017)

I've always been partial to the concept of ravioli code which I read about from John Papa. Contained modules that do a job that can be added or removed. You decide whether or not you need that modules fucntionality with no other module having a dependancy on other modules.

I agree with the spirit of this article, having a responsive code base with easily replaceable code. But this becomes a problem when you have a code base with sprawling legacy modules with essential functions for core customers that new code must interface with.

I worked for a company that attempted to incorporate agile methodology to add features on to a large legacy system to try and stay responsive to customer feedback. The problen was when new features were added we were only adding on to the "cruft" mentioned in the article. As unintentional as it was new code would start to tightly couple with legacy code. In spite of that we kept continuously adding new features with the predictable results of more tech debt, bugs and on-call catastrophes.

I'm all for responsive code that instantly reflects customer requirements but it requires a lot of discipline and planning.

Ideally, "legacy code" wouldnt exist at all and keeping a low half life should help with that. But in the real world, with people being the irrational, nepotic, lazy and self-deluding creatures we are, thats not going to happen. I'd caution anyone to really know what theyre doing before rationalizing poor design choices by thinking "it's not technical debt if were going to throw the code away anyway!"

I'm sure that's what the original authors were thinking when they wrote that awful legacy monstrosity you're dealing with now.

Over the years one of the most valuable questions I've asked myself as I've worked in long living codebases:

"If I had to delete this feature tomorrow how quickly could I do it?"

If you come back to this question a few times over development it does a wonderful job of really forcing you to consider your coupling and dependencies. In most cases it's been "delete a few dispatch calls and nuke the whole feature namespace" which has held up very well when future changes come down the pike.

I expected this to be a (welcomed) repost of a different article about the half-life of code. There was some good discussion in that post, and that article has charts which do a good job of showing a codebase’s evolution. Interesting stuff.

https://news.ycombinator.com/item?id=13112449