What's it like to work in a large programming team?

Question

I've always felt lucky to work in a small programming team. I think the most I've worked with is 11 programmers. What is it like working on a project with hundreds of developers? Thousands? What does scale and what doesn't?

EDIT: Thanks for all the responses! There seem to be very few positives:

• possible to work on mega-large codebases
• better internal career development
• employee protection against abusive management (this is more -ve on small than +ve on large)

Is there any other benefit to large teams?

Answer 1

I've worked (briefly) in an organization with at least hundreds of developers. But of course (?), the organization is internally partitioned so that you as a single employee don't have direct contact with all the others, that would be very hard to keep up with.

At that particular place, the software was split into components, with teams formed around components. Some teams would work with only a single (large) component, while many teams had the responsibility for a bunch of (smaller) components.

Of course this implies everything that working with a very large code base does; things like configuration management, building, integration, and so on become important, big, things that are in turn made by specialized devoted departments. And you awe them, for being able to collect all developer departments' output and regularly (once a week, where I worked) integrate it all together into one cohesive whole that actually worked.

Answer 2

Communication is what I have found to be the biggest thing that starts to degrade as the size of the team grows. It becomes harder to get communication out, and harder to ensure that everyone is still on the same page. I work indirectly on a team of about 75 developers, we use a common code base, but many of the 75 break out into smaller groups for individual "activities". For us the communication is just an utter nightmare.

Management of larger groups is also harder, as in most environments after 8-12 people additional members of management get involved, sadly this just exaggerates the communication problem as it typically creates a "silo" type environment where the individual subsets start breaking off of the large group and try to keep knowledge inside their group.

Answer 3

I find bureaucracy scales really well.

Other than that, not a whole lot. Large projects have large teams because there's no other way, not because it's more efficient (per developer). You pay a cost as soon as you add a second person to the mix in terms of inefficiency (ie knowledge transfer and communication).

Largest project I worked on had 70 or so develoeprs across 5 different sites. Even a one line change took a day minimum although that was in part due to the fact that the build took 45+ minutes over a network link from Zurich to London and starting the app took another 45 minutes. Check-ins took about 5 minutes per file. I'm not kidding. The London developers could do this in a fraction of the time.

Anyway, what you tend to find is that on large projects you'll have a bunch of team members that you don't interact with all that much. It's more like a loosely affiliated collection of mini projects. I once read that Microsoft development tended to break down projects into teams of 5-7 developers, even for large projects like Microsoft Office.

Part of the difference is also the difference between small and large companies: larger ones tend to have more process, more rules, less flexibility and so on. But that's by no means guaranteed.

It can be good for career development though. In a small company someone has to leave or die before you can get a promotion (or the company has to be growing such that the team expands and you move upwards) whereas in larger dev departments you can move between teams and so on.

Additionally you can sometimes find some really smart people to attach yourself to and learn from. In small companies being so isolated and self-reliant can be conducive to programmers going a bit "strange", sorta like a hermit.

Answer 4

I once spent a year working on a team with over 500 people on it, about 200 of those were developers. We were delivering an EOA, integrating several different SOA solutions.

In practise there were somewhere between 30 and 50 teams, each with varying numbers of programmers (3 on our team), each with responsibility for a different aspect of the overall deliverable.

The largest team I ever worked on was about 15 people (this was only for 3 or 4 months, in a differnt company). I was technical lead on the team, and took to getting into work at 7am, I'd get 2 quite hours before everyone else got in, it was the only way I could get any of my own tasks done.

I wouldn't like to work on a team with more than 8 or 10 developers, 15 was far too many for a single team (the team could easily have been split into two, not my call unfortunately), 3 or 4 devs is a nice comfortable size IMHO

Answer 5

Back when I made software for weapons systems we had LARGE teams of software developers. Since no one person can wrap their head around the requirements (some of which were classified), it was all about teams and how the teams interacted with each other.

1. Configuration Management -- the nightly build process -- was a very big deal. In those days it took a large distributed computing cluster to recompile the world every night.

2. Work authorizations -- and charging your time to the correct line item on the master overall project schedule -- was a big pain in the neck. Down to the 0.1 hr. increments.

But the biggest deal was change notification. Particularly interface changes.

This was so important, they invented this crazy two-layer process. Most of the effort went into making sure that the Interface Change Notice Request (not the notification itself, but the request for notification) had elaborate support software with a database and reports and what-not.

Once the request was approved, the actual notice more-or-less went without saying. Meaning that it was really a one-layer process and the request effectively was the notice. But when you're doing waterfall development, everything has to be thought of a long time before any developers show up.

With so many people working in parallel, there was a Configuration Control Board. All the various team managers, plus group of folks who's job was simply to coordinate changes.

Answer 6

I've never worked for a large team of programmers, but the result of an organization increasing in size is usually more rules. This isn't necessarily always a bad thing! In addition to the rules that make everyone's life difficult, there are also more rules to protect employees and ensure good process.

I've seen managers in small organizations get away with things that would've immediately gotten them terminated by an enterprise HR department.

Answer 7

My first "real" programming job was to work with an army other others to develop international air traffic control systems. It was a very successful endeavor and we were considered a Capability Maturity Model Level 5 environment. Since then I've been in mid-sized and small shops. So, which is the best place to be? Personally I would take a smaller shop over s huge one any day. While some might consider Level 5 as the Holy Grail, for me it was suffocating. Everything has to be documented, approved, signed-off, etc. Don't get me wrong, I defintely see the value in it, especially for systems as critical as air traffic control, but the question is how do you want to spend your day? Do you want the freedom of being able to dream things up and then implement them, or do you want to write to the requirements? Perhaps if I had stayed longer with the ATC system I might have risen to the level of being able to design as well as develop, but even that required X number of years, Y number of approvals, Z number of promotions--all well prescribed with no chance of deviation. It was stifling.

One last thing, in general I find the quality of developers to be much higher in smaller companies simply because they can't hide. Its not hard to be mediocre in a very large company, but it becomes painfully obvious in a small one and they often don't last long.

Answer 8

The one difference I've noticed with big projects is the office politics. The larger the projects the more dominant the politics are.

My first project out of school was a couple of hundred developers. As a cocky and naieve developer fresh from school I was really not ready for that. The only thing that saved my hiney (and it is the only thing that will ever really protect you) was the amount of friends I made.

That's the biggest lesson I learned from that. Try to make friends with everyone. Even the jerks. In particular, if you have a chance to stop work for a minute and have a conversation with someone you've never talked to before, do it.