I’ve been looking at migrating some C++ code from my group that’s from 2005. In terms of computers, that’s a very long time and the code is definitely showing it’s age. As I was looking at it, I saw a lot of opportunity to modify build files and get some things for free (like using Fortify for code analysis). I also saw that some of the libraries the code is linking in are very very old. All in all, updating the dependencies was quite easy, and testing the new build took the majority of my time.
This neglect of code (not just build systems, but general usage patterns) is something that software organization need to actively guard against. There are a number of reasons that this happens.
One, the person or persons writing the code are using the same methodology and design that they believe is best, so they will have little incentive to go back and change work they’ve already completed.
Second, engineers like to work on new and shiny projects. No one likes doing maintenance work, and modifying build files is the worst case scenario for maintence work. After a bit of work, you have absolutley nothing to show for it but a binary that works exactly like it did before.
Third, if it doesn’t appear to be broken, then why try to fix it? This is a common argument against refactoring code, and I’ll address this more thoroughly in another post.
Fourth, fear of the unknown. Engineers already have a toolkit of libraries, patterns, and common usage patterns that they know work (at least reasonably well). ‘Stick with the devil you know’ is a phrase I’ve used more than once, and isn’t without merit.
In light of the above points, how can an organization keep code bases up to date? I think a very effective method is to put the ‘new guy’ on the project. Newer engineers are going to be eager, but they won’t know the systems they are working on. Getting to know the build files and dependencies intimately will give them a good start at understanding larger codebases. Also, new engineers (if they have any experience) will probably have some ‘best practices’ from their previous work that they can bring to the table.
Having them impliment those changes in your build process can demonstrate to the team their value, and increase adoption of those processes. This is a win win situation for the engineer and your organization. As an added bonus, you just might see some previous bugs disapear as you update dependent libraries.
Mat
Posted by Mathew Duafala 
