With apologies to the movie A Few Good Men, 1992, directed by Rob Reiner.
The right team size for software development.
How many people does it take to develop a Software Product? How big a team will I need to create to tools for my business? I need to migrate this legacy software to a new platform, how many programmers will I need?
These are common questions asked of CTO’s, IT Consultants, startups, techies and, of course, me. Depending on who you ask, you’ll get a different answer. Here’s mine, and why.
Build a small team of smart people, point them in the direction you want and let them loose. They will deliver beyond your expectations.
Lets compare three team sizes, the one man band, the massive outsourced team and A Few Good Men.
One Man Band a.k.a. Jackaroo
Definition: Jackaroo - Jack of all Trades, Master of None.
The Jackaroo is a single developer who does it all. A lot of Indie Developers, like myself, seem to be Jackaroos, but not all of us are. A lot of contract programmers are.
The Jackaroo does it all, they design the software, write it, test it, and deploy it. Great Jackaroos produce great products. But they are rare. Good Jackaroos often focus tightly on a market segment or technology and successful Jackaroos will have special expertise in your business area.
Jackaroos are cheap (there is only one person to pay), fast and focussed. Jackaroos are flexible, jumping from component to component, from programming to support to design like trapeze artists. They provide personal service, which is rare in this day and age, and are measured by their individual professionalism, track record and product history.
For small, quick, simple software, the Jackaroo excels.
But…
A Jackaroo cannot be great at everything involved in software development. Their development style, programming patterns and architecture may not be conducive to later maintenance and modification. They may program well, but do artwork badly. They may not be the best managers of time, or the best communicators.
And since a Jackaroo cannot have expertise in all areas, they will struggle in areas they are not good in, take more time because of it and deliver lower quality results. Over and above the limits of a Jackaroo’s expertise, a Jackaroo is limited to the number of hours in a day they can work for you, often drawing out the project timeline.
And if anything happens to the Jackaroo, you may be in trouble.
If the project is larger than a few function points, not simple, has more than one component (e.g. server plus client plus API), the average Jackaroo will not have all the skills, time or ability to deliver.
The Large Team a.k.a. the Army
When a project is large, complex, has many stakeholders, departments, components and seems daunting, the Army seems the way to go.
An Army has heap of resources available, specialists in any and every area are available at the Army’s fingertips. Need a web team, they have it, need an API team, that too, add an iPhone component, the Army has people who can do that too. If there is one thing an Army never runs out of, its resources.
And for every specialist developing code, there’s another to test it, another to document it, another to integrate it and another to review it. Armies produce large, complex software products that do work, usually.
But at a cost.
Armies need leaders, we call them Project Managers. Armies need scouts to tell the army what to do, we call them Business Analysts. Armies need standards, we call them Programme Managers. Armies need logistics, we call them assistants. The true cost of an Army is not in the number of people (a Jackaroo costs the same as half a dozen outsourced programmers), but in the number of interactions between them. The managers, analysts, assistants, programmers and client have to meet a lot to ensure all parties understand the needs, progress and issues of the project. The Army needs lots of internal meetings to ensure the analysts deliver a consistent message to the programmers, the analysts and programmers have to meet constantly to see that the required software is being built. The testers have to meet the analysts to know what to test for and meet the programmers to point out where the tests fail. The number one reason large projects fail is that the communications network gets just too complex and political.
Besides the time these meetings take up, communications breakdowns cause havoc in Armies. Small misunderstandings between teams can lead to large integration issues, incorrect modules being developed, components failing to complete. Even worse, communications breakdowns between client and manager, client and analyst, analyst and manager regularly lead large projects astray.
To make Armies more cost effective, most use outsourced, offshore programmer teams. These programmers never meet the client, never see the big picture, never understand the design, they just cut code. The result is a lot of code duplication, differing standards, and no-one takes responsibility for issues, performance or quality. And since these programers are not ‘in the loop’, they take their time.
Armies are not agile. Needs change, projects change, software changes and Armies take time to adjust. If the client is not 100% clear that the software required will remain static for the time it takes to write, the Army will be cumbersome.
The Army costs a fortune, even with cheap programmers and reasonable management. The Army produces workable software that may or may not be any good, but it takes time, a lot of time, and is hard to keep consistent.
Army examples: Microsoft has the largest Army out there, as does IBM, Oracle and SAP.
A Few Good Men a.k.a. Seals
A Seal team in the military is a small team of experts who have had extra training and specialization; work together well and take on the toughest assignments, assignments a single spy or large team cannot accomplish.
If software, a Seal team consists of a small team of professional designers and programmers who take on the toughest assignments. Seal team programmers are seasoned programmers, experts in composing great software and just plain smart people. Seal team designers understand art, architecture, interaction, and your software needs better than you do. Seal teams live and breathe producing awesome software products.
Seal teams can take on large complex projects by simply breaking them down into manageable chunks and getting to it. They have been there before and know what to do. Seal teams produce well designed, well coded, integrated software. There are few meetings (low communications overhead) because the entire team is involved. They are agile, if the needs change or an issue arises, they all get on it, quickly, silently, efficiently. They work in parallel. They work like a family. And they get it done!
But Seal teams are rare.
Finding Seal team members is hard, very hard, but not impossible. There are lots of potential Seals out there who have not been given the chance. I know, I have been hiring Seal programmers for 10 years. I choose people who are smart, passionate, flexible and those I get on well with. They may not have the experience or expertise I need, but a smart, motivated individual can pick up skills insanely quickly. But 19 out of 20 programmers I do interview for work are better suited to Army work.
Seal teams are hard to deal with. They are professionals, and unlike some Jackaroos and all Armies, they are just as passionate about your product as you are. Which means they are going to contribute to the discussion, offer unsolicited advice, point the project in new directions and in many cases, take charge. A lot of clients are not used to this and struggle hand over software design and control into the capable hands of a Seal team.
And Seal teams do not come cheap. Experience, quality and expertise take time to build up in people. And these people are in demand. You will pay a Seal team so much more per person that either the Jackaroo or the Army.
Seal team examples: Google never has more than seven people on a product team. And, the most popular software today was started in Seal teams, for example Bricklin and Frankston created spreadsheets, Andreeson and Bina made web browsers, Thompson, Ritchie, Kernighan, McIlroy and Ossana made UNIX!
So, how many do I need?
You need a small team of exceptional people. Get them and the higher cost per person will be tremendously offset by the quality of the software, speed of development, ease of process and communication, flexibility in design and awesomeness of product.
Footnote: A good indie developer, like Noverse, seems to be a Jackaroo, but we’re not. I may be the lead, but I am surrounded by other brilliant programmers, professional designers and business experts, people who complement my skills, whose strengths are my weaknesses. A Noverse Seal team will form for your project, and re-form for the next.