Communal Development

From: ChiefArchitect, ChiefArchitectOfXp

This is taken from GreatDesign. Let's try to sum up this ThreadMode discussion into a disseration on CommunalDevelopment or how one may retain collective ownership and equality between team members while still finding unique roles within that commune. Notice the choice of title. It says communal development, and not design. Development is a superset of design or construction. Let's attempt to represent each view without requiring each be pitted against each opposing view. This could be refactored into a several labeled paragraphs with each label describing a different take on CommunalDevelopment, Evolving an Architecture collectively, and so on.

One would expect that the C3 team had a lot to do with the creation and evolution of XP. If they didn't, if the architect (or system designer) had done it all, s/he would not (in my view) have been a doing a good job as ArchitectAsKeeperOfTheFlame... the Xp process would not have turned out as interesting or polished as it is. My guess is that many people are bringing a lot of baggage to this debate and tend towards this idealized MarxistViewOfDevelopment? that (while appealing on many levels) does not exist, or at least not for creating truly great systems. --RobertDiFalco

How about CommunalViewOfDevelopment?, rather than Marxist. Most developers have no interest in who owns and controls the means of production (except in the special sense that they, personally, would like a go ;-), the InherentContradictionsInCapitalism?, DialecticalMaterialistHistory? or the DictatorshipOfTheProletariat?. --TomAyerst

If I can intrude once again into the commune ... I think the great strength of XP in this area is in recognising that unless the whole programming team is passionate about the ConceptualIntegrity issue, they will end up subverting it, however great the "architect" is or thinks he is. This is something that we have all been victims of and perpetrators of, most likely, as books like TheInmatesAreRunningTheAsylum present pretty convincingly. I agree with a lot of your concerns or challenges for XP, Robert, but I would still prefer to remove "software architect" from the lexicon. I have seldom found that this title helps in practice. The ExceptionsProveTheRule, of course. -- RichardDrake

I would agree to finding some other term that doesn't have as much baggage as it seems to carry here. This is much like what KentBeck (or whoever) did when they created new terms like PlanningGame, UserStory, and such. XP tried to create terms that had the correct role, but wouldn't upset the uninitiated who would have brought predjudices to the existing terms. However, whatever you call it, most complex software systems will always have an architect role, usually played by one to three people. However, you have to remember that the architect role is not the most important or even the most powerful role. It also doesn't mean that many other people aren't designing their subsystems, classes, and interactions. Everyone on a project is equally important and my bet is that those who have such an abrasive reaction to the term architect are really the ones who, deep down, don't believe that. --RobertDiFalco

How about CommunalViewOfDevelopment?, rather than Marxist?

The CommunalViewOfDevelopment? is great because it allows people to collaborate and be equally important without requiring a simpleton approach like not defining roles in order to achieve that equality. Places like the Zen Center in the BayArea have very well defined roles but are still communal. An Amish community also has very well defined roles and people don't worry about whether one role is perceived as more important than another. They are all equal and important pieces of a communal puzzle. I don't understand why most XPers think that having someone in the role of architect prevents a project from being communal. Personally, I would hate to be part of a team where everyone was most interested in the architect role or where everyone was most interested with implementation. This, to me, is a major flaw in XP and I here the masses holding on to it religously than I ever have heard Ward or Kent doing. Just that the XP followers push this issue so passionately seems to point towards an intolerance for diversity. If someone is really good as an architect why shouldn't he or she be allowed to grow in that position? Wow. I find the most rewarding team experiences (whether sports, a band where we aren't all playing the same instrument, or engineering) are those where each person is good at their role and comes together to create something greater than the sum of its individual parts --- not 20 copies of the same part. There is a big difference between being communal and being marxist. MajorityRules? has never in the history of mankind produced great art or achievement. However, people have to be able to really egoless (including the architect) to make this succeed. The problem is that most programmers have HUGE ego's so the best they can do is to level the playing field so no one will feel less important. --RobertDiFalco

This is important stuff. I agree that the enemy of great communal design is ego, from top to bottom, and I definitely include the customer. We differ perhaps on the "tactics of titles" and the impact of the XP disciplines (from rigorous coding standards to PairProgramming) on the programmer ego problem. I have to admit that I've never seen team egos disappear as much they were reported to in C3 and VCaps. The egoless presentation of such effects by shy types like RonJeffries on Wiki was so convincing though! I was sad that the XP Aggression value was renamed Courage along the way but this is also an important factor to my mind for great software. If you are 100% thorough with the XP practices, does it matter if you name an "architect"? I keep an open mind. Do my questions in ExternalAndInternalDesign have any bearing on this? -- RichardDrake

Richard, yeah, I really do think those questions have a large bearing on this topic. They are hard to answer. I really imagine that I must come off so differently than I really am when I say things like great software has generally been the result of a single vision created and maintained by one or two people. Statements like this don't get across how much of a collaborative effort I think software development is. I really believe that anything a single person can think of, create, implement, and deliver is never going to be very interesting. However, this doesn't lessen my belief in the architectural role. I'm not as good as Ron at thought experiments but here's a go:

: Completely clear your head. Now, as quickly as you can, think of your personal picks of excellence. These could be software systems or languages, but don't restrict yourself. These could also include music compositions, scientific models, achievements in structural engineering, and so on. Try not to have an agenda when picking these, just come up with stuff that you feel represents great design. Okay, now go back to your list and split these into two groups: Entries whose design you attribute to one or two people and entries for which you can only think of a group to attribute their design to (not its implementation or development). What do you get? This experiment is ruined if you attempt to refactor your thoughts to match an agenda

Personally, I think you really have to be selfless in order to be an architect of any value. If you're not, you will never be able to be a part of anything greater than yourself. See the balance? Lessen your sense of self in order to create something greater than your self. You have to be ready to admit that sometimes others may do a better job of being pragmatic than you, and submit to their often superior interpretation of your ideals. Worry more about the overall flavor of things than the specifics of how they are carried out. Just as with any role, the architect's job has several state transitions. The final state, the state that indicates success, is when you leave. If the system continues to be vital after I have left, then I was successful. If it fails, then the system was never any greater than myself. --RobertDiFalco

I would like to take the references to 'Marx' out of this because it is not an appropriate term. In fact I think that the whole Marxist thing a the top is a StrawMan. The claim is that 'many people' tend towards 'this idealized MarxistViewOfDevelopment?', which seems to be an enforced uniformity of role.

I don't believe they do, many people don't see a necessity for having a one-to-one person to role relationship though. The roles can move from person to person as the project develops and people feel capable or driven to take on the various roles.

On reflection maybe that should state that they all have uniform access to the set of all roles within the project, though they may chose to use that access with varying degress of frequency. This is manifestly not true when external interfaces are included (in XP the manager role doesn't rotate, though the tracker and coach role can (at least on one project)).

In terms of designing the system it is, I suspect, almost universaly true that the high level design and conception of the system will be the product of a small number of the development team. There may be a number of interlocking, high level designs developed by different subsets of the team. Perhaps the 'architect' is the common member of all those subsets?

Whether the responsibility conception and design is then disseminated to and internalised by the rest of the team or held by the 'designer' is down to the team's values and dynamics. Personally I feel that it is more productive, but possibly more risky, for the dissemination to occur.--TomAyerst

from ChiefArchitect

It may be unpopular to say it, but I believe GreatDesign is rarely the result of MajorityRules?. -- RobertDiFalco.

See also: JustAnArchitect

CategoryCollaboration