There is More Than One Path to Success

For a long time I had a difficult time reconciling that both the cowboy coders and the meticulous software craftsmen are able to achieve extraordinary results.

I’ve never wanted to believe the deploy-straight-to-production coder was effective. I always sought to find some way to prove that this kind of behavior or methodology always produced an inferior result.

But, while some of these cowboy coders smack right into the wall, and crash and burn, others truly do become heroes of their project and are able to, time and time again, save their companies from total disaster.


As much as I hate to admit it, these renegades are often the most valuable employees in the companies they work for.

It’s not just cowboy coders who are successful

That is not to say cowboy coders are the only ones who achieve stellar results. There are also developers who are the exact opposite of cowboy coders; those who follow the best practices of the time, meticulously test their code, write unit tests, see their jobs as crafts and treat everything with the utmost professionalism.

These are the ones we expect to write the best code and produce the most results–and sometimes they do–but, often we see these software craftsman types having a production value close to zero. They know how to write code and how to do it beautifully, but all the ceremony and meticulousness gets in the way of performance.

Now, before you pull out your pitchfork, while it might sound like I am on the side of the cowboy coder, I actually identify myself more with the software craftsman approach. I believe in writing solid, elegant code and doing things “right.” That is exactly why I am so puzzled by those cowboy coders who seem to achieve exceptional results.

In my mind, they are dong everything completely wrong. I often try to rationalize why their choices and methodologies are wrong; why that kind of thinking and “sloppiness” will eventually bite them and they’ll end up averaging out to less than mediocre results.

And, like I said, while deploying straight to production definitely can have some dire consequences, and staying up all night single-handedly writing an entire feature that should take two weeks in a single night can produce some difficult-to-maintain code, it turns out that some of these renegades actually get results that far outstrip doing things the “right way.”

Conflicting ideas

For a long time, I had a hard time reconciling these two conflicting ideas. I wanted to believe my way was far superior. I wanted to find a smoking gun that proved that shortcuts and late night code binges always resulted in abysmal failures and spectacular explosions. But, the evidence was just too overwhelming to ignore… both ways worked.

Even though the cowboy coder and the software craftsman have completely different approaches and completely different philosophies about writing code, even though one is meticulously careful, and the other is at times downright reckless, both can be extremely successful.

There was too much data to ignore. Time and time again I would see entire companies that owed their success to that one grumpy coder with the keys to production. In fact, when I think back and try to come up with companies that had notorious bad code and coding practices, but became wildly successful, I can come up with a pretty big list: Twitter, Facebook, WordPress–hell 4Chan. But, when I try to come up with a list of extremely successful companies that owe their success to meticulously strict software development practices and test driven development, I know they are out there, but I can’t really name any.

I spent months thinking about complex ways to do database migrations to ensure that the version of code matched the database version exactly. I developed complex systems to ensure that deployments went as smoothly and as autonomously as possible, but I watched in horror as my clients demonstrated to me their database migration processes which consisted of using a SQL comparison tool to manually push changes from development to production “fairly often.”

But, at the end of the day, their system worked and they rarely had problems. If they did, they figured out how to fix them and moved on. When my system failed, it was almost always a catastrophic failure. Recovery was often very difficult. Sure, when things worked, it was pretty easy to say that my choice to do things the right way was correct–and overall, I still believe it is the best way to go–but, it is pretty hard to tell the company that has been using SQL compare to migrate their database changes that they need to invest thousands of dollars and months worth of time fixing something that is working perfectly well for them.

There is only one sensible conclusion to be drawn from this. There is only one clear way to resolve this paradox. As Francisco says in Atlas Shrugged, “Contradictions do not exist. Whenever you think that you are facing a contradiction, check your premises. You will find that one of them is wrong.”


It must be true then that there is no “right” way to develop software, or rather that there are many right ways to develop software–as distasteful as many of them may seem to be.

I can’t believe how long it took me to figure out this simple truth. I do believe it is a truth you have to come to on your own, on your own terms. As I write these words, I realize you, who are reading this post, are likely to disagree with me. I can only say that I thought the same as you once. In some regards, I still do. I’m just slowly coming to accept that much of the time I spent looking for the right way, was waste.

