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.