6

In agile pair programming it is recommended to switch pairs every now and then so as to increase the bus factor of the team. That means, most people in the team should work on different parts of the system at different times so that everyone has an understanding of it.

Now it is impssible that everyone has an expert level of understanding of each part of the system. That's because people are urged to specialize in one area of expertise. If you are an expert database admin, what's the point of working on the user interface of the system when you switch pairs? You will not be able to do such a high quality job as someone who has extensive experience in UI design.

How can you increase the bus factor and make sure that you have specialization in your team?

Improve this question
2
  • 1
    Don't you mean decrease the bus factor? Increasing the bus factor (the chance of bad things happening if someone e.g. gets hit by a bus) means higher risk, which is bad in terms of risk management.
    – Spoike
    Commented Nov 18, 2011 at 12:56
  • he is mixing bus factor with bus number, which you would want to increase and some times involves other modes of transport c2.com/cgi/wiki?TruckNumberFixed ;)
    – jk.
    Commented Nov 18, 2011 at 14:13

2 Answers 2

Reset to default
1

For the main, I'd keep the pairs within discipline - so, UI guys would predominantly pair with another UI person, DB guys would pair with another DB person. If you only have one or two in a discipline, then so be it - you can't always pair when you don't have the numbers. You are right that a UI specialist would not want or be needed to fill in for a DB specialist.

But, it is a good idea to sometimes mix it up a bit - your web service experts might have an idea for the UI, or the UI might have an idea about the DB structure which would simplify something back up on the UI layer - a different perspective can be extremely useful.

Also, DB and UI are quite far apart on the chain - you would get some advantage of the middle layers pairing more frequently with either DB or UI.

As with any work methodology - pair programming isn't something to implement slavishly just to tick a box of to say "yeah, we've done that" - it's there as a tool, and needs thinking to implement.

Improve this answer
0

Mix 'em up

Specialization is only a means to gain expertise.

Expertise does not have to come from formal training. It is most often gained by self-study and experience. And it is possible for programmers to be expert in multiple areas. By pairing people with differing experience, you can spread expertise throughout the team. After a while, instead of one database expert, and one UI expert, you will have several people who are highly capable in both. This is good for the team, and good for the team members.

Improve this answer
1
  • "jack of all trades is master of none" :/
    – siamii
    Commented Nov 20, 2011 at 2:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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