I feel like I’m reading a rough draft, not a deeply thought out piece of writing. There are some nuggets of good sounding information in here, but the author do

I feel like I’m reading a rough draft, not a deeply thought out piece of writing. There are some nuggets of good sounding information in here, but the author doesn’t really go very deep. Chad Fowler had an interesting slide in one of his talks (circa 2009 I think) where he had a graph of something like frequency of errors produced by working code versus number of changes to that code. Code could end up in one of four quadrants: - frequent changes, lots of errors: suggesting that the domain was still being discovered or there were quality issues - frequent changes, few errors: suggesting the domain was changing or growing but quality was good - few changes, lots of errors: suggesting that the code was not adequately maintained or even understood, perhaps poor quality as well - few changes, few errors: this is the “legacy” code that works hard and costs less to keep running Clearly it’s a good thing to have that “legacy” code, by this definition, but I remember that he listed some downsides as well, but not the downsides that the junior dev who wants to rewrite then whole system comes up with. Edit: I think it might have been "Measuring & Analyzing Things That Matter When You Have Too Many Things To Keep Track Of" At 36:00, he talks about a ruby gem called for Rails "Turbulence" that measures code complexity against number of modifications https://vimeo.com/38252887#t=2160s https://vimeo.com/38252887#t=2160s He also references this article by Michael Feathers: "Getting Empirical about Refactoring" https://www.stickyminds.com/article/getting-empirical-about-refactoring https://www.stickyminds.com/article/getting-empirical-about-...