I sometimes watch developers with 20 windows open at the same time trying to find their web browser, which takes them around 15 seconds and then they have 34 tabs open in FireFox and they click back and forth randomly to at some point find the page they are looking for. Then they forgot what they actually planned to do, so they switch back to wherever they came from to copy some chunk of text and they navigate back to that window… – quicker this time as the tab in the browser has already focus.

It’s the multitasking problem. The more you multitask, the more it will slow you down. But not only the number of different tasks for different projects can decrease productivity, also the number of team members.

“Adding manpower to a late software project makes it later.” Also known as the Brooks’s Law.

The concept is that for each team member you add to a project the intercommunication effort increases by n(n-1)/2 as shown below.

images
Figure 1

So let’s say we have 6 members in our team, this would mean that all of them have to communicate with each other in order to complete the project; assuming they have to know what each other is doing.

This would create 15 communication channels or communication paths as shown in Figure 1.

If we then assume 20% of the actual time required to complete the project as the communication effort per communication channel we will figure out that the more man power we add to the project the more time we require. As shown in the table below, theoretically 10 people take as long as one team member by himself.

Members Time Required in Days n(n-1)/2 Communication Effort Actual Time
1 20.00 0 20% 20.00
2 10.00 1 20% 12.00
3 6.67 3 20% 10.67
4 5.00 6 20% 11.00
5 4.00 10 20% 12.00
6 3.33 15 20% 13.33
7 2.86 21 20% 14.86
8 2.50 28 20% 16.50
9 2.22 36 20% 18.22
10 2.00 45 20% 20.00

In our example we are most productive when we are working in a team with three members. This observation does not only apply for software development, but for any creative team effort. (I even experienced this with our school band – we never wrote a song until we limited participants to 3 members only ;)

Examples are projects that are completed by a single person. Projects that would usually require a big team of developers. The guy who started http://pixlr.com/ has built most of the application by himself within just a year of his spare time.

Our most successful tools and products are those that where developed by a single person either as a requirement or a proactive solution. It’s like a prototype that becomes a real product. Usually we noticed that progress slowed down drastically once a team took over the development. Taking the conclusion that it would make sense to have just one person working on a project for its life cycle is not a good idea though. At some point we need to think about support, maintenance and other tasks that require a team setup.

I call it the Rock Star setup – let him do the show and let the band take care of the music. Never forget they can’t play a show without each other.