This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
This might be a better (even more extreme example)... You have a team with 1 senior engineer and 100 entry level engineers. The senior engineer is the only one with engouh experience to make major design decisions (the others tend to be wrong at least as much as they're right). Would XP work here? (Yes, I know its designed for small teams, but humor me to get to the point.) I say no because the one person who needs to make the big decisions can't have them communicated to the team fast enough through pair programming and discussions. (I don't trust B learned it when paired with A, so that C can learn it when paired with B. Those channels can get noisy.) I think some degree on "decisions from a central authority" is needed and must be formally communicated. Now as I noted, the example above was taking an idea ad absurdum. But if you accept the above, then can imagine scaling it down to reality.
I think a team of *experienced* developers would need more formal communication, too, so I really don't get your point. I also don't think that Big Up Front Design needs to be the answer - if you want to discuss this issue, we should probably start another thread, though.
There exists a project of complexity C such that for some team of N senior engineers with combined ability X, and M junior engineers with combinaed ability Y (and perhaps all sorts of other parameters), XP is less efficent then some upfront design.
I don't understand the "versus" here, as XP *does include* "some upfront design". I agree, though, that an inexperienced team needs to adapt XP in a different way than a more experienced team. But I don't think that more "formal upfront design" is the best solution. What I would rather like to see is a longer exploration phase, probably with more emphasis on design discussions and architectural spikes, and more design discussions scattered across the whole project life cycle, probably supplemented by thematical workshops. [ May 18, 2003: Message edited by: Ilja Preuss ]
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jul 11, 2001
Mark also wrote
I've seen teams where the senior engineers didn't fully appreciate the scope of the misundertsandings. He talks to Joe who misunderstands A, and explains it to him. He doesn't also epxlain it to Alice and Mike who also misunderstand it. He explains B to Mike, but not to Alice. he doesn't realize how widespread the confusion is (or takes him a while to figure it out).
That certainly can happen. I wonder, though how critical the concerns are in an XP environment. So, what parts of the XP practices did they practice? Which ones did they not use which might have helped to - make misunderstandings less likely or found earlier out about - make misunderstandings less critical?
Will upfront design fix this? Of course not, it's not a silver bullet either, but I think if done right, it's more likely to work in this case.
Why? Why is an upfront design (I suppose you mean a bunch of formal UML designs and such things) more effective to communicate? Why is it less likely to be misunderstood? Why would misunderstandings be found out about earlier? [ May 18, 2003: Message edited by: Ilja Preuss ]