March 15, 2003

Specialization

Breaking a problem down into discrete chunks that can be worked on separately is good in most cases. You can estimate each little component separate of the others, and you can assign it to one person. You of course get an integration penalty when everyone puts their little pieces together at the end, but you account for this in your schedule and so you do fine.

But another problem with everyone working on only their area is when you have a very complex system (like the one I currently work on) debugging a problem can be a nightmare. Let's say that you find a case where the system fails and you don't really know much other than who works on which pieces and how to reproduce it. So you go around to each person and describe the problem, and show them the failure. They either respond that it is not their part or they respond that it is and they go and fix it. Easy, right?

Well, normally if you have people who work on separate parts of the system they don't really understand how the overall system works so they find themselves being handed problems where their little component is being used over the network, or being called faster than they expected, or having less memory, etc. They also will claim that the problem is their part if they are humble and can waste time trying to track it down. In the other, mildly more common, case they don't think that it is their problem so they don't help.

All of these situations are bad. It is very important that everyone on a team know at least enough about the system that they can use it in a normal way as a user would, and also be able to trace problems down to their source. Otherwise you can waste a lot of time with finger-pointing and wasted effort.

March 15, 2003 03:12 PM