Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If I work alone, I used to be superproductive, if I want to be. Running prototypes within a day, something that you can deploy and use within a few days. Not perfect, but good enough. I also had this experience a few times when working directly with someone else. Everybody could do the whole thing, but it was more fun not to do it alone and also quicker. The right two people can take an admittedly not too large project onto new levels.

Now at work we have a seven person team and I do not feel nearly as productive. Not even nearly. Certain stuff needs to be checked against something else, which then needs to also take care of some new requirement, which just came in three days ago. All sorts of stuff, mostly important, but often just a technical debt from long ago or misconception or different vocabulary for the same thing or sometimes just a not too technically thought out great idea from someone who wants to have their say, and so on. Digging down the rabbit hole, I think to myself, I could do larger portions of this work faster alone (and somewhat better, too), but it's not my responsibility (someone else gets paid for that), so by design I should not care. But I do, because certain things go hand in hand (as you may experience it, when you done sideprojects on your own).

I know this is something Fred Brooks has written about, but still, what's your strategy for staying as productive as you know you could be in the cubicle? Or did you quit for some related reason; and if so where did you go?

share|improve this question

closed as off topic by Walter, gnat, jmort253, maple_shaft Nov 25 '12 at 2:42

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

4 Answers 4

up vote 13 down vote accepted

Welcome to the intrinsic problems with team dynamics.

The problem is indeed one that Brooks described. When we go from one person to two, we have 2 sets of hands that work, but we have a line of communication that is needed. When we go from 2 to 3 we have 3 sets of hands, but 3 lines of communication. When we go from 3 to 4 we have 4 sets of hands but 6 lines of communication. And so on. The number of lines of communication grows quadratically, the amount of energy to do work linearly, and at some point you reach a point of diminishing returns. Your team is probably about at that point.

In fact there is empirical data on this subject. In Steve McConnell's Software Estimation he has a chart, I forget on which page, correlating team size to calendar months to complete a project of around 50k lines of code. It has an interesting shape. As you add people, the number of calendar months drops, but the efficiency per person does as well until you reach a minimum at groups of 5-8 people. Then calendar months RISE as teams get larger, then start to decline. Only when you get to around 20 people does the calendar months for a 50k line project reach what it was for a 5-8 person team. (There probably is less functionality because a 20 person project is going to have more wheel reinvention.) But after that it continues to drop. So your team is right about that size where diminishing returns make growing the team useless.

