Why Teams Create Better Software

A recent email asked for my advice: "Our 'team' has 9 developers. We're all doing our own separate projects. That seems bad to me. But my boss says it's more efficient. Is he right? If he's not, what can I tell him?" Hmmm...excellent question -- and in an area that I think the right decision can have a huge impact.

My response: First, let's examine the issue from your boss's POV. What's the situation look like to him? Luckily, using my patented MindMeld(tm) 600, I was able to get a snapshot into his thinking.

Ah, we recognize that guy: the Angry Boss, unconcerned about their employees. It's a stereotype we all get. But, MindMeld has an advanced feature called "Probe" -- a sort of drill-down on a train of thought. Using that got me this:

Ah, so it's not so much about being a jerk. He's not so much angry as he is scared. Maybe the best response isn't opposing him so much as empathizing with him. On the face of it, it looks like his math makes sense.

One of my favorite quotes is by the American curmudgeon, H.L. Mencken: For every complex problem there is an answer that is clear, simple... and wrong. I think in this case, your boss has fallen into this trap. While costs must be controlled, a strategy of "get the job done as cheaply as possible" may work in manufacturing widgets; it most certainly does not when developing software.

Most of us, when given nothing else to consider, focus on price -- or in your boss's situation, cost. It makes sense: given A and B, and knowing nothing more about them, we'd opt for the cheaper. But there is something far more important to focus on -- insanely great software.

Apple is the current darling of the business world, where it can seemingly do no wrong. Your boss has most likely read articles in business magazines extolling the way Apple produces products. Because of the desirability of the company's high-quality products, Apple is able to charge premium prices. A recent Fortune article revealed that Apple sold 17 million iPhones during the first half of 2010, out of a total 400 million sold (4.75%), but garnered fully 39% of industry profits during that time period. In contrast, top manufacturers, Nokia, Samsung, and LG, combined for 32%. Quality, it seems, pays.

But you're not creating iPods, iPhones, and iPads. And besides, Apple has Steve Jobs while you have...your boss.

OK, how about 37Signals? They produce software. Yes, it's a product, but for a long time, they wrote contract code for projects as well. But they have Jason Fried and David Heinemeier Hansson (who created Ruby on Rails so that they could write better code). Sure -- but before Steve Jobs was Steve Jobs (or Jason, Jason or David, DHH), they were obsessed with quality. And that's the point of connection between you and them.

So, how do teams create better software than individuals?

Great software requires a high level of execution on multiple fronts: design, architecture, persistence, etc. A wonderful Latin translation of an aphorism by the ancient Greek physician, Hippocrates, goes like this: Ars longa, vita brevis. My less than wonderful English translation is this: Art is long; life is short.

The fact is that when developers are asked to do everything, nothing they do will be insanely great. There's just too much to learn for one person to master everything: mediocrity ensues. But let's take a fictional team made up of Anne, Bob, Charlotte, David, and Ellen. We can break this cycle of mediocrity by letting them excel at something.

So we ask them what their interests are -- and we channel and nourish that interest so that it benefits the team. Perhaps Anne loves architecture while David loves databases. One thing is sure: empowering David to become a true expert at databases -- especially our database -- is going to have a tremendously positive effect on the work that the team produces -- provided, of course, that David guides all database development across all projects. The same holds for all areas.

Former president John Kennedy once defined happiness as "the full use of your powers along lines of excellence". No good developer likes to be mediocre; they get stuck there because the system they're part of places them in that situation. Allowing David to become great -- insanely great -- is far more likely to make him happy than asking him to wear multiple hats, none of which quite fit him.

Good point. Sometimes, two heads are better than one. I have three responses to this.

First, when developers feel secure that they have expert knowledge on a subject, they're actually more willing to seek others out for their feedback.

Second, cross-training -- something I'm a big fan of -- can be done through things like "learning lunches", in which team members prepare a short presentation and give it over a lunch that the company pays for.

If your boss has a problem with paying for lunch, you might point out to him that during that lunch hour, he has effectively "hired" a developer for one hour at -- what -- $10? Sounds like a pretty good deal.

Third, when a team -- a real team, not just a collection of individuals -- pair-programs, knowledge transfer is rapid and real.

Hopefully, that will provide your boss with new information, with which he can make a new decision.

Let me know how it turns out!