JMCQUARRIE.co.uk

James McQuarrie is a London (UK) based User Experience Consultant who designs and helps build digital products & services that delight their users.

Why growing your development team lowers their productivity

Writing code and building software is one of the most complex undertakings that a group of people can start.

The complexity stems from one simple fact; there is no right or wrong way of writing code. Let me qualify that slightly; as long as the product works there is no right or wrong way of coding it. There are more efficient and less efficient ways of writing your code. There are even preferred, industry standards and coding patterns in some areas of development, but there is no one globally approved 10 step process for coding.

This simple fact makes the world of software development one of the most exciting to work and partake in. No two days are the same in this field, and people are constantly reevaluating, reworking and improving the best ways of producing software. This fact also means that getting a group of developers together and getting them to work on the same project is a nightmare.

The more people you bring together, the worse this nightmare gets.

If you have a single developer working on a system they will be very productive. They can design and write their own code, in what ever language they fancy, and as long as the end result works it doesn’t really matter how they do it, which conventions they do or don’t follow or which design patterns they have used.

Now take this same developer and add a second to form a development team. Before these two developers can begin to design and cut their code they need to agree on their approach. They need to pick a coding language, a methodology that they will follow and a series of coding conventions that they can agree to. Once coding they need to constantly think not only about their own code, but also about how it will integrate with the code that their team mate is writing too. You’ve now got two developers who are each less productive than they would be working on their own. Let’s, for arguments sake, say they are now each working at 70% of their potential productivity.

If one developer working on their own is represented by 100 work units, two together do not add up to 200 work units, they add up to 140 work units.

Now add a third developer to the team and across the board they are each less productive again as they now have to spend even more time agreeing to how they will write their code and integrating with each others work. Again, for argument’s sake, let’s say each developer is now only 60% as productive as they could be on their own. You now have a team that is producing 180 work units, less than you may have thought you’d get from a team of two.

Yes, I am simplifying things quite a bit. Yes, as a team gel and work together more and more they will improve their overall productivity, and yes once you start building bigger teams than three even with this model you’ll get more for your money. But, and this is a big but, the point is that adding another developer into the mix in the middle of a project will not have the immediate productivity impact that some folk may imagine it would and to the uninitiated that can some as quite a shock.