Passionate Development

A lot of people seem to have a real passion for developing software. So why is it that we have so much bad code? Well I have my own theories. So without further ado I present my most-wanted list of culprits, in no-particular order:

New coders

New developers are great. They're happy to have a job and are excited and keen and want to change the world. But they don't really know what they're doing. Hey sorry, but I've been there, I know. You can always do better the second time. And when you're new you write a lot of code. You do the first thing that pops into your head. That's not usually a good recipe for creating good code. I've said it before and I'll say it again, mentor these people and give them training. They don't mind learning and usually take constructive feedback well.

Gung ho Project Managers

Project deadlines are very rarely made with developer input and even if they are, deadlines are never adjusted to account for unanticipated problems or changing requirements. The usual solution is to throw more coders at the problem. To write code under the obligation to create software to help someone do their job is one thing. To do it under duress is completely another. Project Managers love to be "under budget" and "on-time". A lot of them don't care what it takes to get there. Tie some of their compensation to creating maintable systems and they'll help do the right thing.

Heroes

You know who I'm talking about. Every place has at least one of them. An environment that routinely has ridiculous productivity expectations seems to attract the evil genius who works his ass off to produce a solution. Like the new coder, this guy writes a lot of code and lives for the pat-on-the-back and the "attaboy". But he isn't really interested in producing an elegant bit of code. Rather he lives for the hack that will make things work at the last minute and "save the company". The problem with this guy is that he perpetuates the bad productivity expectations and increases the brittleness of the environment. Keep some kryptonite handy to slow him down.

The Architect

You know that fat dude from the Matrix who talks in riddles that nobody understands (says shit like "vis a vis" and "ergo"). Picture that guy and make him an IT architect and you'll get my drift. Architecture is a good thing and somebody needs to think about it, but a lot of these enterprise architects have no accountability to anyone and dream up all kinds of crazy impractical things to do. Take for instance all this SOA, Web Service stuff... Good Lord what a mess! But talk to an "architect" and he'll have tears in his eyes when he explains the world he sees through his rose colored glasses. If you're gonna have people called "architects" (regardless of how bad that analogy is for software development) then assign them to projects and make them responsible for something. (btw: I was a technical architect once so save your hate mail. I know what I'm talking about, vis a vis)

The Academic

These guys are aspiring architects. They love to look for the next great solution and somehow work it into their latest projects. There is such a thing as the progression of technology and you should upgrade the technology in your project so that it doesn't become a backwater for discarded frameworks. But you need to be careful. If you blindly adopt the latest and greatest all the time then you'll spend more of your time working the bugs out of these frameworks than you will actually developing your own software. The elusive silver bullet will often shoot you in the foot.

Support Developers

A lot of places I've been devote some developers to supporting the applications in production. They're motivated by the desire to fix bugs and enhance the application to meet ongoing user demand. So while that's a good thing, they usually have to support 20 applications simultaneously, don't really understand how any of them are put together, and only have to touch the code every so often. So what happens is that the application code (no matter how lovingly crafted during development) slowly decays over time. The solution? Make sure the people who developed the application are resonsible for maintaining them. There's nothing like knowing your own code may come back to haunt you, to keep you focussed on writing good code.

DBAs

These characters live in an alternate universe of sets, joins and intersections and they rule this kingdom. They institute all kinds of rules that don't always make sense from all perspectives. Understandably, they want to enforce certain conventions so that things are consistent and easier to maintain. But every once in a while these guys need to stop defending the battlements and adopt the prevailing wisdom of the land. For example, DBA purists will usually get pretty hostile if you talk about using surrogate primary keys to ease the object relational mapping burden. They'll get all academic about composite natural keys. And while their argument may make absolute sense from their perspective, they need to undertand that their unreasonable rules can result in less elegant code. Don't even get me started on the "law" about only updating tables through stored procedures.

Summary

Nobody sets out to create nasty tangles of code. Most people are at least somewhat passionate about what they do. They want to have pride in their work. Now it's easy to fall into the trap of negativity and start believing in the futility of trying to make things better. (Lord knows I've fallen in there once or twice). But in the end that's what you have to work with. Greenfield development seems to be a rare commodity. So recognize the poor behaviors, try to understand the motivations behind them, state your opinion, make good decisions (or at least try to influence the decision makers) and do what you can to make your coding world better. And for god sakes, stop writing crap code! ;-)