To Compile or Not to Compile

A discussion I overheard recently got me thinking about compilers. (Wait, don’t fall asleep!)

A software developer complained that a Java 1.5 metadata annotation was preventing him from compiling a class. In this particular case, the @Overrides annotation was choking because the superclass no longer had a method to override. The suggestion was made that the developer simply delete the annotation, compile the class, and continue with his work.

(Nobody suggested the hard work that needed to be done: Get the older version of the superclass and find why the method was removed/renamed in the new version. Analyze whether the functionality in the subclass is still necessary and needs to be called from somewhere else in the stack…)

Yes, deleting the annotation would be so much easier.

We all hear the joke, “It compiled, so check it in!” It is a joke…. right? Compiling isn’t supposed to be the goal of software development, is it?

Charles Hummel once wrote, “The urgent is the enemy of the important.” The urgency of a deadline tempts all programmers to “just make it work.” That’s an unfortunate reality of software development that can’t always be avoided. But when the decision to “just make it work” becomes the rule rather than the exception, we’re in trouble.

To state the obvious, I’m coining this phrase:

The Compiler Axiom
Code that won’t compile is not my enemy.
Bad code that will compile is my enemy.

Most software developers will agree with this in principle, I suspect. After 11 years in software development, however, I don’t often see them actually take it to heart. More often than not, the shortcuts I see people take are less rational and more rationalization.

Here’s a reality-check list to see if you don’t really believe The Compiler Axiom:

  • I have set my editor to suppress compiler warnings so I don’t have to ever see them
  • I habitually ignore exceptions that aren’t part of what I am directly working on
  • I have commented out code I didn’t like or didn’t understand without researching its purpose or contacting the author
  • I have recreated a class/library/application rather than figure out an existing one

If you answered “yes” to any of the above, perhaps it is time to re-evaluate why you write software. Is your goal to compile/source control/ship code, or is it to deliver something that meets requirements and works as designed?

Ironically, if you have answered “yes” to anything on the checklist (as I have), another developer may someday have to deal with your code and decide whether to ignore exceptions, comment out code they don’t understand… or simply replace it altogether.

Comments are closed.