Should Developers Perform All Tasks or Should They Specialize? [closed]

Question

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

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

Cons
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

Pros
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

Cons
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.

Answer 1

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.

Answer 2

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?

Answer 3

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.

Answer 4

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.

Answer 5

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.