So what can be done to improve productivity, either for a team or a personal level? The answer is to eliminate the needs for lines of communication. There are two basic strategies for this. One is to divide up the work such that people are in small teams that need to communicate with each other a lot, but not so much with others. (Common trap, management declares that it has so divided the teams, but it isn't really divided. If X winds up having to talk to Y then that is communication overhead, no matter what the org chart says.) The other strategy is to move towards having a process that guarantees that there is documentation of everything that needs it. So that instead of people directly talking, people consult documentation.

Of the two strategies, the first is by far more efficient, and is far more fun for programmers. However the second produces results that are far more predictable, repeatable, and appeals to management. (In theory it also can scale to faster overall development times. In practice, of course, a small team of very good people can beat a large team of average ones. In theory a large team of very good people should be better still, but finding a small team of very good people is already hard, finding a large team like that is hopeless.)

As a programmer, you should follow a mix of the two strategies. First seek opportunities to work in the parts of the project that you already know well. This reduces how much you need to ask questions. Also when people have to ask questions about stuff that you did, think hard about how you could have prevented them from having to ask, or have made sure that if they did ask, they needed to take less of your time figuring it out.

And a final note that is tangential to everything else. In one of McConnell's books (I forget which one) he recommends keeping track of bugs by component. IBM found that a very large fraction of their bugs would be confined to a very small fraction of their components. Then they rewrote those components from scratch. By rewriting under 5% of their application, they managed to reduce bug counts something like 50%. (And that 5% turned out to be easier to rewrite than people expected.) You're unlikely to be in a position to get your organization to do this. But keep track, and see if you can figure out the most intense ball of mud in your application. You probably don't need to keep track - it is that bit that everyone dreads that keeps breaking. If you can get your organization to rewrite just that piece, it probably is not as hard as everyone dreads, and people's lives will get better. Including yours.

share|improve this answer

The short answer is: yes, you are probably more productive alone than in a team (as most developers). Yet there is no reason you should quit or go crazy (unless you plan to code by yourself forever). So, that is not a problem with your specific team.

Steve McConnell has a great article about team sizes and productivity that might help you to better understand the problem you are facing. Communication is probably the main issue:

  1. "If you’re the only person on a project, communication is simple. The only communication path is between you and the customer. As the number of people on a project increases, however, so does the number of communication paths. It doesn’t increase additively, as the number of people increases, it increases multiplicatively, proportional to the square of the number of people."
  2. "The typical approach taken to streamline communication on large projects is to formalize communication with written documents. Instead of 50 people talking to each other in every conceivable combination, 50 people read and write documents. Small projects can avoid documents that are created solely for the sake of streamlining communication."

And this is one of the reasons agile development has proved to be so productive: less people means less effort in communication and documents.

That said, one might wonder why to have large teams. The answer is time. Even though your productivity would be 50% on this 7 person team, the product would still be delivered faster than if it was coded by yourself. Using some rough math: 350% (7 * 50%) > 100% (1 * 100%). Of course, there are drawbacks. In this case, it is cost (people are getting paid the same, despite their productivity loss).

Hope the answer is helpful.

share|improve this answer
  1. Skew your working hours. For example, work at home two hours in the morning until the traffic subsides and then work the rest of the day at work. Or arrive to work before the traffic starts, and work alone a few hours... Or go home early, relax, family/hobbies, and then open the laptop at 2100 and work another hour or two. Alternatively, ask your boss to work from home all day when you have a bulk of work to get done, which does not require oversight and coordination.

  2. When you are doing something, try to do only that thing. Snooze any interruptions (close Outlook, Facebook, ask people to come later). Don't answer company phone calls/emails when you are with your loved ones, unless you are officially WFH (Working From Home) - see 1. Try not to install your work email on your mobile phone - a big time saver. If someone really needs you he can text you or call you... usually it can wait for tomorrow.

  3. Work with your team-lead to box (time limit, people limit) coordination tasks. In our company, support can hijack R&D daily. So we get all of the relevant support cases that requires triage after the scrum meeting. We time-box this interaction, and try assigning single person per day to investigate the new support cases (is this a bug, a feature, usability, etc...). Time-box also kitchen chit-chat. Some of our team members go for a coffee-break together, they like it that way. The rest of the time they are at their desk.

  4. When helping out a colleague do not let them waste your time. If they are answering a phone call during your session, politely go back to your keyboard after 59.99 seconds. Time box also small favors. If it takes more than 30 minutes, tell them you couldn't do it... and ask them to triage it as a feature. Better yet - teach them how to do it themselves (delegate work).

  5. We still use Kanban Board to track milestone progress. If someone is working on "a small favor/urgent", we put a Red sticky note instead of a yellow one. That way everyone knows that there is a price for the "just do this one little thing for me". Or if it's too many small items for you to label it, raise a general flag saying you are "swapping to disk" - meaning much slower than usual. Give your boss a chance to filter out noise, or give you more time to get the job done. The important this here is that you do not work double shifts just because someone else did a bad management call.

  6. Use virtual teams (commando). A virtual team is a small group of people (2-3) that move to a separate room, for a limited time (2 weeks) to get a feature on time. Everyone knows they should not be interrupted, they usually come and leave work at the same time for these two weeks, report together on their progress, and have lunch/fun/pair-program/whatever together. This can be a life saver for certain "don't-f-it-up-get-it-on-time" features.

  7. Reduce ambient noise. I can't get into the zone when there is more than one noise source (loud ventilation, background music, background conversations, obsessive stress-thoughts in my head). If it's from the hall, ask them (politely) to get a room. If it's from your room, try to find another room (one man meeting with yourself for a few hours) - use a wireless keyboard/mouse/pad whatever. If you are a programmer that happen to have people skills (just kidding :) talk about noise with the others in your room. If your work collueges don't mind you wearing a noise-cancellation headphones, use it for a few hours a day.

  8. Don't be ashamed to ask to pair program. There are days, that I just feel I am not good enough. That's ok! Ask a friend or your manager to pair program for an hour or two. Tell them you are not concentrated and you need help. You can turn it into your advantage by inviting your test-peer, or a new guy that wants to learn from you - or ask a senior engineer/ your boss, for productivity tips along the way. That's how I got to known new keyboard shortcuts in eclipse, and learned some nifty unit testing tricks. Ask "how would you do it?". Sharing is Caring :)

  9. Last but not least - E N J O Y. The minute you stop enjoying your job, your productivity drops. A good manager knows that it's hard to get the best coders, so they try to make sure everyone is satisfied. If you are not happy, learn whatever you can (you are already there aren't ya?) and then call a friend that is happy with his work, and join him. If you don't know any such friend, go to local coders meetup and mingle. They are usually a happy bunch.

share|improve this answer

This is one of the biggest challenges I've had leading software teams. Ideally the project would be broken up into standalone chunks that can be owned by individuals. These chunks would then be executed almost as fast as that one developer could do an individual project. As the lead I help coordinate between the different pieces/teammates and maintain a cohesive vision for the whole project. I would work to actively remove barriers to individual productivity like you describe. This also need not be functional chunks. You can also take a pipeline approach. That is have part of the team focused on preparing/implementing the next phase while the other half does final integration, test, and support on the prior phase that's now feature complete.

Sometimes this ideal is hard to achieve. Management may try really hard to force you to have that baby in a month. Extra unneeded manpower may have to be worked into a schedule that's already optimal with a small elite team. The project becomes "overcrowded" and the pieces assigned to individuals are too interdependent. I've mitigated this a bit by pairing two devs on what would otherwise be a single task in the ideal model. Then they either pair program or as a pair can work much more cohesively than the larger group in dividing up their task into work for two people on a hour-by-hour basis. But even this breaks down if the team is too overcrowded.

Sometimes also too many unskilled or unfriendly teammates dramatically slow everyone down. Some people feel the need to work against the team. Others just need help. The former should be summarily fired while the latter dealt with in small doses (that is only so many junior devs per team).

In the end it really up to the team lead and management to identify and help cope with poor team dynamics. Maybe your tasks are poorly organized? Maybe your team is too big? Maybe there's a bad egg holding up progress?

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.