Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Most programmers defending methodologies politically correct like Agile, Waterfall, RUP, etc. Some of them follow the methodology but not all of them. Frankly, if you can choose the methodology, you certainly would go to mainstream "correct" methodologies or you would prefer the "easier" methodology like cowboy programming? Why?

I know it depends. Please, explain when you would use one or another. Please, say what advantages do you see on Cowboy coding.

See about Cowboy coding on Wikipedia

share|improve this question

closed as not constructive by Thomas Owens, ChrisF Jan 21 '12 at 12:03

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

10  
An experiment was performed once with two groups of people who were asked to make clay pots in a fixed time frame. Group 1 were told to make the highest quality pot they could, group 2 were told they would be measured on the weight of all the pots produced. The quality of the final group 2 pots was higher than the group 1 pots. Alas I have not been able to find the original source of this experiment, but the overriding point is "the higher the number of iterations, the better the quality". Were group 2 cowboys? Probably. –  adolf garlic Sep 25 '10 at 12:42
3  
"Cowboy coding" a terrible choice of words if nothing else. When used to refer to people in a team "cowboy" often means something along the lines of "the person who just does their own thing and doesn't care what that means for the rest of the team". But the question of the value "less structure" is a good one. –  MIA Sep 25 '10 at 15:40
3  
I think you should put your definition of cowboy programming (directly) in your question as both the wikipedia page and answerers seem mixed on what really is cowboy coding. Do you mean just not to use any methodology? Because lots of people seems to think that cowboy coding doesn't do design at all. At least for me it just meant no formal process - not that you jump coding straight away. I think since you're the one asking the question you should define it according to what you wanted to know. –  n1ckp Oct 10 '10 at 20:50
3  
Why does it matter HOW she does it rather than what she produces? She can type with her tongue for all I care. We are all different, and the only thing that worse than a mandate would be a man date. –  Job Jun 11 '11 at 1:59
28  
this is the most important part of the question I have a programmer that codes fast by dismissing revision control, documentation, patterns, tests, and methodologies. Dismissing revision control is the mark of a very selfish personality and discredits anything else this person says ever. –  Jarrod Roberson Jun 11 '11 at 3:34
show 13 more comments

26 Answers 26

I think almost every experienced programmer has gone through three stages and some go through four:

  1. 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).

  2. 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.

  3. 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:

  4. 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.

