Saturday 10 May 2014

Development Team Size

DISCLAIMER: I am writing about team, that starts a project. Not about support team or a team which has to add pieces of functionality to existing application.

Narrative

Recently we started two new small[had to be] applications in the bank, that are small transformer/bridge, and aggregator(integrity controller by function).

We started with aggregator - two of us. We did a proof of concept and working app with most of functionality fairly quickly. Pairing most of the time, quickly discussing problems. If we had different vision - we could quickly find a consensus (usually with well-known phrase "let's quickly spike and then change if we don't like";)

Than the priorities has changed (surprise-surprise), and we started transformer. With one small difference: now there was a big team (9 expierenced developers, including us). All but myself were working in one team on the other project before, so people knew and respected each other.

But something in our cooperation was broken from the very beginning. We usually make team decisions about any new library, technology, the way to organize process and structure the codebase. So we have a discussion about any topic like one of those and at the end we are voting/deciding on the way.

Sounds great in theory. Turned into disaster in practice.

So many senior developers on a small (at the beginning) codebase - means everyone has his own ideas how to do things. And this is a start of new application - so everyone saw that as an ideal opportunity to apply his ideas and practices from the empty page.
Was hard to agree at the beginning on anything.

Some team members were very upset when their point of view didn't get enough supporters in voting.

Some people where rewriting bits using their approach, and then others were refactoring the same place back because they saw that as an issue.

We came back to the same discussions again and again. Too many opinionated people, not enough codebase size to make everyone work on his own feature.

Theory: small green-field application - what could be better for developers?
Result: slow delivery; team not happy.

Conclusion


Someone would argue: the situation turned to worse because there was no single authority/architect/team-lead, who would drive decisions.
Maybe. But this will not make people happy, it will make them to obey but they will keep their creativity unrealised.

I think the ideal solution here would be to start application with 2 developers - smallest possible team. And once the skeleton and main features would be ready - add more people for bug-fixing and to plug in new features.
This approach will give first 2 devs ability to build the prototype and to evolve design quickly, without spending too much time for holy-wars and discussions.
This will reduce project budget and the freedom to throw away the code if initial assumptions were wrong or business has changed it's mind.
It is much easier to find 2 developers, that will have more or less similar ideas and approach. It is much harder to find 5-7 with the same mindset.
This 2 devs can pair on idea, than split to quickly implement different parts, then pair again on next piece of functionality, and so on.
They can (and should) seat next to each other, in order to be able to quickly gather near one monitor for a discussion and to split again.

Why not 1? Illness, personal matters, vacations and so on of the single developer should not stop the project - 2 can always go for a rest one after another.

Why not 3? If there is any problem that has few options for solution - usually voting in this case will decide the way. Than usually it would be 2 against 1 and that one will be not happy. In case of team of 2 - they know there is no way to vote, so they have to learn to find consesus using facts and arguments. Once they will learn each other - they will make decisions very quickly. Its always easier in case of 2, because there is no way to split into groups with different opinion, and there is no way to escape.

4 and more... Well, the same issues as for case of 3.

I really hope the managers will find out at one point that more people doesn't always mean faster delivery.
And too many smart people on the same task can result in problem.