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
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.
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.
Aug 11, 2011 at 5:05
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.
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:
People like this produce truly great results with very little management and structure overhead, but they are rare.
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:
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.
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:
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.
EDIT: For future reference, my answer is for another question, which has been merged into this one. It's quite out of place here, but that was not my call.
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.
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.
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.
From my experience, cow boy coding WITH source control is the best and most bug free way to develop large software systems.
This kind of person is called a hacker, and it's usually not a complimentary term from the more professional among 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 developer's 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. It's 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 they created new methodologies to organise coding while 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 it's like it is and maybe a few tips to deal with it professionally.
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.
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.
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.
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.
When I think "traditional" methodologies, I think "management doesn't know how to understand developers, so instead of coming into the developers world and understanding enough to know what's going on, they make the developers 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 are things you need to do on a very large project, and there are things you need to do on small projects, and there are things that you do on both.
For example, 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 are two of us, I'd probably have that list shared, but in a very simple format (probably just a note stored in our code repository). Once I have 3 or 4, I'm looking for some sort of work item system.
Only when prototyping of very simple features.
Then once done and considered the right way, I ditch the code and get serious.
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.
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.
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.
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.
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.
Cowboy programming is a rather sure way of creating a big ball of mud. Which, as unpleasant as it sounds, tends to deliver...
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.
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 need 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.
I find your post interesting. I've often shared views with your subject, and her feeling is 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 worthwhile 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 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...
