Specialists And Xp

The trick with specialists is interfacing them. Each may do her thing well, but when we need to put the work of two of them together, it can be hell. Thus, I suppose, we often get the "architect", who somehow brings these things together into a coherent whole. (Much input from customers and others assumed.)

An interesting aspect of C3 has been our use of specialists. We have evolved the following approach: we bring in the expert and watch her while she optimizes our database or converts us to Version Umpty-ump. Then we throw away all her code and do it ourselves. (And ourselves doesn't even mean me, it means a couple of the full-time Chrysler people.) At the end of this, we have a system that we can still understand, without any of those scary mysterious regions where there be dragons.

It's no phone system, but it is complex (1800 classes, 25000 methods), and the ordinary folks who wrote it actually understand it! Mark a tally on RAH's side, perhaps? -- RonJeffries

This seems like a great way to use specialists. You have them come in and teach you how to solve your problem, then you solve it. You don't understand the general techniques of optimizing a database as well as she does, but you understand how to optimize your database, and you probably have learned a bit about optimizing databases in general.

This does not seem to me to be a tally on RAH's side. You are still depending on specialists. Moreover, you have specialized roles like customer and coach that only a few people can play. -- RalphJohnson

It seems to me that there is a more fundamental intersection (or non-intersection?) between SpecialistsAndXp. XP removes many of the specialized non-developer roles that tend to hang around large development projects: business analysts, testers, designers, project planners. The developers, as generalists, take on all these roles. [See EveryoneShouldBeaDeveloper] And pairing, if it is done dynamically, goes right to the heart of preventing specialists on individual components, libraries, or subsystems that make up an application. You certainly need people who are (or can become) deep experts on the technologies you use. But their ability to operate effectively on the team is more important than their specific technical expertise. -- BillBarnett