I started to answer Torbjørn’s comment on my previous post about general specialist, but it turned out to be far too long for a comment, so I posted it hear instead.

I think I did a poor job defining the general specialist. Actually, after doing some more research I found that the guy I didn't remember the name of was Scott W. Ambler (which I’m a bit embarrassed of not remembering). Anyway, he actually doesn’t call it a general specialist but generalizing specialist (or craftsman), which is a better description. In my post I focused much on sharing knowledge. Sharing knowledge is important, but what I didn’t focus enough on is that generalizing specialists are also specialists in certain areas, but in addition to that also has quite a bit of knowledge in other areas. What Scott is stating is that you as an IT person should strive to become a generalizing specialist and not a pure specialist. His examples are focused on a much broader scale (like use case specialist, database specialist, C# specialist and so on). Torbjørn touched on this as well. What I'm saying is that by putting the same principals to a smaller scale, where you have developers specializing in certain areas of the application, you get the same effect.

So I think that developers should strive to teach themselves different part of the system, and not specialize in a few areas. One way of doing this is to motivate developers to share knowledge and allow them to work with parts of the system that someone else might do faster because he’s the specialist in that area.

Torbjørn commented on my previous post that:

“Nobody can be expert of everything”

And that’s not what I meant. What I meant was that people should be allowed to specialize in areas outside their specialty to become generalizing specialists. This will also let developers sharing greater knowledge within certain areas to be better suited to improve functionality within this area. Two people think better that one, right?