2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns – Half-Day Sessions
2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- November 14, 2018
- Refactor Legacy Code
Sometimes, when an important project is going poorly there’s a desire to start over. Sometimes this comes from management but often this comes from the developers themselves. They say if they only had a second chance and could start over then they can build the right system.
But that almost never happens. Take it from me. I’ve seen companies try many times and I can say that without exception, when a team sets out to rebuild the same system with basically the same approach, they end up with roughly the same system the started with, including the same problems only this time they have two systems they have to maintain.
Boy, I could tell you stories… Want to guess how many CRMs Microsoft had under development in the early 2000s? At one point, I counted a dozen. Twelve projects that basically did the same thing!
Legacy code gets a bad rap. People are scared to touch it but it embodies business rules and procedures that are time-tested, and even the most intractable legacy code may still hold value when used to refactor a system.
Refactoring gets a bad rap as well because developers and managers are unfamiliar with it. They don’t know that there are safe ways of reorganizing their “big balls of mud” that their software has become into more manageable chunks that are independently verifiable and therefore less costly to maintain and extend.
Refactoring legacy code is often a process of breaking it up. It might have been written procedurally and worked fine for years but then, in order to improve the build and support continuous integration, code needs to be broken up into independently verifiable parts.
Don’t worry. The hard part is over. The software does what it needs to do so refactoring it is really just a matter of reorganizing it. That doesn’t mean it isn’t easy or risk-free but there are ways of dealing with the issues that come up and the benefits of making these changes can oftentimes give companies the competitive edge.
Think of it this way, most software is written procedurally and takes a global perspective. That’s fine for simple programs but as systems grow their complexity skyrockets so we needed a way to manage that complexity.
Object-oriented programming gives us a way of managing complexity by taking the behavior we want to create and putting it in a collection of “objects” that interact to create that behavior.
By doing this, we hide different parts of the system from each other. Instead of having one global perspective, object-oriented programs are composed of a collection of objects that interact to create the desired behavior.
By taking the additional step of encapsulating behavior into the right objects, we allow our systems to become more modular and independently testable through automation, which drops the cost of change for the software we produce.
This is by no means an easy task in most situations. Your legacy code got that way from years of neglect and it may take a bit of effort to clean it up but if it already does the right thing then often it’s a matter of reorganizing and restructuring the code so it’s in different places but the functionality remains the same. Reorganizing code is usually more straightforward than rewriting it from scratch.
Previous Post: « Buy or Build
Next Post: The Virtues of Laziness »