opinion

If a service doesn’t have a way for me to support it directly, and isn’t depending on my support, I’m going to be very wary of depending on it. -- From "2011 The Year the Free Ride Died" on ReadWriteCloud

Note: This blog post was originally written on October 20th, 2009 - but due its continued relevancy, my fight against the term "cloud", and sheer lack of creativity to think of any other topic to blog about, I'm going to repost it here for all to enjoy. And enjoy you shall.

I wake up at 5:30 AM to lift weights and run. That's my own personal sanctuary from what is now my work day. My work day consists presently of helping a company manage applications and data "on the cloud". I do not think about "the cloud" while I'm working out... typically.

Late last week while doing cardio, I start listening to one of my subscribed podcasts as I always do when engaging in such a miserable activity for the benefit of my heart. The podcast of choice on that morning was TWiT. This particular episode came directly on the heels of the big Sidekick data loss fiasco - which just happened to be the loss of a ton of customer data such as address books, text messages, and other fun bits of personal data that was stored... guess where? That's right - "on the cloud". The TWiT crowd on that particular episode had a fun time with that term for the opening ten minutes this story was talked about. Thankfully neither Dvorak or Laporte were actually there, or else it may have just been intolerable. Regardless, they had a fun time talking about how "the cloud" failed.

Actually, no - that data was stored somewhere in the bowels of Danger's and/or Microsoft's infrastructure. Their infrastructure, and their policies/procedures around it are what failed. "The cloud" didn't fail anyone here.

Why? Because there is no cloud.

I read a column on jaguars.com by their media guy, Vic Ketchman, who does a rather entertaining and witty Q&A with the fans. One of the more frequently occuring topics is that of what makes a team more successful - having better players or better strategies. Vic's canned answer for this always includes "it is players, not plays" that win the game.

I agree with Vic. For example, the West Coast offense is fine and dandy, but you need a QB intelligent enough to orchestrate it and receivers who are tough enough to run routes over the middle yet still athletic enough to get yards after the catch. If Pittsburgh's defenses from the last 15 years were so successful, why didn't everyone who copied the blitzing and zone-blitzing scheme out of a 3-4 have as good of a defense? Because the Steelers always had great personnel to run that defense.

So what in the hell does this have to do with software development? Just substitute some words around.

for fap in ["Languages","Platforms","IDEs or Editors","Methodology"]:
	print "It is engineers, not " + fap + "."

The constant jabbering and grandstanding I see loudmouthed developers, evangelists, and vendors make is that adopting $x is the key to being successful. I have heard that claim made regarding ESBs, software methodologies, unit testing that demanded 100% coverage, IDEs and so on. Unfortunately, no one has yet to invent a tool or process whereby you can stick a group of mediocre typists who can write hello world in a room, have them click a few buttons, and out comes a working software system. If that were true, then being a software engineering truly would become the equivalent of being a McDonalds floor employee of our age.

It is all about talent. Markus Karg said it best in this near diatribe he posted to java.net:

Go back to the roots! First, you have to reduce product development to a few core people, located in a first world country. That [sic] people have to be experts. They have to be well paid (the major reason why lots of Sun people quit with Oracle was about reduced income, BTW). Those people have to have enough time and equipment and silence. Don't bother them with revenue, release dates, and so on. Just wait until the software is done. No need for thousands of engineers in India. No need for "taming the masses" things like XP, Scrum and Kanban. Just let them sit in a quiet chamber and wait and do not disturb.

Smart, talented, and motivated engineers, sitting in a room with a singular focus is what any software project needs. The tools become irrelevant, though they'll be best chosen to meet the personalities and preferences of the engineers The point is that the tools are chosen to match the talent - much like football plays and strategies are chosen to match the personnel. In both football and software engineering, if you have to adopt tools or techniques to make up for your lack of talent, then you've lost before you started the game.

I'm a huge David Fincher fan, and after yesterday my infatuation with his movies still continues. Let's just say The Social Network profoundly reinforced some of my core beliefs while at the same time being my type of movie - dark and complex.