The Grand Old Duke Of York

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<coder<lead coder<architect<lead architect (which is to be found in many a trad. development shop). But, being composed of humans, XP teams do have partial orderings by skill. The flaw with the traditional hierarchical team structure is to assume that the skill ordering and agrees with the corporate recognition hierarchy. ArchitectsDontCode, but the assumption is that if they did, they'd necessarily do it many time better than the mere coder. By not having a management type hierarchy an XP team is able to make optimum use of each member's skill as and when it is that skill that's the limiting factor on the team's performance.

There probably isn't any such thing as a naturally occurring team where every member has the same level of skill and interest in each of the activities mentioned. Even in a team composed of people with limited experience and skill, there will be these skill orderings. Now, if the team has a uniformly low level of skill in everything (even the member deemed to be the "architect"), well, then without outside help they will fail. With XP, they'll probably fail more quickly and more obviously. And that's a good thing, saving the customer money.

But supposing they don't crash and burn immediately, XP lets them collegially gain every scrap of help they can from each of their ComparativeAdvantages amongst themselves for each kind of activity. Being less experienced, they'll do less well than an experienced team, very likely. But I submit that using XP they'll perform closer to their optimum than with many other approaches. I'd also suggest that an inexperienced team doing XP with an experienced coach could perform better in many cases than a more experienced team of comparable size doing, say, RationalUnifiedProcess. -- KeithBraithwaite

Great stuff, Keith. This has helped me to frame a proposal/argument, plus helped me work through a few misunderstandings! Thank you. -- ChadThompson

You're welcome. Let us know how it turns out. -- KB

CategoryAntiPattern CategoryDevelopmentAntiPattern