Within Temptation has a song called Destroyed (http://www.youtube.com/watch?v=KA_KdRhG9OI) with the refrain, “It is so easy to destroy and condemn the ones you do not understand.” Who knew that a symphonic metal band knew so much about working with legacy code? Okey, they are probably not singing about doing maintenance work on a software system without test cases, documentation, design patterns, and looks like a mess of spaghetti.
Anyone who has worked on a legacy system knows how easy it is to condemn someone else's work. When in that position myself I have often found it is easier to destroy and condemn by rewriting the legacy code rather than spend the time to understand to code. Rewriting leads to obliterating the original implementation which may have special cases littered throughout and on the next release customers depending on those special cases will start calling support. And that doesn't make anyone happy.
Working on a code base written by another developer is an intimidating task. Every developer is going to work out solutions in a different fashion, applying a different pattern or algorithm to the problem. Wrapping your mind around the original developer's thought pattern is challenging and often frustrating, especially when the original developer's background is very different from your own. Failing to understand the intent of the original developer can lead to belittling the code or writer, especially if they are not around to defend their work. Most bosses or customers are not interested in who created a mess, they want to have product shipped.
Destroying or condemning is not productive or conducive to shipping product and having happy customers. It is a developer's job to write the software and ship. The original developer already has a leg up on you since he has shipped something. So he is obviously not completely incompetent. Granted you are performing some sort of maintenance (bug fixing or feature enhancement), but that doesn't take away from his accomplishment. Judging or condemning the prior work does not add business value. Perhaps it is you or your point of view which needs adjusting, not the existing code or its developer.
There are many reasons why the original code is difficult to understand completely unrelated to the original developer's competence. The original developer had a different set of circumstances under which they were writing. Their personal style could be completely different or the styles they have picked up over time could be foreign to you. Many languages and toolkits have styles and patterns which are unique to them and you may unfamiliar with them. A hardware engineer may be excellent at their job of circuit board design, but unfamiliar with software engineering practices.
A better outlet is to work towards understanding the existing code using various techniques. Searching out the original developer and pairing with them if they are still available is a great way to become familiar with difficult code. Reviewing the original artifacts created during the development will give a high level understanding of the product, as it actually using the product itself. Writing unit test to stimulate particularly difficult segments of code can quickly reveal their purpose and leave an executable documentation of features. As you learn the purpose of particular portions of the code make sure to update identifiers to reveal their purpose for the next developer who will be working in this area.
Let me challenge you to be gracious in your judgment of existing code bases. There is value in the code otherwise you would not be maintaining it. The original developer was neither malicious nor out to make your life difficult. Assuming the worst intention or capability of the original developer does not improve the situation. Your boss and customer do not want to hear excuses, they want a time frame and the best possible value. Working with unfamiliar or difficult code is an opportunity to be explore new patterns, expand your repertoire, and become a better developer.
References
No comments:
Post a Comment