There's code that we write ourselves, code that we've acquired, open-source code and then there's code that just happens to be in our system... that's called "code rot". It's outdated code that still exists but hasn't been acknowledged in ages. Nobody is quite sure how it works or why it works, so it's just best to ignore it. If it's not broke, don't fix it, right? But what are the implications of faulty code? How can we continue our software development planning and strive to modernize our systems if we don't even know how they were built?
Just because the code works (or at least we think it works) doesn't mean it's optimal for performance. If we continue to ignore the code simply because it's the easiest solution, we'll eventually hit a roadblock. Legacy systems are tough to displace. In most organizations, infrastructure has been built on top of platforms and technologies that were chosen decades in the past. The decisions made long ago probably wouldn't be made today. It's important to know what you're working with so you can plan for where you want to be in the future.
Our systems today (although mostly automated) still need our attention. Code can become obsolete, hindered by errors which can burden system responsiveness. So, what can we do to rid ourselves of code rot? Well the Rational SCM toolset is a good start...
- Rational Requirements Composer (RRC) offers a better solution for organizing documentation. If we know how the system works, we'll be less likely to hack an integration when there's a new feature request.
- Rational Team Concert (RTC) offers a centralized repository for all of our source code. Developers can be assured that they're working on the latest & greatest code, instead of some obsolete version stored on their desktop.
- Rational Quality Manager (RQM) provides visibility into the efficiency of our systems during development. By automating the testing process we can automatically determine the cleanliness of our code and plan project release dates based on metrics.