Doing it Right vs Getting it Done

The days leading up to a product/system release is always an exciting time. For organized teams, it's a tightly controlled process where useful bug reports roll in from the QA team and beta testers while a small strike force of the best team members from each functional area track down the root of the problem and deftly wipe them out with a few swift keyboard clicks and a new deployment. As this cycle repeats a few times, the problems become less frequent and involve more contortion to create and the strike force begins to break a sweat… This is not the team I'm writing about.

For less… organized… teams, the process is slightly different. The bug reports are written by six-year-olds with ADD, the QA team is the team's manager or the team itself, and the lead developer of the core-module-that-runs-everything was hit by that nearly-mythological bus that hunts software developers. The worst part of the experience is that you envy him for “having time off”, but I digress… I know your team is nothing like this, but let's imagine it for a moment.

One of the nasty things about software development is that there are a minimum of two ways of doing anything: The Wrong Way(s) and the Better Way(s). There isn't always a “Best Way” of implementing a particular feature for the simple reason that there are design trade offs that happen along the way but there are almost always a multitude of Wrong Ways. Unfortunately, some developers have misappropriated the term “Refactoring” to excuse the quick and dirty way of doing things but this doesn't hide the fact that the underlying problem is still there.

I was reminded of all of this recently as I dug into two different systems. The first was my application and serves the core of a number of production websites and the other I was looking into as a quick favor for a longtime customer. Much to my disappointment, both systems had these styles of “fixes” applied. Some of them were relatively small like a color on table cells while others consisted of hard coded id's. Unfortunately, while only a handful of these were my doing, they ran the gamut from trivial to feature-changing. The only aspect in my favor was that all of mine were marked with “//TODO: ” and an explanation of why the tweak was put into place along with some of the expected ramifications.

In order to combat this, I've made a handful of tweaks to my coding standard validation scripts to seek these out and log them. By no means will it get rid of them, but it will allow them to be identified and tracked throughout development. If anyone has a better strategy, I'm all ears. 😉