Comments on: There is More Than One Path to Success

By: David Rael

David Rael — Fri, 20 Jun 2014 12:11:00 +0000

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

By: Ronnie Mukherjee

Ronnie Mukherjee — Tue, 17 Jun 2014 14:54:00 +0000

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.

By: jsonmez

jsonmez — Thu, 12 Jun 2014 13:59:00 +0000

In reply to Pieter Swinkels. Don't worry didn't take it that way :)

By: Pieter Swinkels

Pieter Swinkels — Wed, 11 Jun 2014 08:51:00 +0000

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

By: jsonmez

jsonmez — Wed, 11 Jun 2014 02:15:00 +0000

In reply to David Rael. Yes. I was surprised to not see dogmatic responses either. I didn't even delete any posts. :)

By: jsonmez

jsonmez — Wed, 11 Jun 2014 02:14:00 +0000

In reply to mikellewellyn. Thanks Mike

By: SwinkelsPieter

SwinkelsPieter — Tue, 10 Jun 2014 21:35:00 +0000

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.

By: mikellewellyn

mikellewellyn — Tue, 10 Jun 2014 15:14:00 +0000

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 😉

By: jbrinkman

jbrinkman — Tue, 10 Jun 2014 14:22:00 +0000

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.

By: David Rael

David Rael — Tue, 10 Jun 2014 10:28:00 +0000

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.