share|improve this answer
16  
Beautifully articulated. –  Brandon Sep 25 '10 at 14:57
13  
The problem is too many people want to be duct tape programmers without being Architecture Astronauts first and then quasi engineers, which means they are forever Cowboys. So, I think I can point at that list and say "it looks like a career progression" ... too bad the management types think AAs are the pinnacle. –  MIA Sep 25 '10 at 15:46
8  
I don't even know where I am on this list :S Sometimes I can hear about a project and know instantly how I'm going to build it, like 4, and then I'll suffer serious analysis paralysis and over think the architecture, like 2, then I consider YAGNI and think about business value and try to be pragmatic, and feel like a 3, and then I wind up making a mess like a 1. –  Carson Myers Aug 11 '11 at 5:05
4  
Some developers are also genuinely good at the planning/design/estimation part but just aren't good at executing. Those people make good project managers but need to rely on the skills and advice of great programmers. –  Aaronaught Aug 11 '11 at 11:21
9  
I should give you -1 for implying that a highly paid consultant is on duct tape programmer skill level (hint: most of them aren't, not even close). But I gave you +1 anyway. –  Falcon Jan 21 '12 at 11:28
show 12 more comments

Yes.

I also prefer leaving my socks on the floor where I took them off, my desk covered in printouts and old snack wrappers, my sink full of dirty dishes, and my bed unmade.

I don't consider a vacation planned in advance to be a proper vacation, a meal eaten with a mind toward nutrition proper food, or staying on known trails proper hiking.

I like to have fun, be surprised, learn new things, make mistakes, and never be quite sure if I'm going to make it back. And sometimes, that attitude is exactly what's required to get a project off the ground...

...but most of the time, it's just irresponsible. When the dance ends, the piper will be paid... Forget this at your peril.

share|improve this answer
show 1 more comment

You're exactly correct. This "cowboy programming" approach may get the first revision of the code out faster, but that time savings will be more than lost thanks to:

  • Additional bugs
  • Additional time needed to find the bugs you would would have had anyway
  • Having to reverse engineer your code to remember what you did when you need to make a change in six months
  • Extra time spent training additional developers that need to work on your code
  • Not having a log of revisions to look back to when you make a change that breaks something
  • Not having modules you can easily reuse in later projects
  • And on and on and on

Like Neil Butterworth mentioned in his answer, sometimes you gotta do what you gotta do. As a general practice though, no, banging out code as fast as possible with no time spent on source code control, patterns, documentation, etc. is a very bad habit to get in to.

Good for you for analyzing your coworkers and considering whether their habits are beneficial or harmful instead of blindly doing as they do.

share|improve this answer
6  
There are always exception. Some coders might be geniuses, have photographic memory but little patience. Others are not that fast but persistent; they grind away at the task one byte at a time until it becomes their bitch. There are many ways to be a good programmer. Maybe cowboy programming works for her. It might not work for the asker or many others. However, why mandate HOW someone should work , when the important thing is the rate and the quality of results. Why pass a law prohibiting 12-cylinder engines, when you can simply reward higher mpg through tax credit? –  Job Jun 11 '11 at 1:54
2  
@Job - There are sometimes exceptions. The percentages will eventually take over. There might be exceptions when evaluated in isolation of perfect code (no errors, no problems, etc) but eventually cowboy coder habits will hit her company (and her team, and her) in the butt. You might win at Russian roulette five times in a row but keep playing and my money is on the bullet. –  Thomas Jun 11 '11 at 5:31
2  
@Job: Yes I sort of agree, up to a point. But refusing to consider anything else (which = refusing to learn), and refusing to use source control are two big red flags that say to me: Might be fast, but a real dangerous boofhead. –  quickly_now Jun 11 '11 at 8:36
1  
Following a formal process isn't the only way to write quality code, and doesn't guarantee quality code anyway. Having a formal process is less important if a persons work is "loosely bound" with other peoples work. Version control, if anything, gets more important as the process gets more informal, though. On "refusing to learn" - how many bad experiences has this person had with bad processes and bad systems in the past? Inference is imperfect, but it's basically the only way we have to understand anything outside our own heads, and with the right (or rather wrong) experiences... –  Steve314 Jun 11 '11 at 19:15
show 1 more comment

This really comes down to the question of whether or not you can implement things correctly without a tight structure in place and lots of time eaten up in planning.

I'm going to throw something out here on this one that may be really unpopular: customers generally want things handled in a cowboy fashion.

That is, they want to request something get done, and have someone jump on it, execute it, and get it out there. No project management, meetings, conference calls, or forms. Just do it. I've never had a customer say "hey, this was done a little too quickly for our tastes, we'd appreciate it if you would put a little waterfall or something in there next time".

Team methodologies and structure are designed to level the playing field of a project and get varying levels of developers on the same page, working for the same goals, in the same ways.

The successful "cowboys" that I have worked with are able to:

  • Identify the simplest way to implement something quickly
  • Know at what point it will break
  • Write clean, readable, and straightforward code
  • Predict how the users will use it, abuse it, and break it
  • Scale it / abstract it in the right places, and not go architecture astronaut on it
  • Know where and how to handle edge cases and exceptions

People like this produce truly great results with very little management and structure overhead, but they are rare.

share|improve this answer
6  
I really wouldn't call your final list "cowboy" coding. It's more like the quintessential "duct tape programmer" glorified by Spolsky. The difference is, a cowboy coder just starts slinging code together without paying any heed to overall design; the "duct tape programmer" sort of makes it up as he goes along, but still has a plan; he's just doing most of the design work at an intuitive (and sometimes iterative) level. –  Aaronaught Sep 25 '10 at 13:52
3  
Customers doesn't necessarily want it cowboy-style, they just want it cheap and fast. It is then up to us to deliver. –  user1249 Dec 3 '11 at 23:03
add comment

It completely depends on whether I'm working solo, or in a team.

If I work in a team, some conventions and agreements are required - everyone in the team must follow some commonly agreed standard to work towards the common goal so that their efforts are compatible.

But if I work alone, then of course I want to be a cowboy. All great creations in the world have been invented by a single mind, or at most two, working cowboy-style. Just to name a few:

  • Classical mechanics? Cowboy Isaac Newton, later additions from Leibniz, Lagrange, Hamilton.
  • Airplane? Cowboys Wright.
  • Theory of relativity? Cowboy Albert Einstein.
  • Fundamental science of computers? Cowboy Alan Turing.
  • Transistor? Cowboys Walter Brattain and John Bardeen.

Teams are good at making incremental improvements and putting together new systems based on proven recipes fairly quickly (provided that they're being led well), but it's rare to hear about an actual invention made by a team. Team work and the methods it requires have their virtues, but so does cowboy coding.

share|improve this answer
add comment

She's just lazy, arrogant, ignorant and extremely selfish. This behavior is reckless.

I mean, it's not that she uses an unconventional or maybe outdated methodology. She just consciously uses none. No standards. No quality assurance. No whatsoever. Where does she expect software quality to come from? Trees?
It is funny she actually denies the experience of the people you quote, when she quite obviously lacks it. Providing verifiable and relevant arguments to question their claims is valid. But just trying to discredit them by denying their experience is not.

But, the main point is: How much time does version control take?
If she cannot be convinced to invest the 5 seconds every now and then, you should take it up to her boss. Version control is not optional. Full stop.

And once you have her using version control, you can easily track which bugs she introduced. And let her fix them. It's her mess, why should you clean it up? If she thinks her approach is better, then let her do it - all the way.
Assuming she actually can do it (within reasonable time), you still have a problem: teamwork with her is close to impossible. And this is something you will have to solve by either convincing her (which sounds unlikely), making her leave (for the sake of your company) or leaving (for the sake of your sanity).
But her failure in the first place is far more likely and should definitely prove your point. And then she'll start adhering to best practices as many people with a lot of experience do.

share|improve this answer
1  
Sometimes the truth hurts plain and simple... –  ChaosPandion Jun 11 '11 at 17:42
add comment

Depends on the problem. A good senior developer will write very compact, simple, and robust code that's very stable and uses all best practices without churning through pages of documentation and tons of different patterns and paradigms. But he will also know when he can afford to do such things.

I would be shocked if he would take a new problem and start to design an application that requires man-months from scratch. But if it's a plugin, simple tool you can write in 2 hours, a function that does some conversion and is not intended for a reuse, design and patterns are actually only good for wasting the time.

Also, I guess large part of the design was already processed in a background thread somewhere inside the senior developers head.

You have to start worrying when the senior developer starts churning classes of a complex system, or new applications from scratch, and without planning step.

share|improve this answer
7  
your answer completely skips over the most telling part of the question "I have a programmer that codes fast by dismissing revision control ..." anyone that dismisses revision control and promotes this opinion to junior level employees is criminal. –  Jarrod Roberson Jun 11 '11 at 3:29
1  
@Jarrod: or not. There's little point in committing incomplete/dysfunctional code. –  Denis Jun 11 '11 at 18:03
1  
@Denis - that's mostly what a branch is for. The history of decisions, changes, mistakes, dead ends etc during the development of incomplete/disfunctional code is IMO a part of the documentation of that code, and very important during maintenance. Easier branching and merging is a good reason to replace subversion with a distributed VCS. –  Steve314 Jun 11 '11 at 19:46
show 4 more comments

No.

But for small projects I do it nevertheless. And regret it, every single time. It's like any other bad habit that I need to get rid of.

share|improve this answer
show 2 more comments

It depends on circumstances. For example, after some disastrous trading scandals, several electronic stock exchanges insisted that auto-trading flags were added to all trades. And this had to be for all trading software inside a week. I mean it had to be done - if the flag wasn't there you couldn't trade. In circumstances like that, all good practices go by the board - you just have to go (as we used to say) "hacky, hacky, hacky". And in those circumstances, writing code fast and accurately is key. Particularly as there were no test systems available.

share|improve this answer
show 5 more comments

this kind of person is called a hacker, its usually not a complimentary term from the more professional amongst us.

As you've noticed, the time saved in design, organisation and control is lost in debugging. And often in finding which release of code was the one that was actually shipped. If you can find it at all!

I find this kind of person is too wrapped up in themselves, think they're too good to work with the 'limitations' others have to suffer and so don't bother with them, and that loses even more time as the rest of the team has to clean up after them. They are also not too involved in the bug-fixing process (that's a maintenance dev task, well beneath the 'l33t coder's skills and talent)

So, it might be a common approach elsewhere, but at my place (and I'm a senior coder who has tendencies to this approach, ahem) we do not suffer it. Its not that we demand a ton of processes and procedures but we do insist on a minimal amount of organisation, source code control (which to be honest is bloody east and damn useful!)

Kent Beck et al, are all professionals who saw the old process-laden ways were bad in themselves, so created new methodologies to organise coding whilst still keeping it more craft-oriented, and then told everyone else about it - by publishing books (how else did you do it back then before the internet?)

You sound like you have it right - do not accept poor practice just because someone else can't hack it. Your team lead or manager should be coming down hard on this 'rockstar', but if they're not.. well, that still doesn't prevent you from doing the right thing. Just do not accept shoddy practice from her, if she screws up (and she will!) then let her clean it up. You stick to good practices (and you know what they are) without letting them take over to the detriment of your coding productivity, and you'll be good for the future.

Here's an essay from a truly insightful writer. It doesn't fix your problem but it does give you a few insights into why its like it is and maybe a few tips to deal with it professionally.

share|improve this answer
3  
I'd say "hack" instead of "hacker". –  Mike Sherrill 'Cat Recall' Jun 11 '11 at 3:45
1  
They're a cowboy, just as the OP stated, don't go muddying up what a hacker is. Leave that to the media. –  Slomojo Jun 11 '11 at 4:41
show 2 more comments

From my experience, cow boy coding WITH source control is the best and most bug free way to develop large software systems.

share|improve this answer
show 1 more comment

I think one of the commentators had it right - its all about the results.

If the person can produce a good product - something that does what its supposed to do, and is maintainable and reliable - then what does it matter if formal methodologies or processes are followed? Processes are great to ensure a floor in quality, but if someone's working above that floor already, then the processes add nothing into the equation. Too many developers these days, imo, seem to think the point of programming is to adhere to processes, as opposed to producing a good product.

share|improve this answer
add comment

The only important fact is the long term product results of the team.

There is a claim that a team including one great programmer (or more) will produce better results than a team with an even larger number of average programmers coding at an average rate.

If the cowboy produces stuff that the regular programmers don't (for a given deadline or spec), and the team with the cowboy even has to spend a few man weeks/months cleaning up the cowboy's mess, they might still end up with the better result sooner.

If the team with the cowboy can't clean up (document, debug, integrate, maintain) the mess even after many man months/year's, then whatever advance the cowboy created did not give the team a long run advantage.

Decide which, and optimize the team's roster.

Not every programmer works (or should work) the same way, as long as the end result is good.

share|improve this answer
3  
There is a claim that a team including one great programmer (or more) will produce better results than a team with an even larger number of average programmers coding at an average rate - That is until the great programmer leaves and takes their saddle, horse and your code with them. How good do those results look then? –  Thomas Jun 11 '11 at 5:38
1  
@Thomas : Risk factors cut both ways. The guy financing all the paychecks could walk out of the next funding round when even a hacked-together proof-of-concept doesn't appear soon enough. How good do your slow horses look now? All engineering choices are gambles. Place your chips. –  hotpaw2 Jun 11 '11 at 6:16
1  
@Thorbjørn Ravn Andersen, @hotpaw2 - There is another dynamic at play here. A coder that is willing to use, if not actively pursue, risky techniques, even when those risks are unnecessary, is in general going to make riskier choices elsewhere. I.e., their choice against source control is indicative of a riskier pattern of behavior that will eventually bite them and their company. Even in a gamble, sometimes you can beat the house but eventually the percentages beat you down. –  Thomas Jun 11 '11 at 6:26
show 3 more comments

When I think "traditional" methodologies, I think "management doesn't know how to understand developers, so instead of coming into the devs world and understanding enough to know what's going on, they make the devs come into their world"

Fundamentally, when I think of "Agile". I think "you do what you need to do to minimize the inefficiencies introduced by multiple people working together." So I'm firmly in the camp that "there's no such thing as THE Agile Methodology, just a set of values and principles".

In other words, there's things you need to do on a very large project, and there's things you need to do on small projects, and there's things that you do on both.

e.g. I would not have more than the simplest of backlogs for a project I'm working on myself... it would just be a to-do list. If there's two of us, I'd probably have that list shared, but in a very simple format (probably just a note stored in our code repo). Once I have 3 or 4, I'm looking for some sort of work item system.

share|improve this answer
add comment

Yes, but you have to recognize when NOT to do it.

On anything small you are probably fine, but if you have something complex, dangerous, constrained, etc you need to be able to recognize when a proper design is worth the extra time.

I also think you should definitely think through Aaronaught's answer. Cowboy means different things to different people.

share|improve this answer
add comment

You might find some insight in my answer to Frankly, do you prefer cowboy coding? The trouble is, "cowboy coding" means different things to different people, and it's not immediately obvious, to the untrained eye, which version you're seeing.

When somebody can look at a problem and immediately start belting out code, quickly and accurately, that may be the sign of a master engineer who has seen it all a thousand times before and already knows the best way to solve the problem.

Or, it may be the sign of a rank amateur.

I will tell you one thing: Refusing to use version control or write tests because they are too "academic" is definitively not a "senior" or even remotely professional approach. You will never, ever see this kind of thing being done at a major software shop such as Microsoft or Google, and will probably not see it in most startups or reasonably mature enterprise teams either.

The risks are just too great. What if your PC dies overnight? Bye bye 3 years of productivity. Okay, so you make backups; then what happens when you make a major change, realize that it was completely wrong, and have to revert it? This happens even to the most experienced and talented of developers because the requirements are wrong. If you're not running any kind of version control, you're just going to be spinning your wheels in the mud. I've been there, once, and would never go back.

There's just no excuse - it takes 10 minutes to set up a repository and 10 seconds to do a commit. It makes up maybe 1% of your total development time. Tests, if you're in a hurry, can easily be whittled down to 20-30 minutes a day and still be reasonably useful.

I'm no fan of Agile (note the capital A) methodologies but sometimes you really do need to just roll up your sleeves and start writing the damn code. I've seen people and teams with "analysis paralysis" and productivity really does take a visible hit. But dismissal of the basic tools of our trade such as revision control and tests is really the clincher for me; this person does not belong in a senior position.

share|improve this answer
add comment

Only when prototyping of very simple features.

Then once done and considered the right way, I ditch the code and get serious.

share|improve this answer
add comment

I've done it once on a real project (at the time we called it Samurai Programming, after the Samurai Tailor series of sketches on Saturday Night Live), and much to my amazement, it worked out well. Of course, what I started with was garbage, so there was little risk of making it worse.

However, I am a "neat" at heart and dislike the shoot-from-the-hip style of development.

On the other hand, heavily process-laden modus operandi is not to my taste either. I just like to plan before I act.

All in all, I feel that the amount of formal process that is appropriate depends heavily on the magnitude (size of the code, duration of the project, number of developers, kinds of requirements, etc.) of the project. I want rigor and strict criteria to be imposed on people developing the software for avionics or biomedical equipment, e.g. For games, e.g., there's far less down-side to any failures, so the cost and burden of rigorous and methodical development practices is not really justified.

share|improve this answer
2  
Frequently you need to solve the problem in order to figure out how to solve it... –  user1249 Dec 21 '10 at 21:18
add comment

It depends (heavily) on the size of the project. On one hand, to get a decent result you need to have a design. On the other hand, if the project is small enough that you can conceptualize the entire design (are most of it anyway) without writing it down, drawing diagrams, etc., then you're probably just as well off without that extra work of documenting everything you do.

Almost everybody has heard enough horror stories to realize that trying to jump in without a clear idea of what you're doing and where things are going is a recipe for disaster. What's far more rarely pointed out is that the opposite can be equally disastrous. Just for example, most of us routinely write small tools in the process of programming. Writing a complete specification, tests, documentation often just isn't worthwhile. There's a threshold below which productization isn't worthwhile -- people often dislike reinventing the wheel, but in some cases it's easier to reinvent than avoid it.

In cases like this, what's often is worthwhile is productizing a library to make tasks like this easy. With that, the front-end code often becomes so trivial that writing (or modifying) code to do what you want becomes easier than sorting out how to get a complete program to do what you want. Consider, for exmaple, gnu indent with its 50+ different flags, many of which interact in various subtle ways, so about the only reasonable choices are 1) don't use it at all, or 2) decide to like what it gives you instead of trying to get what you originally wanted.

share|improve this answer
add comment

No, never.

I always do requirements analysis, think about architecture, design the details, and then code. Even if I work solo at home for a personal project.

And I would instantly fire a developer in my team if he/she were working in a cowboy style. We are engineers and have a responsibility with the customer and the users.

share|improve this answer
show 4 more comments

I have the feeling that your distaste for her style is causing you to slightly misrepresent it. You say the cowboy approach is paid in debugging - is this what is already happening, or is that your assumption of how it will play out?

Fair disclosure - I am a senior developer myself, and I often forgo a formal process for design and going on experience. Not having a formal process for someone who is very experienced in the problem domain is quite common. If you have solved a problem dozens of time, you don't a formal process to formulate a similar solution again.

A formal process deals with the design of code - I don't see why more bugs should be introduced because a formal process is missing. The only big problem I read in your account is that revision control is not being used - which is not only selfish but downright reckless on the developer's behalf. Is she in fact not committing at all, or just not committing in a pattern that is to your liking?

Not having a formal approach to design is not 'cowboy coding' in my book (not using revision control is though). Experience should be used for exactly that - to reduce time needed to come up with a 'good enough' solution. Remember, you have to solve the problems you have currently and make the code easy to change, not design for future scenarios that might never happen. With experience you get a good feel for how to do that very fast.

share|improve this answer
add comment

I don't think cowboy coding is a senior approach.

As others have said, there's a real danger in discarding version control. Skipping documentation and analysis could also mean risking delivery of something the user doesn't want. Just my opinion, but I don't think you go from "coder to developer" if all you do is cowboy code.

However, yes, there are exceptions like the one Neil Butterworth mentions. And in these situations, I'd rather have an experienced senior developer be the one that has to do the cowboy coding.

share|improve this answer
add comment

I find your post interesting. I've often shared views with your subject and her feeling that over formalized methods are stifling. As someone else noted, if she's a genius, and can track a multitude of mental notes at the same time without forgetting or getting confused, then it's quite possible to maintain a monolithic chunk of convoluted code and get it to do amazing things with completely obscure changes. There's a certain mental happiness that comes to the brains of people that can do that - it's like being a God of a little universe in your mind.

However, smart employers have learned the hard way that nobody but the original author can ever do anything worth while to that code. If the programmer moves on, they end up wasting a lot of money figuring out that the only option is to re-write (I used to think think that meant total loss, but I realize these days that you don't destroy the intrinsic result of iterative development at the level of external functionality).

Personally, I woulnd't mind having someone like that on the team, because in a crunch, they might do something that nobody else thinks of.

On the other hand, be your own person and decide for yourself what the answer to your question is, because the only thing that's for sure is that nobody has it figured out when it comes to building software. It's one of the things that makes it an interesting field...

share|improve this answer
show 1 more comment

Cowboy programming is a rather sure way of creating a big ball of mud. Which, as unpleasant as it sounds, tends to deliver...

share|improve this answer
add comment

I think newer programmers tend to do some cowboy coding things when taking on aspects of a project / scopes that they may not have a lot of experience with or when they are trying to "just get things done" due to pressure from a boss, etc. I know I have definitely gone down this path a few times because I was lacking in knowledge of the proper pattern to use and just "hacked my way through it".

The difference between me and the person you are complaining about is that I usually soon after realize that I could have done it better and made it more maintainable and it usually spurs me to learn more and improve my skills (by reading books / articles on the subject). When I go back to debug some of these hacked solutions I usually find it to be a pain and it contributes more to my wanting to learn how to do it the "right way". I think this person you are describing is basically stuck at an infantile level of self reflection and it letting their own ego get in the way of actually improving their skills as a software developer, doesn't seem like someone I would want to work with.

share|improve this answer
add comment

There appear to be two camps - those who favour results, and those who favour principles. I fall into the latter.

I am a mediocre but arguably conscientious programmer - my main concern when coding, beyond getting the job done, is that I am helping whoever uses my code to get THEIR job done. I can't say as that I've always achieved that - but that's what I aim to do.

Sure, you may have a hotrod on your team - but what happens when they take a couple of weeks leave and you're asked to debug their work, or add stuff to it? Ultimately, cowboy programmers are not team players. They may make great code, but if the team depends on them - then it's dangerous.

share|improve this answer
show 1 more comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.