Thursday, January 06, 2005

Cowboy developers

A recent responder to Damien’s Iris article chided Damien for being a cowboy and not a team player and pointed out an article about Oracle 10g development cycle to make his point. I have two separate responses to this thought.



I too think Damien is a cowboy developer, but when I say that I say it with respect and admiration. Infact, all the best developers I’ve worked with have been cowboys. That's not to say they haven't been team players either, they all have been. Cowboys by their nature are team players.



What does a real cowboy do? They work on a team to shepherd a heard of cattle from one location to another. A cowboy knows their job on the team but can also think independently and be assertive because the heard is large and there may not be another cowboy in range when trouble strikes. A cowboy doesn’t need a lot of creature comforts either; they can sleep on the ground and live off beans and cornbread for weeks on end. Cowboys don’t always get along with city slickers and they don’t have much use for towns, except perhaps to visit the saloon, but put them in their element and they are king of the range.



In this context, a cowboy sounds a lot like a software developer to me. Code is a lot like a heard of cattle. Each cow - I mean piece of code - needs to be coerced to work in the direction of the entire project. Just like in herding, this often means moving from one area of the code to another to keep things moving along. To do this you need self motivated people with a variety of skills and a team and project perspective. And, just like real cowboys, a cowboy developer can do all this with a modest set of tools; just give them a good computer/horse and editor/saddle and they can get the job done. When working on an interesting project a cowboy developer will gladly work crazy hours and live off soda, candy bars and pizza for months. But also like cowboys, cowboy developers don’t like people who aren’t developers who try and tell them how to do their jobs. They work best with other developers and they willingly follow the lead of a developer who has demonstrably better skills than themselves.



As for the Oracle 10g article - I would take any article written by a marketing person on behest of corporation with a grain of salt. A statement early in the piece pretty much kills the credibility of the author as far as writing about software development.




"In the past, developers used local, four-CPU machines for development and testing," says Kumar. "But the number of tests has grown from 30,000 to more than 100,000, which is more than a desktop machine can handle." So, Oracle pooled the developers' individual computing power to create a server farm of more than 1,000 machines. This development grid represented a major breakthrough for Oracle, giving developers on-demand computing from any location. It also offered them far more horsepower than a single dedicated machine could provide. As a result, they could edit source code not only more safely and accurately but also more quickly.



I’d really like to understand how this grid helped the developers edit source code more safely, accurately and quickly. Perhaps the author was trying to indicate that grid helped developers regression test changes and get the code integrated into the build quicker, but that’s not what they said.



The whole article seems like management patting themselves on the back for their ‘brilliant’ plan. I would like to hear from some developer on the ground how things really were. Most of it sounds like standard enterprise development BS.



Post a Comment
 
The Out Campaign: Scarlet Letter of Atheism