"Muntz" your code

A long time ago, when I was a much younger engineer, I read an article in "Electronic Design" magazine by Bob Pease of National Semiconductor titled "What's All This Muntzing Stuff, Anyhow?". In this article, he describes how Earl "Mad-man" Muntz, would clip parts out of his engineer's circuits to see if the parts were absolutely necessary. As a consequence, his television sets cost dramatically less than his competitors. This article is definitely worth a read (as are Bob's other articles).

This article had a huge impact on my urge to minimize the complexity of the hardware that I designed (though in some cases, I went too far and increased the complexity of the associated software). The idea that "Simplicity=Elegance" is something that I've carried over to my software design methodology.

So now that we've created a new verb, how do we apply "muntzing" to software development? ... CODE REVIEWS. Whether you're working in a team using a classical waterfall method, or you're a lone-wolf programmer using one of the agile methods, the "code review" process can dramatically improve your product.

In a team environment, code reviews provide a mechanism for developers to learn from each other. It also provides an inspection by a second pair of eyes that can spot mistakes. At the point a code review is performed, it is likely the developer has already passed his unit tests, so the types of errors that are found at this point are generally more algorithmic. In the case of agile development, a code review is essentially one final pass for code clean-up and a re-execution of your unit tests.

In both cases, here are a list of tasks that should be performed:

  • Run a syntax checker and formatter ... you'll want a consistent source file format when you dig back into the code (potentially years down the road). If your company has coding standards, compare the code against this template.
  • Read through the comments in your code as if the code didn't exist. After the code is developed, I find myself eliminating many of the "in-line" comments as redundant (obvious from the code functionality), but I find myself adding content to top-of-block comments to adequately describe the block's algorithm.
  • Eliminate extra tests ... it is easy to have the same condition checked more than once in complicated code (especially when the tests are in nested methods). Modern compilers are pretty good at eliminating these problems, but they'll give you a healthy dose of "Why in the world did I do that?" when you revisit the code.
  • Eliminate extra import or #include statements. If they're not used, they're just clutter (this step might be difficult for pack-rats and those who have an extended family of trolls on their monitors).
  • Rerun your test suite ... you can break your code just by altering comments

Why does this list of common-sense items help? Many times this step is skipped due to scheduling constraints or laziness ... you'll pay more for it later. The code review process has two goals; One is to take one last look at the product of your labors. The second is to take the first step in code maintenance.