Category: AntiPattern (CategoryAntiPattern) ---- ''Synopsis:'' Four out of Five developers cannot define good abstractions; this leads to excess complexity. ''Refactored Solution:'' Project teams should have designated architects who are abstractionists, i.e. possess the architecture instinct. (JamesPoupard inserted this here to give context) ---- Context: Therefore: (mistakenly) Resulting context: Okay... I started the discussion and template to find that I don't have the book next to me to fill out the 'canonical' AntiPattern. The basic idea is this: When doing Object Oriented design, it has been forwarded (through a few academic papers) that the skill of 'abstraction' is one that not everyone is terribly good at. (Either by aptitude or experience) When this mix is put into a project where the team makes all decisions about architecture, the abstractionists are often outvoted when it comes to design decisions, resulting in a system that is not as flexible as it could be. The book discusses taking the abstractionists and putting them in a TechnicalArchitect role and letting them control and influence the design of the system. Now, here is my dilemma, and need input on how to better approach the problem... One of the things I have noticed about ExtremeProgramming is how 'democratic' the team is. To quote the back of Beck's book ExtremeProgrammingExplainedEmbraceChange: "Don't force team members to specialize and become analysts, architects, programmers, testers, and integrators - every XP programmer participates in all of these critical activities every day." Now, while I have worked on teams where everyone seemed to be readily capable (and experience in) object oriented design and programming, it seems that on less experienced teams, an XP approach would lead to "everyone charging the hill" in the style of TheGrandOldDukeOfYork. (Which, unfortunately, I have also experienced.) There seems to be a little disconnect on how (and where) XP would be successful. Has anyone had experience (or notes) on how to deal with XP in such a situation? -- ChadThompson ---- I think the name's inappropriate. TheGrandOldDukeOfYork ''led'' his 10000 men to the top of the hill (and down again) which is not at all what this page is about? ''The nursery rhyme is a sanitization of a War of the Roses battle in which the Duke of York was pincered, murdered and his army routed. An entirely appropriate title I would suggest.'' Er, no, the War of the Roses was in the 1300's sometime, and the WikiPedia page http://www.wikipedia.org/wiki/Frederick,_Duke_of_York shows clearly that Frederick was around the 1800 mark. This little sub-section should now be tidied more. ''This is a matter of debate; the nursery rhyme might well be about the War of the Roses; see http://en.wikipedia.org/wiki/The_Grand_Old_Duke_of_York'' ---- I thought that it was during the American revolutionary war. The DoY formed up his troops and marched them up the hill, and they were fired on by the Americans. Noting that the lines had become ragged, (tut, tut, tut), he marched them back down and reformed them into neat rows. During this interval, the Americans reloaded their muzzle-loading rifles. Eventually, the DoY was injured, and some lower ranking officer marched what remained up the hill, ignoring casualties, and took the hill. Perhaps the antipattern then is halting development when it's on a roll to (unnecessarily) tidy up documentation. ---- "Democratic" is the wrong term to use about XP. Someone said something once about "from each according to their ability"... The quote says [emphasis added]: "Don't '''force''' team members to specialize and become analysts, architects, programmers, testers, and integrators - every XP programmer '''participates''' in all of these critical activities every day." It doesn't say: "prohibit team members from exhibiting more skill in one area than another". It also doesn't say: "require team members to excel at tasks they aren't well qualified to perform''. Within our team there are great differences in ability (and interest) in each of the areas mentioned. This strengthens the team. Since we work in pairs, and we aren't above manipulating who works with whom on which task from time to time, no-one ever has to perform a task they're uncomfortable with alone. When we do group design exercises, via CRC or whiteboard sessions, everyone is involved. That doesn't mean that everyone makes an equal contribution to every activity, but it is part of the job of those people particularly skilled and experienced in design (say) to keep a (design) session on the rails, ''and'' draw out whatever contribution the less skilled can make. When difficult integration problems arise (say), and they do, it turns out to be exactly the folks who don't thrill to abstraction who are good at doing this concrete task, and so it is now ''they'' who need to take the dominant role and keep the team moving in the right direction. This is one of the things that makes teams so effective. Any team. XP amplifies this effect. XP teams don't have hierarchies in terms of tester