There are a number of esteemed contests for the greatest and fastest software developers among us - events where we can pit our coding prowess against fellow brainiacs and like-minded techies. I think it's high time we had an alternative set of awards, suited not to aspiring budding Turing machine engineers, but rooted more in the humdrum real, rather than artificial academic, world.

The Herring Rouge Chase
To win this award you have to think that when a piece of code you authored isn't working correctly that the problem isn't your error but instead lies elsewhere in the broken software stack. A colleague of mine was once so convinced the JVM was broken he got as far as talking to a Sun engineer by phone, when it transpired eventually that he'd just written a bad toString() method. Everyone has had or witnessed one of these moments, for which we should humbly remind ourselves of the age-old proverb "If you see hoof prints, think horse, not zebra"; it's more likely to be something simple than something complex, and make really sure it's not your code that's broken before you hit the fire bell.

Hunt the Edge Condition
This is a favorite contest of many folks I've worked with, and involves the exemplary statement along the lines of: "Ah, I agree that if you have a personal details dialog with a name and sex that'll work for 99.8% of all use cases, however, what if the end user undergoes gender reassignment surgery during the account registration process so when the billing details are mailed back to them the new details should be used?". Entrants to "Hunt the Edge Condition" are the plague of all software development projects, as all they do is harp on about obscure scenarios that never actually occur in the real world and make the software so rich in features to cope with these that it can't be operated for normal everyday usage. Let them have their way and the software drowns in UI treacle as it tries its best to not offend anyone and ends up being useless to everyone.

The Armchair Performance Race
Most projects have one of these - they spend their entire time talking about how you should write everything in one giant method to avoid method prolog invocation; how reflection is so CPU intensive, using it will stop the world from turning; or forcing you to use arrays rather than java.util.Collection classes because of heap optimization. Such people are usually wrong; most application performance problems are related to network latency or else usage scenarios where you can't really determine why they're tardy until you put a profiler on it and look at the numbers. The biggest thing to do with performance is not get obsessed with it at the expense of good clean modular code, and avoid rewriting to optimize code at the expense of clarity. Also, don't profess to know how something will perform until you've actually run the thing - you'll be surprised where the bottlenecks really occur.

The Legal Obstacle Course
This is a contest entered by legal departments that pit themselves against fellow corporate lawyers with how to best ruin a wonderful and creative piece of software. I was on a project once that awarded this to the appointed attorney who delayed the ship date because they had used the universally ubiquitous cut/copy/paste icons in their program's menu bar. He cried foul and instead had new graphics authored by a clean room design team who came up with something novel and now totally unrecognizable to the end users, who were used to the old icons. Other entrants in this contest are those who think using open source in your software stack is slightly less than signing a Faustian pact with the devil, and will endlessly nitpick at the wording for a splash screen copyright attribution or a set of About dialog from and to dates, again doing nothing more than delaying ship dates and frustrating the development and test team to the breaking point.

There are other events that awards should be given for, including ridiculous progress bars, writing code libraries, and routines from scratch when perfectly good ones already exist in the JDK, and just generally gloating in pressing the brake, rather than the accelerator, or even idling in neutral, when involved in software production.