Editorial – Don’t Criticize Code
By Phil Factor
SQLServerCentral.com
After many years spent supervising development teams, I’ve come to recognize warning signs of problems ahead. There are many such signs, but the following is one that always makes me cringe: a developer looks at code that he or she is assigned to maintain, and says something like “Who one earth wrote such stupid and xxxx (unstructured/ mindless/ unintelligible/etc.) code?”
There is a developer showing his inexperience. Only adolescents writing their first application in some exciting new computer language in their bedroom ever believe that it is possible to write perfect code, or even that they are capable of doing it. Intensive commercial experience as a developer normally grinds off the idealism and naivety that inspires this attitude towards legacy code.
Never is it a good idea to criticize legacy code, let alone the poor developer responsible for it, particularly if you don’t know the history of the application and the circumstances of the code being written. If you don’t show the code due respect, you are in danger of refactoring it into something worse. You probably aren’t aware of the circumstances under which the code was written, or the real brief given to the programmer. The pressures of coding in a commercial development project are difficult to describe, but it is perfectly natural under such conditions to take decisions that, in retrospect look daft, but which actually saved the project.
Legacy code is something I pore through with eagerness, as if it were a rich historical archive; even if it merely illustrates the coder’s drift into lunacy. Many times, when doing so, I have been jolted out of a growing sense of contempt by coming across a technique or insight that is brilliant. This real sense of humility, when faced with the results of human endeavor under pressure, always served me well in my work as a consultant. When you’ve been called in to fix a project that is about to hit the wall, making any suggestion of criticism is probably the least helpful thing you could possibly do. Beyond the easy job of fixing things, comes the more difficult trick of tactfully attributing their original predicament to a cruel act of Fate.
For anyone eager for a long-term career in IT Development, humility and tact are probably more important habits to acquire than demon coding-skills.