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.

We have a small but growing team at work, and are thinking of doing things differently. We develop websites from scratch and do HTML/CSS/Javascript/PHP/MySQL coding. Currently, we all work on things as they come, and everybody could do either of those things. So everybody in the team has currently several projects assigned, and they could be doing different things, so for one project somebody takes care of the front-end things - mostly Javascript/CSS, and for another site it's the back-end part with mostly PHP/MySQL. The issue is that most in the team have a decent basic understanding of things but are still learning the details. And it seems to take its toll in terms of productivity. I think we could improve this by assigning everybody to just specific tasks (only CSS / Javascript / PHP / MySQL... just one thing at a time). This way:

  • Tasks are clearer for everybody
  • Everybody can better learn one particular thing and not get overwhelmed
  • When mastering one skillset, one can upgrade to the next level
  • Productivity should go up

What do you think?

share|improve this question

migrated from stackoverflow.com Jun 4 '11 at 2:39

This question came from our site for professional and enthusiast programmers.

    
Henry Ford would agree. –  Till Jun 4 '11 at 1:27
    
It's the exact same and totally valid basic principle i was talking about and i wasn't being judgmental. But your vanity concerns are duly noted. :) –  Till Jun 4 '11 at 1:42
add comment

3 Answers

There are tradeoffs.

Team of Specialists: Benefits

  • Faster solutions - Specialists tend to solve problems (in their domain) faster
  • Better solutions - Specialists tend to make better solutions

Team of Specialists: Costs

  • Resource allocation - You may have alot of work for one specialist, and none for the others.
  • Bus factor - You may end up delaying or canceling a project if a specialist with necessary information leaves, gets sick, etc.
  • Information Concentration - Only one person may be able to answer questions regarding a solution/domain.
  • Communication - Communication can suffer when everyone is working on their own problem.

Other Observations

  • Ownership - Teams of specialists tend to lean towards individual ownership. Generalists tend to lean towards group ownership.

Mitigating the Cost of a Generalist Team

  • Consult the specialist - have the specialists consult on the problem
  • Reviews - have the specialist review the solutions
  • Communicate - encourage more communication within the team
share|improve this answer
    
There's also the cost of developers not looking beyond their little claim. If you split between SQL and PHP (for example), you'll get PHP developers that use the SQL backend as key/value store, instead of offloading queries to the database. –  Patrick Georgi Jun 4 '11 at 7:06
add comment

Don't focus on productivity too much if they are still learning. Ask the developers what they like. Some will like to specialize in, say, PHP coding, while others like to broaden their knowledge and rather have a basic understanding of all languages first than to specialize on a single language.

If you let them choose the path they like (within limits, of course) you keep them motivated, which will increase performance.

There is an advantage in doing different things. If for some projects you got more work to be done in PHP and relatively little styling, you will need those PHP programmers. If some of them only got HTML/Javascript assigned to them in the past months, they will have a hard time switching to PHP. So it's definately a good thing to let those who want to, learn more than a single language. You'll only need to push them in one direction if you're about to get a shortage of one disciplin and an abundancy of the other.

You could gain productivity by introducing different project management methods, like SCRUM.

share|improve this answer
add comment

Another big benefit of having a separation of responsibilities is that the interface between components is discussed, agreed upon, and known by more than one party.

share|improve this answer
    
-1 In my experience this is almost never the case. What usually happens are integration problems because of (at least) subtle misunderstandings in the interfaces. –  dietbuddha Jun 4 '11 at 4:49
    
This may be true of a rushed 1.0 release and less and less so as the software and development teams mature. –  karmakaze Jun 4 '11 at 20:23
    
karmakaze: One of the most common things I've seen in specialist teams are integration bugs when trying to bring separately developed components or layers together. There is also a correlation between how long you wait before integrating and the magnitude and severity of the bugs that arise. –  dietbuddha Jun 4 '11 at 20:29
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.