What's the ideal development team composition?

Question

This question might be a little too open-ended, because there are so many variables involved. I'm sure someone could describe a modern take on Brooks' Surgical Team from MMM.

I'm wondering what people's opinions are on specialists vs. generalists. Should you build a team of people who can pretty much do it all (jack-of-all-trades), or should each person be totaly focused on one aspect of software engineering, leaving the big picture to the development lead?

I tend to prefer generalists, because it gives you a lot more flexibility when things change, and developers who understand the big picture, how every part of an application interacts with every other part, tend to waste less time designing things that just won't fit.

The counter-argument to that, of course, is that a generalist doesn't have time to truly master all the intricate details of each technology, and therefore will be less effective than a specialist.

Answer 1

I like teams where you have a mix. The generalists tend to make the better team leads because they focus on the bigger picture items. But I like relying on the specialists if there is a specific problem (like the Performance guy, or the Database guy).

Answer 2

I think. that depends on the size of the team.

If you are on a small team and do about as many different things/technologies as there are team members, then generalists have a few advantages. Just think about vacations/sickness or whatever time off from team members that are responsible for a certain project. In a specialized team that would leave these areas completely uncovered.

However, on a large team with relatively few projects/technologies to cover, it makes sense to have specialists for each and have them do their best. The larger number of people compared to the number of projects makes these specialists more redundant and individual loss would not hurt that much.

Answer 3

I believe that you have to scenarios

1. Small Team - mISV In this scenario you need people that are all Developer, the is a book Coder to Developer, is this book Mike Gunderloy explain better than anything I can write here why you need Developers.

2. Large Team - Big Company In this scenario your are in the opposite side. If the team is large enough you would want that each person is specialized is something and if the team is small but in a large company you problably have a lot of resources, like IT people to help you.

Answer 4

I would say that first off, it depends on the size of the company and the intended target of the application you are working on.

1. If you are working on maintenance of a mature application then a small team of developers is likely a nice balance. Plus, having multiple people that know how the application works means that you and can train others as developers come and go.
2. If you are working on a new business application then the team is likely going to be limited in terms of size by the size of the company, but once again you at least once a small time so you have redundancy in knowledge if you lose people. Also, at some point it might be a good idea to have a designer on board for user interface design. This wouldn't have to be a full time slot, but you do want to try and avoid so called "programmer design." [1]
3. If you are developing a game then once again the size of the team will likely be dictated by the size of the company and upper management, but for this you want a mix of people that are specialized in various area of game development, plus some graphic artists that are familiar with programming as well.

As for the specialist versus generalist debate - I think that in some cases you want the specialist but in others you want the generalist. It likely depends upon the project itself, thus making for a hard question to answer.

[1] Stack Overflow Beta Design - http://blog.stackoverflow.com/2008/07/stack-overflow-beta-design/

Answer 5

As Fred puts it, there is no silver bullit ;) ...but I read a little from Alistair Cockburn who is a founder of the Agile movement and have very down to earth solutions for most things.

Alistair link

Think I might add that I think that people are so different, knowledge-wise and personality-wise, so finer grain design of a team falls back to the available resources

Answer 6

I'd say it depends more on the kind of problem you're facing.

I like to hire specialist as consultants while I look for generalist for long term jobs.

If you need to improve performance on an Oracle database then specialist is the only way to go. It will be faster and cheaper, in addition, when the job is done the consultancy is over.

If one of the projects of your "generalists" ends you can be confident into moving him to another project with a low/medium impact on his productivity which will dissapear over time.

Here are some rules I use to have in mind:

• Bussiness knowledge: Specialist. The more he knows about the bussiness the better. Nontheless don't use a consultant for this. This is not a short timed job.
• Marketing: Specialist. If you can combine this with the previous one then you'll have an awesome seller.
• Coder: Generalist. Usually hire always generalist people for coding. You may change the technologies involved and you need people with a base knowledge of everything basic on your bussiness.
• Database: Specialist. Database is suficiently complex to have an expert take care of it.
• Spec: Generalist. I'll even suggest hiring a coder. You need someone who is aware of what is needed to actually implement the software.

Answer 7

At present I am a member of a developer team of 5 people. The situation here is that all of us know the general part of the software (like base classes or helper classes) very well, so there is a high redundancy. Problems concerning these code parts can be managed by every one. But there are some specific parts of code, that can only be maintained by a special person of the team. Here we have a lack of redundancy, which clearly is a disadvantage, but I think it's impossible to have a team consisting of specialists only.