For those who are unaware, here is a quote from Wikipedia:
Cowboy coding is software development where programmers have autonomy over the development process.
A cowboy coder can be a lone developer or part of a group of developers working with minimal process or discipline. "Cowboy coding" commonly sees usage as a derogatory term when contrasted with more structured software development methodologies.
If by 'Cowboy Coding' you're meaning freeform development without a rigid structure, YES, much of my coding fits into this category.
I do a lot of greenfield development and research, which means I'm constantly opening up my editor to a blank file, working, and later throwing away my result (I don't keep working in it).
Much of my client work is on a consultation basis as well, so rather than being a part of their internal structure (if there is one) I'm expected to be self-driven, self-organizing, and get the work done without them having to worry about it.
The term 'cowboy coding' usually only refers to programmers who do risky things, ignoring best practices though:
But I think I can list some advantages of 'freeform development' that might get missed in the 'cowboy coding' connotation:
Free to explore: this is excellent when the problem domain is unknown. When you begin with a structure and you don't yet know the shape if what needs to be built, it's hard to argue that approaching an unknown problem with a partial solution isn't a case of 'premature optimization' that might turn into technical debt if you gamble wrong, and a different structure ends up suiting the problem better than your starting point.
Free to refactor: similar to exploring the problem domain, once you do understand the shape of the problem it's much easier to refactor the code you have written to suit it. Imagine you are tailoring a garment to a person, is it easier to tailor a brand new garment that's never been altered before, or to adjust a garment that's already been fitted and tailored to a different person? Freeform development lets you keep things loose until you need to tighten them up, then gives you the freedom you need to do it well
Free to throw away: I think at least for me, the amount if disposable code I generate versus the amount of code I hang onto is key for reaching the quality level I desire in the code I hang onto. If I was working within a structure that made it more difficult to throw away code, I imagine I would be more tempted to polish code that was less-good, rather than throw it out and rewrite the code I actually need. The more structure and process you have, the harder it becomes to write code you intend to throw out as well. You get locked into writing only what you keep, and keeping all you write, and that's not a process that produces the best code all the time.
If this was a chef in the kitchen rather than coding we might call 'cowboy coding' something like 'cooking without a recipe', which sounds a lot better than 'cowboy cooking'. I imagine there are times and places where chefs follow recipes and strict guidelines for what they are making, and there's probably a lot of time spent doing things by feel, exploring, and experiencing what they are cooking that isn't rigidly dictated in advance. Both types are useful, both styles produce good results. It's all about balancing your knowledge with your learning while addressing the task at hand!
CowBoy coding : Coding what you want, whenever you want, as you want. For which situation this style fits the best? When the only thing that matter, are short-term results. Build a proof of concept, learn new concepts, understand part of code. Local benchmark, illustration, etc.
Last, but not least : WHEN THE F*CKING MANAGER IS F*CKING BAD. and doesn't deserve anything else
Cheers 🍻!
If you're a senior responsible engineer, then autonomy should not be a negative role in your development process. That said there is value in
otherwise you will end up with a spaghetti western "The Good, The Bad, and the Ugly." If you're a prolific coder like Stallman, you might pull this off. If you're just a hack then this is a license to write unmaintainable code that can't adjust to changes in requirements.
I have occassionally cowboy coded to see
Mostly I do CC on challenges like codefights.com, and 'trivial' work like translating MIPS optimizing compiler in C++ from its original pascal.
Well if you're self disciplined it can be rather productive. If not you don't.
The question to me also is about time-frame and desired outcome. and other aspects.
Because if it's research and prototype development basically cowboy coding seams like a valid choice to me.
But for a structured business-process on a medium to large scale where software is the key/main product. It seams rather unpredictable.
as Matt Strom mentioned it seams wasteful, but than research always should be seen as wasteful/uncontrolled because you're going into new areas.
I think that's the point, cowboy is great for pioneers, researchers, free spirits.
But it's not a general attitude I would recommend for everyone.... but than I would not recommend anything these days. The team has to decide based on the target and usecase what's needed.
Cornerstones however are relevant... anyhow blah ... I think I made the point I wanted to make.
Correct definition:
Cowboy Coding: The JavaScript framework scene 2 years ago.
:P
I have not practiced cowboy coding. It does seem to have some similarities to several manifestations of Agile, such as Scrum, in which teams are self-organizing and have a lot of autonomy. I think Scrum teams are quite enjoyable to work on.
However, the "cowboy" part of it sounds undisciplined and prone to wasting resources. As your definition states, it does seem like a derogatory term.
Gergely Polonkai
You have to believe in things that are not true. How else would they become?
Oh, I do that a lot. Most projects I do this way never make it to production, though.
Cowboy coding is a nice thing when you make a prototype or proof of concept. When the project leaves that phase, this style does more harm than good.
But thatʼs just my ¢2.