I think almost every experienced programmer has gone through three stages and some go through four:
- Cowboy coders or nuggets know little to nothing about design and view it as an unnecessary formality. If working on small projects for non-technical stakeholders, this attitude may serve them well for a while; it Gets Things Done, it impresses the boss, makes the programmer feel good about himself and confirms the idea that he knows what he’s doing (even though he doesn’t).
- Architecture Astronauts have witnessed the failures of their first ball-of-yarn projects to adapt to changing circumstances. Everything must be rewritten and to prevent the need for another rewrite in the future, they create inner platforms , and end up spending 4 hours a day on support because nobody else understands how to use them properly.
- Quasi-engineers often mistake themselves for actual , trained engineers because they are genuinely competent and understand some engineering principles. They’re aware of the underlying engineering and business concepts: Risk, ROI, UX, performance, maintainability, and so on. These people see design and documentation as a continuum and are usually able to adapt the level of architecture/design to the project requirements.At this point, many fall in love with methodologies, whether they be Agile, Waterfall, RUP, etc. They start believing in the absolute infallibility and even necessity of these methodologies without realizing that in the actual software engineering field, they’re merely tools, not religions. And unfortunately, it prevents them from ever getting to the final stage, which is:
- Duct tape programmers AKA gurus or highly-paid consultants know what architecture and design they’re going to use within five minutes after hearing the project requirements. All of the architecture and design work is still happening, but it’s on an intuitive level and happening so fast that an untrained observer would mistake it for cowboy coding - and many do .Generally these people are all about creating a product that’s “good enough” and so their works may be a little under-engineered but they are miles away from the spaghetti code produced by cowboy coders. Nuggets cannot even identify these people when they’re told about them , because to them, everything that is happening in the background just doesn’t exist.
Some of you will probably be thinking to yourselves at this point that I haven’t answered the question. That’s because the question itself is flawed. Cowboy coding isn’t a choice , it’s a skill level , and you can’t choose to be a cowboy coder any more than you can choose to be illiterate.
If you are a cowboy coder, then you know no other way.
If you’ve become an architecture astronaut, you are physically and psychologically incapable of producing software with no design.
If you are a quasi-engineer (or a professional engineer), then completing a project with little or no up-front design effort is a conscious choice (usually due to absurd deadlines) that has to be weighed against the obvious risks, and undertaken only after the stakeholders have agreed to them (usually in writing).
And if you are a duct-tape programmer, then there is never any reason to “cowboy code” because you can build a quality product just as quickly.
Nobody “prefers” cowboy coding over other methodologies because it isn’t a methodology. It’s the software development equivalent of mashing buttons in a video game. It’s OK for the beginner levels but anybody who’s moved past that stage simply won’t do it. They might do something that looks similar but it will not be the same thing.