Deeply, we want to believe that there is a single truth. We want to believe we can find the right path, because it is far too overwhelming to think that no one has the answers; that there might not be a right path.

Not just software development

And this doesn’t just apply to software development. In so many areas of life there are multiple, sometimes conflicting paths, that lead to the same destination. I’ve seen stock traders and real estate investors with completely different strategies, completely conflicting viewpoints, who’ve been wildly successful by choosing to do what they felt was right and ignoring everything else.

I’ve seen bodybuilders and athletes with completely different theories on diet, nutrition, exercise and even basic physiology, achieve phenomenal results. By all accounts one way should be far superior to the others–yet, it isn’t.

Now, this isn’t to say that you can just do whatever you want and you’ll be successful at it if you stick with it long enough. There is a such thing as universal truth. I firmly believe that. I just think that our view of it is so murky, so out of focus, that we are forced to come up with different explanations of the same phenomenon. It’s like Newtonian physics and quantum physics. In many areas they seem to be in complete contradiction, but we know it is only because we are unable to see the deeper truth.

Somewhere, deep down, behind nearly opaque glass, there is a similarity between the cowboy coder and the software craftsman that makes them both successful. There is a reason why both ways work, we just don’t know it yet–we may never know it.

But, what is the point?

So, what can you gather from all this? Why even bring this up?

Because, I think it is important to understand that the more sure you are of something, the less likely you are right. I’ve been proved wrong more times than I can count, because I held onto the belief that there was only one road to success and that I was on it.

In contrast, I’ve found that my greatest successes have come from the times that I let go of my own viewpoints and beliefs–if only for a moment–to see that even though I didn’t agree with or even understand someone else’s perspective, there was often something to learn from it.

It’s difficult to let go. It’s difficult to accept that we are never going to find the answer; that the truth may be unknowable. But, if you want to be the best that you can be, if you want to assist others on their journey, rather than block them and hold them back, you must realize there are multiple paths to success.

