Chief Architect Of Xp

It's pretty clear who the ChiefArchitect of XP is. That doesn't mean that many people don't participate and refactor the design, but all of them are not the architect. I would say that it is very clear that KentBeck maintains the ConceptualIntegrity of XP much as AlanKay or AdeleGoldberg acted as the ChiefArchitects of Smalltalk in order to maintain its ConceptualIntegrity. -- RobertDiFalco

For the record, Kent is trying very hard not to be the chief architect of XP, it is our fault if he is still perceived as such. -- DonWells

This is an odd assertion.

Why? Do you think he is doing a bad job or does he no longer have enough time? Whether he is trying to be or not to be it is too late. XP has already been architected. Now, the original vision can only be refactored, improved, or hurt. Chances are, without a some small group working as the Xp architect (or architects) its ConceptualIntegrity will be lost and XP will be reduced to the lowest common denominator by democratic compromises. This is always a difficult trick when the architect gives something up to democratic rule just as BjarneStroustrup did with C++. -- RobertDiFalco

There are many things in XP that came not from Kent but from the C3 team itself. There is one thing in XP that came from the VCAPS team as well. If you read through his next book you will notice many new ideas coming from other people. Those of us who attended XP2000 will have noticed that Kent did not present nor sit on a panel discussion. MicheleMarchesi told us in his opening remarks that Kent wanted the conference to be about XP and the people involved with it and not about KentBeck. I have heard him say many things about wanting people to pick up XP, experiment with it, and add to it. I sincerely believe he wants XP to be open. If it is not open than it is our fault for not accepting his challenge. -- DonWells

There are many things in XP that came not from Kent but from the C3 team itself. There is one thing in XP that came from the VCAPS team as well.

Sure, but honestly, adding things is not the same as architecting something. In fact, it is just because that there was an architectural infrastructure in place that allowed it to be built on. [Kent has said that XP is an attempt to formalise something that WardCunningham does naturally :-)] That it remained strong afterwards is just a testament to the fact that the architectural foundation of XP was strong. What's wrong with that? An architecture is like genetically engineering a seed and then planting it -- it happens once for that particular seed. Then, after the basic system has been architected, everyone comes along and refactors, adds, and prunes the basic architecture as it grows. All the while, the architect continues to exert influence on these additions and attempts to keep the ConceptualIntegrity of the original idea. Sometimes he/she will be in favor of the idea but argue that it should be named differently. Even changing the name of an addition is a way of maintaining ConceptualIntegrity. This is a good thing. Why are people so emotionally and violently against it? -- RobertDiFalco

MicheleMarchesi told us in his opening remarks that Kent wanted the conference to be about XP and the people involved with it and not about KentBeck.

Of course, if there was a Smalltalk conference how would you feel if it was about AlanKay instead of Smalltalk. I'm not sure how this relates but to further show that XP came from the vision of one or two single minds. That's what architects do, they create something and the unleash it to the world. It's a very cool thing. To me, architectural success is when I release something and watch it grow into something good that I never imagined. To see it be used in ways I did not have the ability to visualize. -- RobertDiFalco

Robert, I greatly appreciate you raising AlanKay and DanIngalls and the issue of conceptual integrity. There is so much to learn from this relationship, even now, so many years after Dan implemented the first Smalltalk SpikeSolution - using Basic everyone!. One problem for me above is that the analogy

is far from the most interesting (even though it is interesting). AlanKay has seldom been called the architect of Smalltalk, for one thing - and what people should be called is one part of what this is about. Much more important to understanding the cultural issues and influences on XP for me though is this remarkable testimony from Kay in EarlyHistoryOfSmalltalk:

By the end of 1975 I felt that we were losing our balance ... In January 1976 I took the whole group to Pajaro Dunes for three-day offsite to bring up the issues and try to reset the compass. It was called "Let's Burn Our Disk Packs". There were no shouting matches: the group liked (I would go so far to say: loved) each other too much for that. But we were troubled ... One thing we all agreed on was that the current Smalltalk's power did not match our various levels of aspiration. I thought we needed something different ... [others] really wanted a better Smalltalk ... I think Dan felt that a better Smalltalk could be the vehicle for the different system I wanted, but could not describe clearly. The meeting was not a disaster, and we went back to PARC still friends and colleagues, but the absolute cohesiveness of the first four years never re-jelled. I started designing a new small machine and language ... and Dan started to design Smalltalk-76.

