If you've ever joined a team of developers, a company that had developers, or taken over a open source project that's long in the tooth then you've dealt with legacy code. It's something that I've dealt with my entire professional career, starting with my first Rails job. The first company I worked for had been using PHP and decided their future was in the Rails framework. The lead developer, probably the best example of all-star cowboy coder, started this process by first using Rails 2.1. It's within this mix of half-PHP and half-old-rails I found my loathing for Legacy code.
When I was younger and working for this first company I looked at this old, inefficient and messy code and only saw pain. I wanted to sweep out all the bad stuff and replace it with my own finely tuned junior engineer work. While my perception has definitenly changed the urge to nuke-and-pave remains to this very day. I've seen other express a similar desire to handle legacy code. It's the mature developers that recognize both the business value of the current working product and the very real costs of spending time replicating that working power.
Before we get into how to handle legacy code in a business environment we need to establish
- Talk about realities
- Discuss the definition of legacy code
- Talk about natural inclination
- Provide some examples
- Talk about the bad choices
- Rewriting all the code
- Removing the code
- Replacing the code
- Talk about the oyster solution
- Provide new interfaces to old data
- Document behavior (just behavior) of the old interfaces
- Get down a process map of old logic
- How to handle hiring
- How to handle new people