DevOps Zone is brought to you in partnership with:

Willie Wheeler is a Principal Applications Engineer with Expedia, working on continuous delivery, including build automation, test automation, configuration management and application performance management. He's also the lead author of the book Spring in Practice (Manning). Willie is a DZone MVB and is not an employee of DZone and has posted 23 posts at DZone. You can read more from them at their website. View Full User Profile

The Virtues of Cowboy Development

  • submit to reddit
Sometimes it’s easy to fall into myopic ways of seeing the world.

Let’s talk about my favorite recent example, which is the so-called “cowboy developer”. The cowboy developer, the thinking goes, is an organizational problem child because he (or she) adds unplanned features, commits code past the code freeze and generally works outside the control structures that management has put in place to keep development manageable.

These are harmful, right? Cowboys are bad. Right?

Well, it turns out that context matters.

One man’s emergency release is another man’s continuous delivery. Big batch releases and code freezes aren’t ends in themselves. They’re rather a way to achieve acceptable quality in a context where regression testing is expensive (usually because it’s mostly manual), and so features need to be batched up into releases so that we can do one or two regression runs instead of twenty. But as you drive those costs down, it becomes more and more feasible to run regression test suites against feature-level changes. Now there’s no more need for code freezes, and the cowboy looks a little less like Black Bart. He starts to look a little more like a guy who can put a feature/fix together and get it out to the user quickly, with high quality and a minimal of fuss.

Developers don’t like being constrained by code freezes, and testers don’t like it when commits come in after the freeze. But both roles are in a fantastic position to solve the problem, and the solution isn’t better schedule discipline. It’s better testing discipline. Developers need to have comprehensive unit and integration tests in place. Testers need to expand and automate their functional and system test suites.

Published at DZone with permission of Willie Wheeler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jammer Man replied on Tue, 2012/12/18 - 10:04am

Cowboy coders are bad - period.  There is no room for them in any organization.

Tony Spence replied on Wed, 2012/12/19 - 2:25pm

 There are NO virtues of cowboy (or girl) development.

Willie Wheeler replied on Wed, 2012/12/19 - 7:23pm

If cowboy development means that somebody's doing something without regard to whether it will break stuff, yeah, there's no room on a team for that. No argument from me.

But there's a deeper point I'm trying to make. The cowboy's real goal isn't to break stuff--it's to act with little or no restraint. For sure some things we don't want that kind of freedom (e.g. product features when there's somebody else who owns the product), but from a development/test perspective, the goal itself is actually a virtuous one because it's basically saying "let me do my work as quickly as I can do it". The real problem is that most development processes can't accommodate that goal without taking a serious quality hit.

The suggestion is to embrace that goal, but to improve the development process such that you can actually achieve the speed-enhancing decoupling without taking that quality hit.

To the extent that the cowboy's speed goal drives improvements in overcoming the speed/quality tradeoff, that goal counts as a virtue.

Tony Spence replied on Thu, 2012/12/20 - 9:51am

 If your cowperson is delivering unrequested functionality not on the current delivery plan then they are adding risk to the delivery. Yes, it is reasonable to build the tools or structures needed to support the agreed functionality and that is what I'd expect of any even half-decent programmer. If, however, they are delivering functionality either not requested or not planned for the current delivery then they have no place on my team. When building a release the release manager needs to know exactly what is included and be assured that it has all been shown to meet the agrred requirements/user stories or whatever your favourite development method uses.

Over the years I've seen numerous examples of the problems which have been caused by  uncontrolled good ideas which were doubtless implemented with the best intentions but which had an anthing but good impact.

I don't know what kind of development environment you work in but I would expect my programmers to be fully employed delivering what they've undertaken to deliver and not to have spare time in which to build 'extras'.

Willie Wheeler replied on Thu, 2012/12/20 - 12:34pm in response to: Tony Spence

Hi Tony. I agree 100% with what you are saying on unrequested product features--see my previous response, which addresses exactly that case.

There's a specific context in which I'm referring to cowboy behavior, and that's the dev code freeze toward the end of a sprint. While we don't want cowboys violating that either (it will make it harder for the testers to do their job), I am arguing that the real problem is a costly regression testing process that makes the code freeze necessary in the first place. It is possible to reduce the cost there.

In retrospect, I wish I had chosen a label other than "cowboy" for this post, because it carries unintended baggage that's distracting from the real point of the article.

Hope that clarifies. I don't disagree with anything you say above.

Tony Spence replied on Thu, 2012/12/20 - 1:22pm in response to: Willie Wheeler

 OK, I agree that over-enthusiastic implementation of code freezes is a real pain but, with my project manager's hat on (a hat which I only wear under duress), you have to draw the line somewhere. In the bad old days it was always the testing phase which was compressed because development always over-ran and implementation couldn't (or wouldn't) move. We learned from that and now testing takes a much higher profile and we build to meet a sometimes immovable testing schedule. That said anything which can be done to speed up testing and allow a bit more development time has to be a good thing.

I think we are singing from the same song-book; as you say the choice of the label 'cowboy' was probably less than perfect.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.