Kay was the leader, he was a leader, just as DanIngalls was, he was just one part of a great team that loved each other. You choose. If you ever read this, Alan, thanks for the writing this paragraph and history of Smalltalk.

No, the analogies I've wanted to explore for while now are:

Again, the parallels are not exact. But love remains the key.

-- RichardDrake

Richard, I don't disagree with this at all. Actually, I was never sure who had the seed of the idea for Smalltalk, or who was the idealist and who was the pragmatist. I just assumed it was Kay who had an idea that was turned into something real by Ingalls. I suppose this was an incorrect assumption. FWIW, I think you see that sort of interaction (between designers and makers) and successful projects.

I've always found some of the best design teams to be initially compose of two to three people -- usually just two. Invariably, one tend towards the ideas and major abstractions but doesn't do well sticking with one long enough to materialize it while the other(s) excel at making these ideas real. The team binding material is not just love and respect of each other but a common faith and belief each member has for their ideas and metaphors -- specifically the pragmatist for the idealist who usually does not get such attention from pragmatists. This sort of common faith is uncommon but when it happens --- when pragmatist and idealist bond on a common vision, really magical things happen.

I think there is a religious fervor aspect to good ideas, TeamGel?, and product/project momentum. Of course, religious fervor can cut both ways and hurt a project by making its creators blind to its flaws. FWIW, GuyKawasaki talks about this religious aspect of software in RulesForRevolutionaries. --RobertDiFalco

I'll post some thoughts on this next week, Robert, if you're still watching. -- rd

My experience of XP was that it was not so much architected as evolved. Kent had many, many good ideas. Some of them remained intact when they hit the cold hard reality of the C3 team, others had to change, and some didn't survive. XP did not spring forth from a box that Kent was hoarding it in. Kent, Ron, and the C3 team struggled for about the first 5 months before things popped into place. -- DonWells

Very interesting and also true of the Kay/Ingalls/LearningResearchGroup? experience with Smalltalk. "Popped" is a key word of course if you accept the fish tank analogy in the NonlinearityOfXp.

XP did not spring forth from a box that Kent was hoarding it in.

Of course not, no system every springs forth complete from its architect(s). Why would you think it would or why would you think that I thought it did? I've gone over all of this before, but let me put it down again here altogether for posterity. Also, I don't feel comfortable talking about XP or the roles of KentBeck or even WardCunningham because I wasn't involved with it. However, this is the topic so I will use it as a case.

While I have never met nor talked with KentBeck, much less about the evolution of XP, my guess would be that while the whole team (including Kent) worked on evolving the concept of a light-weight process with a particular flavor and focus, Kent worked to maintain the ConceptualIntegrity of all the various incoming ideas --- on maintaining the flavor and focus of the incoming ideas. No one has told me this or even hinted at it, but this is how it usually works. I imagine that XP was refactored and maybe even rediscovered when it was put into real-world use (i.e. when the team starting eating its own dog food). However, I have a very hard time believing that there was no seed of an idea, not particular flavor or feeling of XP until C3 came along to collectively create the process with no leader and only MajorityRules?. To me, in addition to presenting an original system style, ethic, metaphor, or foundation that this is what an architect does. I find it odd that so many seem to think that being an architect means you are some dictator or chosen one that spits out an entire system whole and then direct everyone at your every whim. Every good idea needs repeated design, implementation, and refactoring and constant architecting (which is why you don't get rid of the architect after she/he conveys her/his idea).

So, in my view, the role of the SystemArchitect is not just to rally effort around a single purpose but to maintain consistent system metaphors, repelling additions the dillute the strength of the metaphors, and keep the number of metaphors to smallest number possible. In other words, to keep the system as small and consistent as is possible. At a certain point a SystemArchitect must let go of the system all together and no longer contribute or massage ideas but to instead facilitate others to take over. The architect becomes successful when the system takes on a life of its own -- when he/she can turn away from it (somewhat) confidently.

I want to say that while I don't know WardAndKent and while I have some issues with XP... from what I have observed WardAndKent epitomize my ideal of what an architect should aspire towards. They've done such a good job that people don't even want to call them architects!! In my view, XP and Wiki are perfect examples of a successful systems that were well architected. I don't know why many people here seem to think of system architect as some megalomaniac who creates everything himself and takes credit for everything. However, I don't think any good architect would ever desire that.

-- RobertDiFalco

See also GreatDesign

EditText of this page (last edited July 9, 2010) or FindPage with title or text search