Ben Northrop

Decisions and software development

Why are our Programming Gods so Unkempt?

December 17th 2007

Despite their popularity, in my experience as a consultant, PMD and other tools typically have little lasting impact on code quality for an organization. To the cynical, they are essentially "panaceas of the month", initially heralded by developers as the silver bullet to all their code quality woes, but quickly ignored or discarded in favor of the next tool.

The most significant problem is that there is a non-trivial learning curve for integrating these tools into any team environment - developers must take the time to understand the rules, debate their merits with their teammates (which can be painful, depending on how ardent their beliefs are!), and configure them in yet another XML file. Even when developers do invest this time, however, they have no mechanisms for enforcement, and tend to be ignored.

Perfect World: Violations as Build Breaks

Initially, many developers would like to treat PMD violations like compile errors or unit test failures: when a developer checks in a piece of code, the continuous integration server (e.g. Cruise Control, etc.) kicks off the build, which then runs PMD. If a PMD violation is found, then a notification is sent to the team, the build is considered "broken", embarrassment ensues, and the developer fixes his mistake. In this scenario, the build serves as a mechanism to strictly enforce code quality it's not possible to check in poorly written code because the build would be broken or, at least, the team would know about it. The tacit assumption, of course, is that there are no violations in the code base initially in other words, you're starting from scratch and your build is programmed to break (or notify people) only when violations go from zero to some positive number.

Most developers, however, don't get the privilege of starting from scratch. Though we'd like to be artists with a blank canvas, we're more like stewards of a delicate ecosystem (or perhaps landlords of a dilapidated tenement!). When we first use PMD, often tens or hundreds of thousands of lines of code have since been written, and, of course, code quality is in all likelihood sub-optimal. PMD of course finds thousands of subterranean violations burrowed into the code mistakes no one knew existed. This is disconcerting, for sure, since immediately it is understood that the perfect world scenario, treating violations as build breaks, is impossible. Fixing every violation to get back to a blank slate will never happen even if the motivation was there, the ROI to the business just isn't.

Reality: Violations as Obscure Numbers on a Report

Given that there's no magic wand to waive to rid the code base of violations, the solution, typically, is to continue using PMD in Eclipse, endeavoring to fix violations as they are encountered, and slowly chip away at the code quality iceberg. Unfortunately, there are three problems with this approach. First, it's voluntary, since it's impossible to force developers to use or pay attention to the PMD plugin. Second, there's no good way for an architect to make sure that no new violations are being checked in - since the code base is already littered with old violations, there's no automated way to distinguish new violations from old. And lastly, even for the earnest developer, after a few days, the information overload usually becomes too much - the code base is littered with thousands of yellow and red flags and attending to code quality gets to be too annoying.

The decision then resolves to either: (a) turn off all but a handful of PMD rules to make violations more manageable, but thereby jettisoning most of the value of PMD or (b) turn off PMD in Eclipse altogether in favor of running it as an optional, periphery part of the build, generating a report for people to look at on their own time (which, of course, never happens). In either case, PMD, as great of a tool as it is, seldom makes any lasting contribution to the improvement of code quality in the system. Developers continue to check in poor quality code because there is no mechanism to enforce otherwise. This is unfortunate.

I believe that software development is fundamentally about making decisions, and so this is what I write about (mostly). I've been building software for about 20 years now, as a developer, tech lead, and architect. I have two degrees from Carnegie Mellon University, most recently one in philosophy (thesis here). I live in Pittsburgh, PA with my wife, 3 energetic boys, and dog. Subscribe here or write me at ben dot northrop at gmail dot com.

Got a Comment?

Sign up to hear about the next post!

If you liked this article and want to hear about the next one, enter your email below. I don't spam - you'll only receive an email when there's a new post (which is about once a month, tops). It's all low-key, straight from me.

Comments (2)

jason thiel
November 13, 2012
Eh, what do you know?
November 13, 2013
I think much of it, nowadays at least, is due to copycat behavior - we see this is how the unix masters look, and so we must emulate it to become one ourselves. And yes, I sport a unix beard.

BTW, your captcha appears to be static.