This is a guest post by Russell Ball. Russell is a senior .NET developer and the evil genius behind the blog – Caffeinated Coder.

I recently watched another excellent segment on Ted.com entitled “The Paradox of Choice” in which Barry Schwartz challenges the popular notion that having more choice is always a good thing.

Barry points out how the number of absurdly trivial choices we are forced to make on a daily basis has grown exponentially in recent times. Rather than increasing our satisfaction, he argues that this trend actually detracts from our quality of life by leading to paralysis, distraction, and dissatisfaction stemming from lost opportunity costs and unmet expectations.

At one point he cites a study done on investments in voluntary retirement plans which showed that participation in the program dropped by 2% for every 10 mutual funds that the employer offered. The increased complexity and effort required to make a decision in cases where employers offered too many fund choices seems to have paralyzed many participants, thus causing them to miss out on thousands of dollars of employer matched funds.

This line of thought led me to think about Jeremy Miller’s recent post, Breaking News: Java trounces .Net in OSS activity. In this post, Jeremy laments the relative lack of Open Source activity and framework alternatives in the .NET space as compared to the Java space. The underlying assumption in this position is that a high number of options is a desirable metric and that .NET developers should strive to create as many if not more alternatives than currently exist in the Java space.

Although I am of the opinion that we currently suffer from too few alternatives in the .NET world due to the domination of a single vendor, I am not convinced that we should strive to outdo the Java world in terms of the number of alternatives we have available to us.

I remember listening to an old interview with Don Box, Ted Neward, and Mark Pollack in which they discussed the differences of the Java and .NET worlds in terms of values and culture. One difference they talked about was the overwhelming number of choices available to Java developers and how choosing the development landscape at the beginning of a project could be a time consuming endeavor, especially if the team consists of several strong willed developers with different preferences.

I can’t help but wonder if this dynamic is less than optimal from the business perspective in terms of lost time and productivity. I also question whether I would really want to spend my own time learning the relatively trivial nuances of dozens of a particular type of tool or framework in order to make an informed decision when it comes at the expense of diversifying my skills in a wider range of other areas and technologies.

At the end of his talk, Barry emphasizes that excessive choice is definitely only a problem of affluent societies and that there are plenty of places in the world that suffer as a result of too few choices. He muses that what is really needed is a redistribution of choices in order to improve everyone’s lives.

Perhaps the same analogy holds true in the world of software.

The trick is to figure out whether either Java or .NET are currently in the sweet spot when it comes to the number of choices they offer. Do they both currently represent unhealthy extremes? Will both camps remain at these extremes due to their origins?

Out of necessity, it is common for software teams to have its members silo themselves into specializations. One person maybe, the “reports” guy, while another maybe the “database” guru. Allowing members to specialize can be dangerous for a number of reasons.

1. Presents the “Hit By Bus” Test

If you haven’t heard of the bus test it’s pretty easy:

If person X was hit by a bus today how well would your team survive?

I have seen teams fail this simple test time and time again. As a need for survival, either individuals choose (or are assigned) to work in very niche partitions of a project or in a legacy code base. The result leads to a knowledge bottleneck which can present dangerous situations to a business.

No lie – I met a person who self-obfuscated all of his variable names to undecipherable “a1”, “b2”, and “zzz”. He kept a secret print-out map such that only he knew the real variable names. He said it was for “job protection”. He left the company on his own freewill, taking the cheat sheet with him, rendering the code base worthless and costing the company hundreds of thousands of dollars to replace.

2. Creates Tunnel Vision

When people specialize they tend to get tunnel visioned into their niche. No longer does the generality of development interest them, but only their one specific technology. As the saying goes,

If all you have is a hammer, everything looks like a nail. – Bernard Baruch

Wanna hear about another guy I have met? Of course you do…

Once upon a time, I knew this other guy who only knew Lotus Notes and XML. He spent all his time and energy learning every single aspect of both technologies, but not an ounce of energy towards different solutions such as Java, .NET, or Python. The result? Every single project he was given resulted in leveraging Notes and XML. Guess what happened next? Yep, he left his company too…thankfully he took his code with him…

3. Yields Lack of Community

Developers by nature tend to stay in their shells, and if given a reason will do so even more. As a result, having office gurus does not lend itself to a sense of community or team. Since each is an individual with no technical peers a dog-eat-dog environment starts to build.

So what is the antidote to the office guru? A healthy blend of:

• Knowledge Sharing
• Open Minds
• Code Reviews

Recognize office gurus for what they are – liabilities. Take advantage of the situation and learn from their craft as well, not only will you extinguish any knowledge bottlenecks, but you will also become more valuable to the company than the office guru.