Does XP pairing assume that knowledge is a commodity?

It seems that practice of rotation of developer within the pair assumes that all developers are relatively equal and even if they are not very familiar with the area, they are able to ramp up quickly. This msy not be true, at least it does not seem to be correct when we look what has been happening in other areas of engineering and science. After all, scientists to not rotate in labs, they keep working in their relatively narrow fields, digging deeper and deeper. They do get peer reviews but those reviews come from peers working in the same area of knowledge. In physics all scientists are physicists, but I doubt that one working in quantum mechanics is readily interchangeable with one working in acoustics. He or she does can learn the new field, but it may take literally years.

There is a lot of areas in software engineering that require specific knowledge and expertise. Parsers, compilers, OS kernels, GPU programming, 3D rendering, game engines, image processing, OCR, encryption, data compression, parallel processing and so on. I guess inside the knowledge area you may still try to rotate people but the deeper the required knowledge or the narrowser the area of expertise, the more difficult it may become. Maybe inside certain areas you have to keep the pair stable?

Did anyone tried rotation of developers in abovementioned areas? How did it work for you?

Opinions and flames are welcome :-).

Comments (5)

  1. XP is more about the software development process than about the software area! It may be seen as a void in XP, but I personally think it’s not. It’s just something XP won’t answer for you.

  2. Well, every process is created for a particular area. Process common to automotive engineering may or may not apply to checmical engineering. It all depends. Hence I am seeking knowledge how XP is typically implemented in knowledge heavy area of software ensineering as opposed to, say, a medium size online store.

  3. Jim Arnold says:

    If we needed to implement something that a team member had much more experience with than others, we would see that as an opportunity for everyone to learn from them. Leaving them in isolation means that no-one else gains from their knowledge. It also begs the question – how would the rest of the team be confident that the "expert" has implemented this feature correctly? And what do you do if that team member gets hit by a bus?

    I would encourage rotation, perhaps with the expert staying on that task until others were confident that they could take the task on themselves.

    Perhaps there are exceptions to this, but I think the trend should be towards knowledge sharing rather than isolationism.


  4. Oh, I totally agree. I am just trying to gather real world knowledge how did it work, how long did it take to a less experienced member of the pair to catch up, did expert guy complain a lot 😉 and was the resulting code quality better or the same.