Comments on: The virtues of cowboy development /blog/2012/05/28/the-virtues-of-cowboy-development/ Willie Wheeler's devops blog Tue, 18 Dec 2012 13:54:51 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: James /blog/2012/05/28/the-virtues-of-cowboy-development/#comment-490 James Tue, 18 Dec 2012 13:54:51 +0000 /blog/?p=177#comment-490 I think you're missing the point. A cowbody coder isn't so named because he's good but "outside the rules"; the name comes from the same root as cowboy trader - a workman that doesn't care about how well a job he does, or whose lives he makes difficult because of his actions. In short a cowboy coder is someone who is not a team player and doesn't even care about the team. Just his job and the paycheck it entails. Your analogy is more like saying in a society without any heavy handed morality rapists aren't that bad as they increase the population size. I think you’re missing the point. A cowbody coder isn’t so named because he’s good but “outside the rules”; the name comes from the same root as cowboy trader – a workman that doesn’t care about how well a job he does, or whose lives he makes difficult because of his actions.

In short a cowboy coder is someone who is not a team player and doesn’t even care about the team. Just his job and the paycheck it entails.

Your analogy is more like saying in a society without any heavy handed morality rapists aren’t that bad as they increase the population size.

]]> By: Willie Wheeler /blog/2012/05/28/the-virtues-of-cowboy-development/#comment-44 Willie Wheeler Tue, 29 May 2012 20:45:17 +0000 /blog/?p=177#comment-44 Hey Clint. We may be saying similar things here. We're both in agreement that process heavy-handedness reflects a deeper trust issue. And that's a fundamental problem. But there has to be a basis for that trust, and it's not just that we think the developers and testers are swell people. There has to be something in place to make it hard for things to go wrong. Heavy test automation is a solid basis for that trust. If your build breaks when somebody creates a bug, then you have a great basis for trust. In that context, the negative connotations around being a cowboy disappear, because you're working within a framework where the process is more in the background. You're not trying to figure out how to get a build out there without running tests against it, for example. The tests just happen automatically and you're OK with it because it makes sense. If anything of the "cowboy" remains, it's the idea that somebody can decide to work on something and get it out there without needing major planning, coordination and verification efforts to achieve the required level of quality. In that latter sense we should all aspire to be cowboys. Hey Clint. We may be saying similar things here.

We’re both in agreement that process heavy-handedness reflects a deeper trust issue. And that’s a fundamental problem.

But there has to be a basis for that trust, and it’s not just that we think the developers and testers are swell people. There has to be something in place to make it hard for things to go wrong.

Heavy test automation is a solid basis for that trust. If your build breaks when somebody creates a bug, then you have a great basis for trust.

In that context, the negative connotations around being a cowboy disappear, because you’re working within a framework where the process is more in the background. You’re not trying to figure out how to get a build out there without running tests against it, for example. The tests just happen automatically and you’re OK with it because it makes sense.

If anything of the “cowboy” remains, it’s the idea that somebody can decide to work on something and get it out there without needing major planning, coordination and verification efforts to achieve the required level of quality. In that latter sense we should all aspire to be cowboys.

]]> By: Clint Hill /blog/2012/05/28/the-virtues-of-cowboy-development/#comment-43 Clint Hill Tue, 29 May 2012 20:23:57 +0000 /blog/?p=177#comment-43 I find this a little wanting. If it were truly a "testing" problem, then unit/integration tests could certainly be written to fix all of this. But that's not it is it? Seems to over-simplify what is actually a very complicated organizational and trust-based problem. The truth I think is that organizations don't trust engineers (QA and Dev). All of the processes put in place are there only to make sure everyone is under some kind of control. I think in cases where you have a "cowboy" you more than likely process heavy. Which might have been a process light system and as mistakes were made more process were added in order to prevent mistakes. But processes never get cleaned out. Are all those process really -truly- needed anymore? Why couldn't process be removed and by definition also remove the "cowboy"? I find this a little wanting. If it were truly a “testing” problem, then unit/integration tests could certainly be written to fix all of this. But that’s not it is it? Seems to over-simplify what is actually a very complicated organizational and trust-based problem.

The truth I think is that organizations don’t trust engineers (QA and Dev). All of the processes put in place are there only to make sure everyone is under some kind of control.

I think in cases where you have a “cowboy” you more than likely process heavy. Which might have been a process light system and as mistakes were made more process were added in order to prevent mistakes. But processes never get cleaned out. Are all those process really -truly- needed anymore?

Why couldn’t process be removed and by definition also remove the “cowboy”?

]]>