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
- January 3, 2018
- Refactor Legacy Code
As Frank Herbert said in Dune, “Fear is the mind-killer.” He could have been talking about legacy code. As soon as we fear touching legacy code, we won’t do it.
As a consultant, I know that merely giving my clients tools and techniques for working with legacy code isn’t enough, I also have to help them get over the fear of working with legacy code. That can often be more challenging than teaching the skills to work with legacy code.
Most developers fear working with legacy code for good reason. They’ve had the experience of making a tiny change to an existing system only to see it sprout several bugs. The way most systems are built, a tiny, seemingly innocuous change to a system can cause unanticipated consequences. Breaking a system in production costs time and money, so we try to avoid it.
Most existing code is so intertwined that it’s very difficult to change. Without good automated tests, we have to manually retest the system, which can be expensive and time-consuming. This discourages last minute changes, which are often the most important to the customer.
It’s not easy, but we have to break this cycle. We have to find ways of restoring our confidence in legacy code and our ability to improve it. The problems that companies are facing with their existing code are not unique. I see the same challenges show up again and again on team after team. These are solvable problems. There are safe, disciplined ways of transforming legacy code into reliable, repeatable code. We just have to get over the fear of touching legacy code.
When we integrate continuously and we have reliable automated tests, whenever we have even the smallest bit of functionality we can make changes to code with confidence, knowing our tests will tell us if something breaks.
When we get instant feedback from our build and test suite whenever we make a change to any part of our system, the cost of making changes goes way down and developers no longer fear touching the code. And with version control we can always revert a system back to a previously known state, so the fear of making changes should go way down. With good test coverage, the fear should go down even more.
Once the fear to touch legacy code subsides then we realize there are ways of dealing with it. We can use known transformations to improve it safely. With effort, it is possible to improve legacy code so it’s more straightforward to work with and extend.
To learn more, check out my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.
Previous Post: « Flying Blind
Next Post: Doing More of What We Love »