Having put the words “legacy code” in the title of my book, people often confuse my book with Michael Feathers’ book, Working Effectively with Legacy Code.
On one hand, it’s great to be in such esteemed company. I love Michael’s book and I refer to it often. It’s full of great techniques for taming legacy code that most developers should know.
But my book is different, it’s not about that at all. My book is called Beyond Legacy Code and the keyword here is “beyond.” My book is about how to get beyond legacy code or how not build legacy code in the first place. It’s about the value of the technical practices and why agile software development requires specific technical practices in order to effectively build software incrementally.
I noticed there was a disconnect between developers and their managers in terms of understanding what the most valuable use of their time and energy is. My book discusses why the technical practices are valuable, both from a developer’s perspective and from a manager’s perspective, so that both developers and non-developers can get on the same page and understand why it’s valuable to do these practices.
This is the piece of information that I saw was missing in our industry. There are a lot of how-to books for software developers and managers. How-to learn a new language. How to use a framework. How to do the latest and greatest things. But I rarely see what I would call of why-to book that tells us why these practices are valuable in the first place.
This is what my book addresses, why the technical practices are valuable. And so it’s content is easily relatable to both software developers and non-developers who have an interest in the software industry, such as managers and executives.
The nine practices that I describe in my book help us build software more cost-effectively while also dropping the cost of ownership for the software that we build. Given that over 80% of the cost of software happens after it is released, dropping the cost of ownership for the software we build represents a major saving for most software development.
Although eight of the nine practices in my book do not directly address legacy code and only the last one, practice 9, Refactor Legacy Code, addresses legacy code directly, it’s important to understand the other eight practices first, before we address existing code, because, in order to refactor bad code into something better, we have to first understand what something better means. And so we spend most of the book discussing what good code is about and once we understand this we can look at legacy code and address how to refactor it safely using many of the same techniques that we discussed to create good code by simply apply it to our existing code.
When I ask software developers what they need to do to improve their existing software they often have a pretty good idea and when I asked them why they don’t do it they typically tell me it is because their manager or product owner won’t let them. We don’t want to refactor code needlessly but when we have a good reason to do it, such as the need to add new features to existing code, then we would like the opportunity to refactor that code first.
The next seven blog posts are based on the section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, called Seven Strategies for Helping You Justify Refactoring. These are things that you can say to your managers or executives that will help them understand when it’s valuable and cost-effective to refactor existing code.
Note: This blog post is based on one of the “Seven Strategies…” sections in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.
Previous Post: « Practice Good Development Habits
Next Post: Refactor to Learn an Existing System »