I do a lot of work with large companies that usually have many development efforts going on simultaneously. A lot of these are maintenance projects, which are basically bug fixes or enhancements to systems that have been around awhile and have already spent a good deal of time in production. Then there are the new development efforts.

The Grass Is Always Greener

Most developers are excited about the prospect of “Green Field” development. Finally you get a chance to build a system the way you know it should be built. You’ve learned from the mistakes of your past, and are eager to put that wisdom to work. You might also be thinking that this is the perfect time to try out one of those new-fangled ORM’s you’ve been hearing about. And just think, since you’re building this from scratch you’ll be able to FINALLY build something with TDD and feel good about your code quality. In short, you’ll be able to fix all those things you complain about in the existing code base.

That’s most of us.

However, I’ve met a few individuals in my brief time on this earth who are while-knuckle, cold-sweat TERRIFIED at the idea of building something from scratch. They like the relative security of having a code base to work on. TDD?! Are you kidding? How can I write a test for something that doesn’t exist? And working with a new framework or tool? Are you out of your mind? What if I pick the wrong one? Then my application is hosed from the get go! And what if I don’t really have all the business requirements? How can I start developing if I don’t have all the requirements?!

Over Analysis == Paralysis

I met one of these poor souls recently. His way of dealing with a green field project was to go into this weird “over-analysis” mode where he tries to vet and verify every aspect of the system before writing a line of code. Beyond the idea that this spits in the face of Agile development (which everybody loves more than a basket of fluffy kittens) it causes him the thrash. In short, this guys doing A LOT of work and getting absolutely nowhere. To make matters worse, he has a deadline that is fast approaching. He’s so terrified of writing the wrong line of code, or missing a field in his database schema, or having to re-work one of his layers, or not naming one of his entity classes correctly that he’s just not doing anything. He’s afraid of writing an application that’s a piece of crap; he seems to only want to write code if it’s going to be perfect the first time he does it.

How Green Is YOUR Grass?

What this developer needs to realize is that there is no “perfect system.” Not gonna to happen. There’s always going to be something you wish you had done better or differently. Time is a great teacher. If you look at code you wrote two years ago I bet you’ll find stuff you would have done differently with the benefit of a little more time and experience. There’s nothing wrong with this.

You can’t be afraid of writing crappy code. Fact is a lot developers that I highly respect spend half their day writing crappy code, and the other half of the day refactoring. And they manage to deliver GREAT (though admittedly not perfect) applications this way. You write your code in an IDE or text editor, not on a stone tablet.You can (and should) change your code. More importantly you should be OK with changing your code. It’s good to think about what you’re going to write before you write it. But you can’t finish until you start. And you can’t start without writing something.

My advice, in this developers case, write a piece of crap.

The system is due on a specific date, which is NOT far away. His options at this point are show up to work that day with nothing, or show up with a system that’s not perfect. Heck, maybe it’s not even very good. But it’s better so show up with something than empty handed. Even something that’s not complete is something. Most managers would rather have something that needs some work than nothing at all. Have a plan for how your going to make it better, but deliver something.

And in this case, bringing some donuts to the meeting might not be a bad idea either. :)