Refactoring agile fragile code is the gift that keeps on giving
I’ve been around the dev work block. There have been some good and fun projects. Then there have also been horror shows. But it doesn’t matter what feelings I have towards the code, they all have one thing in common — they all need to be refactored, eventually. Refactoring is one of those facts of life for all developers. At some point, we all encounter it. There’s no escaping and explaining the concept to upper management can be as equally challenging. For many non-techies, software is akin to an asset that’s built and paid for. For the software developer, it’s more like homeownership. At some point, the old pipes are going to leak, or you suddenly realize that building with asbestos was a bad idea.
Nothing is perfect. You might love the color scheme and architectural plans, but to a different set of eyes — it might just be an overload of hedonistic maximalist self-indulgent code that only made sense to its creator. So what can be done to create at least some sort of consensus? What lessons from refactoring have I learned that can be shared and might make a difference for future refactors? I have three words — three words that I wished someone had told me early in my software development days and something I live and die by nowadays when working in a team where refactoring becomes a factor: contract-driven development.
0 Comments