Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are planing to introduce Help Desk and Support Desk in our project. Our current development team would be divided into two smaller teams: Support Desk and Development team. Support Desk would be responsible only for bug fixing. Development team would be responsible for making enhancements and new features development. What value do you see from such responsibilities and teams segregation? Can we find a differences between bug and new features in terms of development activities? Is there any real value of doing such things?

share|improve this question

migrated from Jul 12 '11 at 4:06

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

The border between a bug and a new feature may be very blurry sometimes, in particular when specification has various possible interpretations. For instance, how would you consider the lack of copy-paste in early versions of iPhones?

An alternate organization would be, based on an issue tracker collecting both bug reports and feature requests, a single team dedicated to fixing bugs and developing new features and a project manager deciding with the client which bug fixes and new features will be included in the next delivery.

People involved in bug fixing are much more motivated if they can contribute to new developments and are much more efficient because they have an intimate knowledge of the code base.

share|improve this answer

The distinction is difficult. There are things that are definitely bugs, things that are definitely features, and... stuff inbetween.

You could put an artificial barrier: if it's against specs, it's a bug. If it requires changing specs (be it extending them, or removing ambiguity) it's a feature.

You can conform to the soft barrier, make it one team with some bug specialists, some feature specialists and most just general developers who get things done.

Some teams did away with the distinction completely - in Mozilla every feature is a bug of "lack of feature".

share|improve this answer

1) Faster turnaround on reported bugs because people are dedicated to the task 2) More predictable scheduling of new features since that team isn't constantly distracted by debug reports

Bug hunting is a totally different kind of work than adding features, the bug team will develop instincts and shared knowledge that a generalized effort wouldn't except after a longer time. (at least that's what I've experienced)

share|improve this answer

Your Answer


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

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