Software Development Team Composition
A software development team (SDT) collaborates to build software applications by splitting the workload into manageable tasks and spreading the work between team members. SDTs, are usually the largest financial cost within an IT department or software company. Though total costs of running an STD varies, productivity is not positively related to its cost. This article presents a philosophy for achieving the best ROI from a SDT.
The quality and the corresponding cost of any one software developer can be, by large, separated to three categories; junior, intermediate and senior. Classifications of C, B and A are often used to define skill level.
When building an SDT, a manager must choose a combination of A’s, B’s and C’s to meet his/her development goals. In the case when money is not an issue, deadlines are tight and the work is highly complex, a team made up of only A’s would more than likely be the best choice. If there is no rush for time but the budget is slim and the work is routine a C’s dominated team with a few B’s would work better. This article proposes a combination of A’s, B’s and C’s that results in quality code development that is designed to keep costs in line. Most SDT’s face some time constraints, are accountable to meet a budget and have work that is somewhat complex. As constrains change, the team combination would have to be changed and adjusted to meet the development goals.
Some of the more simple views which have gained popularity in the industry say that an all A’s team is the only way to go 7-simple-rules-for-hiring-great-developers. To some extent simplistic ideologies have been steering the industry with statements like: “A will hire A, because they want to work with the best. B will hire C so that they'll look better by comparison” or "If your first 10 employees are B, you will end up with 100 C.” These statements are not a leveraging tool which SDT managers can use to build and adjust their team, instead they are scare tactics that have gained a larger following than a more balanced approach.
Rather than building a costly team made up of only the best, the leading parameter which should dictate team composition is the complexity of the work. For the average software project the bulk of the work could be handled quite well by a B (or intermediate) level developer. The more complex work (design patterns, architecture changes, frameworks research) constitute a smaller portion of time but would definitely require an A (or Senior) level developer. To make the best use of your development budget, you should keep in mind that every development project has some very simple yet time consuming work which could be done be a C (or Junior), such as; code clean up, commenting, adding disclaimers, building unit test and small GUI alignments.
The simple statement of this article is; don’t waste money having an “A” developer cleaning a 5th generation CSS file in order to make a 2 pixels alignment.
For the average software project the best return on investment form a team should be somewhere in the vicinity of:
2 A : 3 B : 1 C
This ratio is driven from the work itself and the minimum cost needed given the nature of the work, internal dependencies between complex medium and simple work and the time each type of work requires. The proportion should be refined and adjusted over time for changing needs.