Great Developers, Mediocre Dev Process – OR- Mediocre Developers, Great Dev Process

Okay, this topic may be a little heavy for a Monday, but it’s been on my mind lately. I’ve designed a number of Development Processes over the course of my career, and there’s one thing I’ve noticed about them: the majority of great developers won’t follow any process they didn’t come up with. And usually the process they follow is in their heads (read that: undocumented) and is not always consistent. But mediocre developers are happy to follow a process if it makes their job easier to do (the exception is the mediocre developer who thinks he/she is a great developer…. they don’t follow any process or listen to anyone).

So, my question is: would you rather have a team of great developers who follow a crummy process (which may mean “no process at all”), or a team of mediocre developers who follow a well-designed, repeatable process with well-defined milestones, deliverables and job functions?

You may be able to guess my answer, but I’ll bore you with it anyway. I’d take the mediocre developers any day. Any day. We’ve all heard the term “herding cats” which is usually how software project managers lament having to work with software developers. Of course, none of us wants to think that we’re difficult to work with (it’s always that other guy who’s difficult to work with… I mean, if he’d just do it MY way, everything would be okay… sound familiar?). But the truth is, the better we are at slinging code, the more difficult – in general – we are to work with. Why? Because (a) we know we’re good at what we do, (b) we don’t like to be told what to do, and (c) (now this one’s gonna hurt) we don’t work well with others.

The solution? Hire crummy developers, train them to write code the way you want it written and make them follow a well-defined process. I’ve worked for two companies that did just that: they created coding standards and had training classes, and smooth development and environment migration processes that were enforced. Both of these demanded repeatability, and for years these companies were extremely profitable. I also watched them decline as client/server gave way to younger developers (yes, I was one of them), who resisted any type of process, which caused communication breakdowns, and the like. These companies both struggle today. I don’t blame the lack of process, but I believe it didn’t help.

Look at modern engineering. If you wonder how a bunch of people whose educational (or citizenship) credentials are in doubt can build a bridge that stands for decades, I argue it’s because of great engineering and great *development processes*. I mean, if we built bridges the way we build software, I’d be afraid to leave town. Seriously.

So what is my point? I suppose it’s this: given the choice between herding cats or sheep, I’ll take the sheep. They do what their told, they’ll follow the process, and well, I really don’t like cats.

What do you think?



Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.