Editorial Note: I originally wrote this post for the SubMain blog. You can check out the original here, at their site. While you’re there, have a look around at some of the other posts and sign up for the feed.
During my younger days, I worked for a company that made a habit of strategic acquisition. They didn’t participate in Time Warner style mergers, but periodically they would purchase a smaller competitor or a related product. And on more than one occasion, I inherited the lead role for the assimilating software from one of these organizations. Lucky me, right?
If I think in terms of how to describe this to someone, a plumbing analogy comes to mind. Over the years, I have learned enough about plumbing to handle most tasks myself. And this has exposed me to the irony of discovering a small leak in a fitting plugged by grit or debris. I find this ironic because two wrongs make a right. A dirty, leaky fitting reaches sub-optimal equilibrium and you spring a leak when you clean it.
Legacy codebases have this issue as well. You inherit some acquired codebase, fix a tiny bug, and suddenly the defect flood gates open. And then you realize the perilousness of your situation.
While you might not have come by it in the same way that I did, I imagine you can relate. At some point or another, just about every developer has been thrust into supporting some creaky codebase. How should you handle this?