The Virtues of Cowboy Development
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)