Disclaimer: The intent of this question isn't to discern what is better for the individual developer, but for the system as a whole.

I've worked in environments where small teams managed certain areas. For example, there would be a small team for every one of these functions:

  1. UI
  2. Framework code
  3. Business/application logic
  4. Database

I've also worked on teams where the developers were responsible for all of these areas and more (QA, analsyt, etc...). My current environment promotes agile development (specifically scrum) and everyone has their hands in every area mentioned above.

While there are pros and cons to each approach, I'd be curious to know if there are more pros and cons than I list below, and also what the generally feeling is about which approach is better.

Devs Do It All

1. Developers may be more well-rounded
2. Developers know more of the system

1. Everyone has their hands in all areas, increasing the probability of creating less-than-optimal results in that area
2. It can take longer to do something with which you are unfamiliar (jack of all trades, master of none)

Devs Specialize

1. Developers can create policies and procedures for their area of expertise and more easily enforce them
2. Developers have more of a chance to become deeply knowledgeable about their specific area and make it the best it can be
3. Other developers don't cross boundaries and degrade another area

1. As one colleague put it: "Why would you want to pigeon-hole yourself like that?" (Meaning some developers won't get a chance to work in certain areas.)

It's easy to say how wonderful agile is, and that we should do it all, but I'm somewhat of a fan of having areas of expertise. Without that expertise, I've seen code degrade, database schemas become difficult to manage, hack UI code, etc... Let's face it, some people make careers out of doing just UI work, or just database work. It's not that easy to just fill in and do as good of a job as an expert in that area.

closed as not constructive by George Stocker, Jim G., gnat, Walter, Matthieu Sep 11 '12 at 14:45

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • This question will probably be closed soon, but I'll offer this: A developer shouldn't feel comfortable as a strict specialist. As a developer matures, he/she should build a thorough understanding of the entire stack. Afterwards, that developer may pursue a specialist's job for the right benefit package. – Jim G. Sep 11 '12 at 0:49
  • Why will the question be closed? If there is a vote to close it, there should be a comment explaining why so I can learn. If this question isn't a good fit here (and why would that be?), where is it a good fit? – Bob Horn Sep 11 '12 at 0:51
  • 1
    The two close votes are for "Not constuctive", and that close reason states: As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance. – George Stocker Sep 11 '12 at 0:53
  • I think "any thoughts are appreciated" is a red flag to people. I would remove that. Your question is in the title. – psr Sep 11 '12 at 0:55
  • 1
    Other than that, it's possible people (not I) might think you are encouraging a list of pros and cons, and list questions rarely have a clearly correct answer. – psr Sep 11 '12 at 0:58

As usually, nobody in practice does things 100% one way or 100% the other, even if they might take that position in an argument for the sake of simplicity.

You mentioned Agile, and Agile does generally tend towards less specialization. This is because everyone is expected to refactor code as they do development, and that is difficult to do if the refactoring must stop at some kind of boundary, such as if it starts touching the code of a specialist who is very far ahead of the other developers in that area. So, the optimal amount of specialization is lower if that's the way you work.

Your list of pros and cons isn't bad. I would add a few, personally:

Pro - It's very nice to have somebody who can get things unstuck when really tough problems come up, and for some of those one specialist is worth a dozen generalists.

Con - Developers communicate less because they are working in their specialized areas most of the time. If so, they don't learn as much from each other and may optimize locally but miss the global picture. There are also fewer eyes to find bugs or bad designs.

Con - Redundancy has value. Having more people understand a given bit of code reduces risk of losing key information about the code.

Again, there are costs and benefits in either approach, so each team needs to try to find the trade-off with the maximum value for it's situation.

  • Redundancy has value. Agreed. But with the specialist approach there is redundancy as well because the specialists would be teams, not individuals. At least that's the way it would work in my ideal scenario. – Bob Horn Sep 11 '12 at 13:59

The system doesn't create value. The individual does.

More importantly, a programmer's economic value is directly related to their expertise and ability to adapt to changing circumstances.

I can't think of anytime where it's good to just be a 'Java Developer' or a "C# developer' or a "JavaScript developer". Imagine how the people who defined themselves as 'Cobol developers' now feel? (Besides rich). Or even better, how the people who defined themselves as Mumps developers now feel?

I used to think that developers should specialize (ironically, when I worked at a job where we didn't specialize). Now that I work somewhere where we have developers specialize (there's a clear division between FEWD and Back-end development), I wish we didn't.

Regardless of the language and the platform, there are common problems. When you silo yourself to 'front end' or 'back end', you run the risk that one group will make the same mistakes the other group just solved themselves. Anything can be improved with communication, but the problem can't be fixed if the developers don't have a frame of reference for fixing it.

Even if you have people who are 'better' at front end technologies, it can't do anything but help your business as a whole if developers are familiar with all aspects of their infrastructure and code. They don't have to become the 'go-to' person, but they do need to be familiar with it. Otherwise, what happens when one of them gets hit by a bus, or worse, the whole team?

  • Thank you for that Mumps article, that was interesting. And I don't mean specializing as in what language you use, but more in what part of the system you're working on. Perhaps all DB changes can go through a small team, but that small team isn't isolated to just the DB; they can do middle-tier work as well. – Bob Horn Sep 11 '12 at 14:01

It depends. If your project lends itself to separation, then do that. If your team is well rounded enough to work on everything, then that might be faster. If you have only 2 developers, then they're going to wear a lot of hats. If your problems are very hard, specialization might be required.

Tailor your process to your scenario; that will be how you get the best result.


The ideal team would have both types of developers. You want to have specialists because they'll have the depth of knowledge that the generalist won't have; they can bang out the code quicker, solve the tricky problems better or faster, and so on. You want to have generalists to be across the system, be able to identify the common problems and fix bottlenecks - for example, that minor change in the database might cost a week's worth of front end redesign. You work in a team, each developers skills, weakeness, preferences and pet-hates comes out and you dish the work up accordingly.

And I think the ideal developer will cover both of these bases. You want to generalise enough to be able to build systems rather than components or just 'bits' to help someone else build a system. But you need to specialise enough to have an edge over the next guy - you want to be the best at something, right?

Of course 'specialise' is a spurious term. I could say "I specialise in .NET"; is that a specialisation? In a way, yes because it defines where my skills lie, but it's hardly a niche area and even within .NET there's far too much to be an expert at. On the other hand, I could say "I specialise in XPath" - okay, that's great too, but it's a much narrower specialisation. You can't build much using just XPath, and if you know nothing but XPath then you're usefulness is very limited.

There are so many areas to be across, and there are only so many hours in a day, that you'll never cover all bases. Ideally you would have an range of experience, and areas of expertise within that range.


This will depend on the skill level of developers in the project.

Usually in a web project, if you have a dev with very good skills on jquery/html/css let him/her work on UI and make it pretty. Logically, a dev who enjoys building back-end code and services would be best useful doing that piece of the application.

However, there might be less experienced devs in the team, who may learn form experienced devs in the team.

In another words, if project has mixed skilled people on the team, let them do what they are best at.

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