As long as you have a small team of good people, it can be the greatest choice of all. Especially if you plan to go iterative (in one way or another).

What? You can do Iterative Cowboy. Works great in my shop.

Methodologies tend to backload results. Software takes a long time and a lot of money to develop. It’s important to show the people paying that the money they are spending is being used to produce more than reports and reams of documentation.

Cowboy programming is very good at delivering results early, clients like that. Unfortunately all you’ve managed to do is take a prototype and raise the expectations of the clients into thinking the project is 80% complete because it “looks” 80% complete. This is bad.

Any methodology, you name it, in my opinion must be results oriented but it can’t backload results. You can’t go a year without showing the stakeholders something tangible. If you try then you are putting immense pressure on the developers to “manage” the clients impatience with the project. The developers are the ones who work all night in an attempt to satisfy the frustrations of the clients in spending all the time and money and having no code to show for it.

Any methodology, or none at all, must manage client expectations, involve all of the actors all of the time – not dump problems on the developers, and must deliver results progressively so the clients can see something for their money – they need to see continued progress.

The typical “cowboy” ad-hoc method is subject to the 80/20 rule. You talk to the client and in a short time you return with something which, to the client, looks almost complete. It looks great, just make the buttons do things, make the list and grid show real data, essentially, go back and fill in all the blanks, easy.

Now you’ve got a situation where the client thinks you’re 80% done. The problem is that they expect you to be finished any day now but you’ve still got weeks or months of work to do to finish. After another week the client asks why you aren’t done yet. They think you’re 80% done because they have seen it with their own eyes. Nothing you say will convince them otherwise. Weeks go by and the client is still look ing at the same almost done view, they see no change and assume you’ve gone to sleep or are being lazy.

Method is about delivering a product to the client which meets or exceeds their expectations at every stage of development. It’s not about getting it done quicker, in fewer lines of code and with fewer bugs. Whichever one does that for you at the lowest cost is the one you should use and it may not be the same choice every time.

Building a trader accounting app from scratch requires a different process than throwing up a email response form on a website. You wouldn’t go to a jobsite with a toolbox full of hammers, why would you write software that way?

I try to use the best tool for the job at hand. There are plenty of methods to choose from. Many of the “examples” above are examples of people who chose the wrong tool for the wrong job, not necessarily some fatal flaw in the methodology.

Cowboy coding also is not suitable in development teams consisting of more than a couple of developers which may work on the same components because that creates unclear code which is not easily understood and changed.

However for small, non critical applications written by a single programmer Cowboy coding can be used. Still if the application is to be maintained by another programmer it is good to follow common coding conventions and have automated testing. That is not something that can be left out because the programmer did not feel it was important at the time.

One would not want to build a missile guidance system or mission critical application without a high degree of planning, design inspection (2nd or 3rd party), and post-coding review.

However, applications that are less mission critical or for end-users who do not need defect free software, it’s a great solution.

For instance, the company I work for makes hospital software. I built a black box application that simulates a hospital’s environment, and it works great for our quality assurance department. I wrote it autonomously, guided more by “gut feeling” about how it should be, rather than going through the traditional SDLC process, and it works great. From time to time, there’s something not quite right that needs to be fixed (I abstain from using the word defect, because I’m not sure there can be a real defect without real requirements, but I digress). When this situation occurs, I fix it, publish to the QA department the updated library or libraries, and they go on their way.

So, yeah, Cowboy development is appropriate for some things.

We actually use a great tool that gives everyone in the project great visbility into the process, how we all relate, and actually has helped improve morale. Click on my name for it.

Mark

I was given the opportunity to “race” the development of three-men who are sworn to agility vs. myself, sworn to deliver. I have finished in 3 weeks. They never did. Unit Testing killed 70 % of their time imho.

I wish I could post evidence (screenshots of poor results by equally skilled programmers sitting in the same room and same meetings)