I really wanted to like this post. It's well written. With passion. Using a common metaphor (a house). And about the biggest elephant in the I.T. room today. B

I really wanted to like this post. It's well written. With passion. Using a common metaphor (a house). And about the biggest elephant in the I.T. room today. But I couldn't. Because it just skated on the surface of the iceberg. OP is right. Technical debt is a huge problem that requires significant mind shift to address. And I can't find a single thing here that I'd disagree with. There's a lot of academic theory and cheer leading here. And true, it's requisite to any further discussion. But what I would love to see are specific prescriptions: How do you train to avoid the sins of the past? How do you enhance process (peer review, QA)? How do you conduct post-mortems to organize the attack? How do you decide what to black box and what to rewrite? How do you prioritize shoring up the foundation and keeping the lights on? How do you find tools to automate the process? How do you make technology decisions to set the new path? And probably most of all: How do you fix the broken data supporting all this bad code? Because any treatment of code without diving deeply into the underlying data structure is too myoptic to be of much value. I've estimated that half of the bad legacy code I've ever encountered would never have even been written if the data were properly structured in the first place. This isn't a discussion of DBMS technology, but a comprehensive treatment of how the business operates and how it's supporting data must be structured, regardless of technology. Fix the data and the code becomes a much more manageable problem to attack. Of course, maybe OP just didn't get that far. Nice article. I'd love to read the sequel, about 5 levels deeper.