A few weeks ago I said that there’s more to creating software than just having a lone programmer. Much of creating a great software product is getting the right team together. In fact, O’Reilly just released a book on Beautiful Teams.

Beautiful teams can truly do amazing things.  There’s only one truly awesome team from the 80s stands out to me — The A-Team!

What can we learn from them?

Just like the A-Team, your software team should be varied with each person having a specific skillset that balances out the others. Here’s a cheat-sheet for the key players you need when building your team:

• The Madman (aka Murdock): Of course, you need the brilliant coder who can design the system and crank out the code. These are the folks who will rewrite half the code over a caffeine-infused weekend to have it just right. This person ideally works in emacs and thinks LISP and C (or some other obscure language) is still the best. Think Stahlman or Carmack.
• The Suit (aka Face): Next, you need the biz guy who can sell this crazy software to someone. Because as we all know it’s not the best software that wins. It’s the software that is best sold and marketed. It’s the software that gets traction with the masses, and you need your biz guy for that. Think Jobs or Ellison.
• The Leader (aka Hannibal): This is the guy who plans your software project. He may be the person funding it or the project manager. He sets the vision and makes sure the plan stays on track. He may even have a penchant for phrases like “I love it when a plan comes together”.  Think Fred Brooks or Joel Spolsky.
• The Enforcer (aka BA Baracus): Not all projects have these people but they help to make everything stay on track and “pity the fools” who take it off-track. Think David Cutler or Steve Ballmer.

The best software comes from the best people. So when you assemble your A-team not only should you be looking to fulfill roles, but you should keep the bar as high as possible.  Find craftsmen and people that really love what they do.

Because at the end of the day, software is simply all of the combined ideas of the team turned into code. So the better ideas you have going in, the better software you’ll get at the other end.

Back in the late nineties, I remember coding to a Lotus Notes API and how difficult it was to find good documentation.

I’d search through Lotus’ website in vain and while the internet existed there wasn’t really a lot of good information out there. It was still too new and the communities had not yet developed.

Also there was no good way to find the information even if it was there. I was stuck with having to dig through a stack of large 500 page technical books and hope that they had a good index.

Life got better when I switched to doing Microsoft programming. They always seemed to cater to developers. In fact, I seem to remember a certain CEO getting very excited about developers, developers, developers.

And nowadays, it’s crazy how easy it is to find information on programming. Last week I needed to a function to get the current week of the year. With a simple Google, I easily had it.

In fact, I don’t even install the API documentation locally anymore because it’s all on the web and it’s become easier for me to Google it than to hit F1.

Even when looking for details on new technologies, like Silverlight, there are dedicated blogs. I’m not sure exactly when we made this shift but it’s become such an important part of the way I work, I’m beginning to wonder how efficiently I could program without Google?

It makes me feel sorry for the corporate developers that have extremely locked down IT policies so if they hit something that has “blog” in the name they are immediately shut out of it.

I have to wonder how much money the company is losing when it doesn’t let a developer look up a simple function and instead forces them to dig through old help files or guess at how an API works…

Programming is seen as one of the last solitary professions. The best programmers just sit in a room and crank out code. Every now and then someone slides them a pizza and some mountain dew and that’s all the human interaction they need.

ALL they need is a power jack and a box to do their black magic!

But as alluring as that myth sounds, it’s just not true. While it is true that programmers need blocks of solid time to do their work, to make truly great software they need other people. They need QA guys to test it; they need designers to make it pretty; they need sales guys to make money off it.

Every now and then you get one person who has all those talents, but that’s definitely the exception to the rule. Most of the best software in history was created by great partnerships of a programmer and design/sales guy.

Some books go so far as to so that you need to actively fear the “programmer in a dark room”. The one that totally disconnects from the rest of the team is the one the PMs begin to worry about.

Rule #31 in the classic Dynamics of Software Development is “Beware of a guy in a room”:

Regardless of whether the cause is bogus or healthy, the results of allowing a guy to stay in a room are uniformly fatal to the professional development organization. Beware. Extricating your project from this trap is nearly impossible.

Programmer’s that are plugged into a community often become better programmers. They challenge each other to learn new technologies and build more efficient software.

When I look back on programming career, I find that I did my best programming when I worked with other great programmers. Like many activities, iron sharpens iron.

Recently, I’ve started plugging back into programming communities by getting involved in places like stackoverflow and following the .NET blogs.

Every group needs its tribe and programmers are no different.