For more deep insights into the psychology of software development, random ramblings on personal improvement and productivity, and an occasionally valuable insight, sign up here and I’ll deliver these posts and more directly to your inbox.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."

  • devhammer

    John, I don’t disagree with you at all regarding there being more than one way to get to a successful outcome in programming. In fact, I’d go further and say that there’s clearly a spectrum between the cowboy coder and the software craftsman, sometimes even in the same person.

    Personally, while I strive to learn as much about development as I can, and follow best practices to the extent possible, I’ve also been known to resort to “git ‘r’ dun” programming from time to time. In some cases that’s served me poorly over the long haul, making more work for myself later. But there have also been times when such an approach was exactly what was needed at the time.

    The other missing piece in your analysis is skill. A deeply knowledgeable programmer may choose to “go cowboy” knowing the risks, and doing what’s necessary to mitigate them, which may lead to a very different outcome than a greenhorn who tries the same thing.

    Beyond that, one of the distinct advantages of the various agile and related methodologies is the reduction in the scope of what is being delivered at any given point in the project, which means that whether you’re going for fully-tested, highly-architected code, or just getting the minimum viable product out the door as fast as possible, any failures tend to happen fast and get remedied fast. The danger, of course, is that a slap-dash approach may hit a wall later, when multiple iterations pile up together to make a horrible mess. And yet, as your examples of Twitter et. al. show, not only is it possible to survive such problems, it’s possible to thrive despite them.

  • Devin Rose

    I agree there is no one right way to develop software. One thing I’ve noticed with cowboy coders (which I’ve been myself at various times in the past): often they are successful because they can get the prototype out there and semi-working, get the buy-in for the product, but then it takes three to four other developers to come on and finish the features, fix the bugs, and make the product solid.

  • Andy Dent

    I don’t think there’s a spectrum.

    I think there are very different modes.

    One mode is the flow mode, in your head.

    The other mode is the process mode, which can exist largely outside of your head and substitutes for flow.

    Many people employ both modes, at different times, and this is partly where the idea of a spectrum comes from.

    Successful cowboys are very good at getting into flow mode and building the software model in their head.

    Agile approaches are almost antithetical to this – they rely on process but have a really optimised process. An agile process can also sit on top of people doing bursts of flow mode.

    One of the things that complicates programming discussions is that we often don’t factor in the vast differences between program complexity. I’ve worked on stuff ranging from CAD in C++ to lightweight business systems written in 4GL tools.

    Complexity is one of the other factors that makes us think of there being a spectrum.

    When I’m in flow mode I can’t even be verbal – I can grunt and say “hi” but have to say “shut up” to avoid thinking of any more complex sentence. (I hear that many writers are also like this.) It drives my wife insane when she comes home and gets this reaction. She can’t understand how I can be literally unable to speak, without “swapping out my brain” and losing what I’m doing.

    • jsonmez

      Good point. I agree.

  • David Rael

    This is a bold topic. I’m surprised there’s not more dogmatic response. It’s still early, maybe it’s coming. I think you pointed out the truth of why different paths can get you to success – like the human body, a software project is a complex system. It’s hard to know what to believe regarding optimal nutrition and training with so many voices saying so many conflicting things and with results and studies to back them up. It’s hard to know whether the time spent writing one and only one test and seeing it fail and getting it to pass and refactoring really pays off in the long run in every case. Things that seem like good ideas are often not. Your conception of what will result from any choice is only an estimate. And we all know how good humans are at estimation. Even after the fact, knowing the results depends on how you measure, which can have variation. Complexity doesn’t only live in the system under construction itself, but in the process as well. Thanks for a thought-provoking post.

    • jsonmez

      Yes. I was surprised to not see dogmatic responses either. I didn’t even delete any posts. :)

  • Pingback: Dew Drop – June 10, 2014 (#1794) | Morning Dew()

  • jbrinkman

    To me this discussion is like many in software development, and life in general – we all form opinions of the best approach based on our own myopic view of the world. We lambaste people who use waterfall methodology and yet you can point to many successful waterfall projects. That doesn’t mean that waterfall is the best methodology for everyone, just that for some dev teams, this approach is highly successful.

    I have taken a number of personality tests like the Briggs-Myers tests and the thing that always strikes me is how different each programmer is in terms of their results. We all know of studies that show different teaching methods have varying degrees of success for different students. Why should programming be any different? Different approaches may resonate better with an individual programmer and their personality and allow them to achieve their “best” result. Why do we as a programming community think that a creative process like programming will have only one way to accomplish superior results.

    In the end, programmers should be judged on their results (that also includes the cost of maintaining their applications), not on the methodology they followed to achieve their results.

  • mikellewellyn

    Great article there John and something to bear in mind in all aspects of life, as you say engineers and programmers in particular can tend towards dogmatism!

    Really enjoyed this, I am more naturally a cowboy coder but I have learnt to structure myself over the years (especially when running teams), and to minimise the risks (even then I have been guilty of late night production errors even this year! (But nothing I didn’t solve within hours ;))).

    Good thoughts here, and something I need to remember the next time I am disagreeing with my wife ;)

    • jsonmez

      Thanks Mike

  • SwinkelsPieter

    Not all cowboy coders are created equal and the same holds for software craftsmen. We should not compare top cowboy coders to not-so-top software craftsmen (and vice versa). Furthermore, I do not think there is an approach that works best in each and every situation. There are some many factor involved, such as the type of software, size of the team, maturity of the team, deadlines (although that is a slippery slope), you name it.

    • Pieter Swinkels

      By the way, I do not want to imply that you are a not-so-top software craftsman :)

      • jsonmez

        Don’t worry didn’t take it that way :)

    • David Rael

      This is a good point – comparison’s aren’t always what they seem.

  • Ronnie Mukherjee

    Good thought-provoking article. I’ve definitely trodden the cowboy coder path in the past, but have frequently not been satisfied with this approach. The common sense conclusion is to stay on your toes and stay flexible. Sometimes the cowboy approach is the best approach, and sometimes the more meticulous and professional approach is called for. Depends on the project and its immediate and long-temr requirements.