Chocolate or Vanilla? That's the question I posed to 24 kindergartens last week as I passed out holiday cupcakes to my sons class. For the record; 14 chocolates, 10 vanillas. Now a statistician would tell you with much bravado that clearly chocolate is superior to vanilla by a commanding 16.7%. A chocolate connoisseur might latch on to that statistician's conclusions and add a few choice words such as rich, delicious, moist, or dark to his commentary and be very convincing to the unbiased observer. But the real truth is that the correct answer to this question is purely a function of the person. Some folks just like chocolate more. No further analysis required. The question that I pose is this. Can we say the same for development platforms?

What would be the results if I asked 24 software developers, at random, whether they prefer .Net or Java. Clearly this question must be more than just a matter of choice. Clearly there must be some level of superiority here. Be it in inherent capabilities, tools, or hardware. Based on all the "statistics" I have seen over the years, I would guess that the answer to my question would yield a near even count for both platforms. Could it be that the choice of development platform for a new software project be as arbitrary to its success as choosing a chocolate cupcake over vanilla? Don't bet the farm.

Barring any technical prerequisites that would preclude one or the other (yes, they do exist), I stand by my prediction of results. Why is it then that about half of the professional development world writes in Java and the other half .Net? I think it's because both platforms are viable for most software solutions. The differentiator, just like the cupcakes, is in the people. The investment it takes to become really good in a particular development platform is great. And with technology, personal bias is all about knowledge of a given platform, or lack of knowledge of the alternatives. And when you look at a developer's career, they are never more eager to sponge up technology details than in the beginning. So it is with very few exceptions that a developer doesn't answer my question based on their developer roots. What platform were their first projects on? In a previous life, I worked a little in industrial automation and that world has their technology players as well. Multiple vendor platforms with specific strengths and weaknesses, but overall pretty equal. Engineers in that world have their preferences too. Modicon, Allen Bradley, Siemens. Their personal preference can almost always be mapped back to their first project.

For the record, I am a .Net guy. I am a .Net guy because I "grew up" using Microsoft development tools. C++, VB 4-5-6, Asp, Interdev, VS200x. Yes I have also written java code, but very little. Could I architect a good Java solution? I know I could. I know I could because I am a good developer. Classes are classes, patterns are patterns, and languages are just syntax, blah blah blah. Besides, I love the curly brace {J}. But I also know that I could build a far superior .Net solution in less time. And it not because I think .Net is far superior to Java. With .Net, I can just do. With Java, I'll know what I want to do, and then have to look up how to do it.

So what difference does all this make? Make your platform decisions based on your people, or your people decisions based on your platform and your software projects stand a much greater chance of being successful. And if this stumps you, find a 5 year old and offer him a cupcake to explain it.

Brian

Developers, Developers, Developers!

I wonder if Microsoft developers ever feel underappreciated. Having never worked there I can't say first hand, but judging from the antics of their chief exec, I'd bet not. Not every exec responsible for software endeavors share Mr. Ballmer's enthusiasm for our kind. If you bounce around long enough in this field, you will inevitably get a taste of both the yin and the yang of executive flavor for which I refer. In my case, the past employers that fall into the opposite spectrum of Mr. Ballmer are in that camp simply because they didn't know any better. Software, or should I say, the importance of software has a way of sneaking up on an exec. One day its pencils, ten keys, and typewriters, and then BAM! - You're in a meeting to negotiate this year's accounting system license agreement. Well, maybe I am exaggerating a bit, but for non-tech leaders, this creep happened, and some adapted better than others. And it's sometimes hard to fault them for their attitude towards developers. In the early days where their opinions were formed; it was all about their experiences. If their teams were good, and they successfully implemented software based systems that actually worked without first failing over and over, the bosses get the impression that it's easy and anyone should be able to do it. On the other hand, if their teams were lousy, and repeatedly failed, well, those developers are certainly not worthy of any kudos either. And then there is the yang for the yin. The exec that has presided over this technology creep with foresight. The creep was there for him too, but he creeped with intent. This exec recognized the competitive advantages that his software systems could achieve his company. This exec recognized the need to ensure that his development teams were better than his competitors and that this competitive advantage could significantly affect the organization's success. This guy is real and he's in Ballmer's camp.

For leaders who have "grown up" so-to-speak within the software process, their opinions are based on other factors, because their experiences were different. They understand far better than their non technical counterparts the great challenges (and great enthusiasms) of the software creation process. They understand developers, and understand that not all developers are created equal. They understand that while great coding might arguably be considered an individual endeavor, great software is definitely a team sport. The successful leaders in this group are also in Ballmer's camp.

In software, a good team of developers stand a chance of overcoming methodology weaknesses, dysfunctional project managers, and impossible schedules and yet still pull off miraculous success. But the best of everything else with bad developers… there's gonna be a big thud when the gantt hits the windshield.

So embrace your developers. Give em' a hug. Hell, stand center stage and at the top of your voice yell! Developers, Developers, Developer!

Brian

So the doorbell rings and I answer it. On the other side of the door is the Ice Cream guy. That's all that Schwans sells right? So I tell him before he says a word that I am not interested in buying any Ice Cream. "But wait" he says, while moving to stop the door from closing with his foot. "We sell more than just Ice Cream. Do you like pizza?" Well… yeah I like pizza, and so the discussion gets a new life. He then hands me his product catalog and lo and behold, they sell lots of things I like. So I start flipping through the pages and rattle off a few items. While I am doing this, he whips out his hand held device and starts punching 3 digit codes that correspond to the items I'm mentioning. When I finish, he goes out to his truck, brings back my items, and asks me how I'd like to pay. I say credit card, half expecting him to tell me that he can't take a credit card, I mean… he's at my front door for Pete's sake. "No problem" he says. I hand him my card and on the side of that same hand held device he slides my card through. And out from the very small wireless receipt printer strapped to his leg appears my receipt. I didn't even notice that printer at first, and I am usually pretty observant of electronic devices. He hands me my receipt and says his goodbyes. I close the door, and I am happy. And it's not because of all the good food I just bought that requires little to no cooking. That makes my wife happy. No, I am in la la land thinking about just how much fun it must have been to create the software application on that hand held. 3 digit codes, wireless printers, credit cards. Fun!

Yep, it happens to me all the time. I see software applications and I start wondering what it would have been like to create it, and how I might have done things better. This is because to me, few things are more fun than making software. Sure there are steps in the software process that are decidedly "funner" than others, but all in all, it's a blast, from specs to release. Fortunately I have been able to build lots of software through the years. The first time I got to write code that people actually used, I remember thinking, I can't believe I am actually getting paid to do this. For full disclosure, I wasn't paid much, but back then I probably would have worked for free if my boss had told me he couldn't afford to pay me.

I don't know how I would have ended up spending my days (and nights) had the solid state transistor never been invented, or had I been born 100 years earlier, but as a result of the advent of the modern computer and its solid entrenchment into all walks of business and commerce, I get to build great software for a living. So whenever the sun sets on my career and I take up the rocking chair, there is a very good chance that I too will get to udder the famous words of Thomas Edison.

"I never worked a day in my life. It was all fun".

And if the Schwan's guy ever shows up at your place, forget the pizza and go directly for the Black Jack Cherry Ice Cream. Product # 362.

Brian