High Discipline Methodology
High Discipline MethodologyWhen all the gears have to work right to move the machine forward.
I consider XP a HighDisciplineMethodology, one in which the people will actually fall away from the practices if they don't have some particular mechanism in place to keep them practicing. Ron is that mechanism at the moment. Should (when) Ron leave, then unless he is replaced in his role, I quite expect to see the team not following the practices properly in less than 6 months.
The other high discipline methodology I know is WattsHumphrey's PersonalSoftwareProcess. It requires people to do a lot of accounting of their time and the defects they turn up. Rumor reaches me that it has been shown to be very effective, if you can get the people to continually practice the practices. -- AlistairCockburn
Summary moved from the bottom to the top of this page... I believe we have come to an agreement. While I feel HighDisciplineMethodology is too strong a statement I can accept the statement XP requires discipline. -- DonWells
I'm cool with that. My current feeling is that it requires a little more than is natural to give when the stress gets on. That means you need some checks and balances to bring stuff to your attention. Regular meetings to talk about "how we're doing" might be sufficient. -- r
Assume that the C3 people are good developers. Why then would they need a "revival" meeting? Answer: because XP requires that people work in a particular and consistent manner in order to get the declared benefits. Doing anything on a consistent basis is quite difficult for us humans. To keep the consistency going, the methodology includes a mechanism for just that purpose - the Coach (see ExtremeProgrammingRoles?). The presence of the coach does not mean the developers are incapable, any more than the presence of the Coordinator role or the Tester role. It means that KentBeck and RonJeffries recognized the value of having someone around with the assigned duty of keeping the XP practices in practice. So the revival meeting is part of the proper mechanism of the methodology doing its proper thing - resetting the practices to the necessary high level. -- AlistairCockburn
Alistair, please tell us about LowDisciplineMethodology and whether they can work. Thanks! -- RonJeffries
LowDisciplineMethodology is what every project I have visited, with the possible exception of C3, has used, and what has been used by most groups that have shipped software (as well as by many groups that have not shipped software). It is just the norm. Discipline is one of the failure modes of humans. The way I usually break a declared methodology is to look for the discipline areas, then ask people if they do that part. They usually say, "no". So they don't actually use the methodology. They really just do whatever they feel like, with a few practices thrown in occasionally. Typically, the project leader or process owner is unaware of how the people circumvent whatever the declared practices are.
Ah yes, the CiderHouseRules.
My goal is to create a space for medium-disciplined people to work, a HighToleranceMethodology. If I were to write a DonKnuth or Gries or WattsHumphrey style book on programming, it would be The Laissez-Faire of Programming. Not a really catchy title, eh? However, my best current guess at capturing a HighToleranceMethodology is in the CrystalClearMethodology. The CrystalOrangeMethodology? is sketched in my SurvivingObjectOrientedProjects book.
Do they work? Well, to the extent the people are skilled and cooperate, yes. To the extent they aren't and don't, no. To get a more consistent result you have to add training and collaboration-setting and disciplined practices and a mechanism to keep the practices consistently in use. -- AlistairCockburn
As for ChryslerComprehensiveCompensation falling apart if Ron leaves. I am offended. I know the people on that project. They have all worked hard to learn XP, practice XP, and as a team refine XP. One person can not force a project to become extreme. It must be a team growing together from mutual experience and new understanding. The mechanism to hold XP in place is XP itself. Anyone who has worked on an ExtremeProgramming project does not want to go back. We all want to be more productive and have fun at work. As people leave C3 they take XP with them and impose it on the projects they move to...not the other way around. -- DonWells
Don is right to have confidence in the C3 folks, whom he knows. However, as I mentioned elsewhere, we have recently found it necessary to have a revival meeting to recommit to our beliefs, because we had strayed fairly far from them. I'm quite concerned - the whole team is - about what let us get off track so far with no alarms going off. And in this case, I was actually here. So much for the theory that I'm indispensable.
I offer no answer, and certainly don't claim to be one. Alistair raises an important point: teams can, and do, go off-process, even such a simple and visibly pleasant process as XP. Suggested solutions would be very welcome. -- RonJeffries
I am surprised that anyone can get offended at my assertion that XP is a HighDisciplineMethodology. I did not and do not mean at all that "C3 will fall apart if Ron leaves." I think I wrote, "unless he is replaced in his role, I quite expect to see the team not following the practices properly in less than 6 months." You have my apologies if the writing gives the impression that C3 people are faulty - exactly the opposite is intended. Please reread my paragraph and see if you find my intended meaning. See also HighDisciplineMethodology. -- AlistairCockburn
I believe I see your meaning and yet still take offense at the implication that my colleagues on the C3 project are in some way lazy and lack discipline. Perhaps you could go back and rephrase in a positive way. Then delete my reference to being offended. -- DonWells
As for going off process I suggest "Doctor it hurts when...". When C3 was first evolving the process we had specific meetings to address process. Do those still occur? Here at the VcapsProject we still have those meetings devoted to nothing but process. We ask the questions: Is it still working? What can be better? Is there anything we can steal from C3? If it hurts when you assume the process is working just fine and ignore it then don't. Schedule regular revitalization meetings to avoid going off process (and serve ice cream to boost attendance).
Let's HearWhatYouSay for a moment. I believe what Alistair has asserted is that XP requires a coach. Perhaps we should examine that assertion as it stands. -- DonWells
What I have asserted is that any high-discipline methodology (XP, for instance) needs a discipline-enhancing mechanism. A coach is one possible one, and an effective one. Why do tennis players have coaches? Because they are lazy and undisciplined? Well, I am content to assert that not just your colleagues on the C3 project are in some way lazy and lack discipline, but that everybody is in some way lazy and lacks discipline... with the possible exception of WattsHumphrey, who, I understand, keeps process accounting while balancing his checkbook. Alternatively stated, people are less lazy and more disciplined with a coach around. Swimmers and runners have coaches, for no other reason than that the coach asking them to do something again and again is more effective than them thinking to do it again and again. It is appropriate to expect similar results with programmers.
Alistair, WattsHumphrey actually agrees with you on this ... it's a key reason he created the TeamSoftwareProcess and the TspLaunchCoach role: to provide the coaching and support for PersonalSoftwareProcess. -- KarenSmiley
I am also willing to guess that, as what sounds like the process agitator on Vcaps, you are the coach or discipline-enhancing mechanism. How long do you think the people on your project would continue to have those process-checking meetings if you left? Would someone step in and be the process-improvement champion the group relies on? -- AlistairCockburn
I'm not asserting that I'm special (though I am), but I do share some of Alistair's concerns.
XP ''is', as Alistair suggests, a HighDisciplineMethodology, and we, as humans, seem to be able to stare each other in the face and say what we believe while doing the opposite. The C3 team are great people, but they are not at all immune to falling away, even with their vaunted "coach" right there.
I'm troubled and concerned by this. I very much share Alistair's concern about what would happen were there to be no one dumb enough to be the champion. More on this later and elsewhere. I'll put a pointer here: FallingFromGrace. -- RonJeffries
Our experience with XP has been different. If everyone on a project keeps an eye on the process and methodology, and equally shares ownership of the team's process, then you don't go astray. On our project, we went from no XP practices to almost a complete set. We evolved to XP because we as a team were able to see the benefit and internalize the process, step-by-step. We used the C3 project as an example and starting point, but never forced anyone to adopt a practice out of the blue. We always discussed what our methodology would be and how it would be changed. Everyone agreed and took responsibility to be a guardian of the flame. This was able to occur only after the team members experimented with XP practices, not because someone (DonWells) simply told us it was a good thing to do, and it worked for other projects (C3). We (especially the experienced Smalltalkers) had to witness it first-hand and for ourselves. Otherwise, XP would have been embodied in only one individual "coach".
In contrast, a team who has a Coach whose sole responsibility is to guide the process, runs the risk of having to "sell" people on why they should be doing XP. Selling people on an idea doesn't really work. People have to believe in the idea for themselves, otherwise they don't really have firm conviction. The process has to be owned by the group, just as in CollectiveCodeOwnership. As in any good team (practicing XP or not) each member plays different roles and wears various hats at different times so that the group is well-balanced. The leadership roles, therefore, should not be the responsibility of someone designated to be the coach. They are the responsibility of every team member, and at some point in time, each person is responsible to step up and exhibit the leadership behaviors Ron mentions above. In our case, if we relied on only Don to be the gatekeeper, we would fail (or fall astray) with him or without him. (Which sounds like what Ron has seen with the C3 team)
I assert that it is not so much that people need a refresher on the practices of XP, but they need to look at how they are functioning as a team.Is there a team synergy? Are people committed to the process? If someone leaves, can the team still live on? (To me, the answers to these questions are of interest. They could indicate source problems in the team's foundation.)
As a member of an XP team, we should each look at our own actions (or lack of) and be an XP-champion when our team needs us to be, instead of waiting for someone else (designated or not) to do it.Perhaps this is the human laziness factor that Alistair is referring to. Perhaps it is easier for humans to rely on someone else, rather than taking ownership and responsibility themselves. -- JeanineDeGuzman
Jeanine ...
I value your ideas, as I'm trying to grok what has been going on here.
Certainly, as you suggest, the team's performance is the result of what the team does. C3 is not a team, however, where the practices have been, or are, imposed. On the contrary, it's very much a buy-in situation. Yet still we went off-track, and still we didn't notice until we bonked our heads.
I'm also much in accord that one has to look at team function and synergy (whatever those are) to get a handle on what goes wrong in some of these situations. The situations are complex, and happening only about once a year it's hard to build a pattern. (See FallingFromGrace.) It remains troubling.
The VcapsProject only started going extreme about 18 months ago. It'll be interesting to watch and see what happens, whether and how it stumbles, how stumbles are detected, how corrected. Please report experience as you have it. -- RonJeffries
Regarding the phrase, If it hurts when you assume the process is working just fine and ignore it, then don't. Here is the interesting thing. It doesn't hurt when you go off process.For a while, at least, it feels fine. (Kind of like not having to floss your teeth every night. Doesn't hurt. But the dentist bill is higher next year.)Perhaps you at the VcapsProject have a chance to embed the practices in the culture. I look forward to finding out in a couple of years' time. -- AlistairCockburn
Alistair - I'm having trouble grokking CrystalClearMethodology as medium discipline with its 20 required deliverables. Please say more. -- r
See HighToleranceMethodology. -- Alistair
I'm having trouble seeing XP as a HighDisciplineMethodology, especially in light of this comment from the XP pages:
A developer's nature is to develop code, not to develop documentation. The best process is one that works with nature, not against it. (Tree-hugger theory of software development.)
Granted, this is referring to only one small part of XP, but for the most part it seems to me that XP tries to work with nature. My point being: XP might require a lot of little disciplines, but they're easy disciplines (compared to other methodologies, at least). So it might be low-tolerance, but it doesn't seem that it requires huge amounts of discipline. --GlennVanderburg
How about if I amend that to read, "A developer's nature is to develop code, alone, without unit tests, thinking up neat things along the way, and not documenting. The best process is one that works with nature, not against it. (Tree-hugger theory of software development)."
I am generally a defender of XP, but I defend it while asserting that it requires discipline. Developers being told the practices LOVE not having to write documentation, but they HATE having to write UnitTests, and having to create an architecture that is amenable to regression tests, and many of them are allergic to letting anyone else see their code. And they LOVE putting neat little goodies into the design. So those are the high-discipline parts. I would expect to see an XP project, after a period of time, get casual about PairProgramming, UnitTests and RefactorMercilessly first, and YAGNI somewhere in there (Oh I'll just put this in, it'll help later.)- Alistair
Oh, I understand and agree that it takes discipline. My quarrel is with saying that it takes a lot of discipline (which is what you say when you call it a HighDisciplineMethodology, is it not?). I think that term has to be relative, and by comparison with other methodologies I'm familiar with, XP seems to be very low on the discipline requirement. It does try to work with a programmer's nature.
Additionally, while there are some practices in XP that require discipline, I think there are counterbalancing practices that reinforce the discipline. That XP projects have stumbled doesn't seem important to me in the least. Projects are going to stumble; that's a part of a complex, dynamic process like this (reread DrivingMetaphor, think about the fact that all drivers occasionally drift, and recall how much more complicated building software actually is). What matters is whether XP projects drift away from the practices never to return. This has happened, either officially or unofficially, on every project I've ever been a part of (at least, on the ones that claimed to have any methodology at all). Large parts of the process were widely considered to be pointless and counterproductive, and most of the developers conspired to ignore them. That's a characteristic of a genuinely high-discipline methodology--one with practices that you have to follow just because the process says to. -- Glenn
Alistair, I apologize. I believe I now see what the original misunderstanding is about. You and Ron both find XP to require super human discipline to maintain. I myself find XP to require very modest discipline requirements. So when you say someone does not have enough discipline for XP you may mean that person is normal, but from my point of view, where XP requires a person to be nothing more than normal, you have just insulted that person. I hope you can come to understand this also.
It should be noted that I do not initiate the process checks and/or meetings. We all gather together whenever anyone notices a problem happening. I myself am the least disciplined person on this team by a good margin. I myself shun authority, Ron will verify this, and I have gotten myself into trouble on many occasions because of my insistence on teamwork. I'm the coach here? You have got to be kidding. -- DonWells
I did not and do not say that XP requires "super human discipline". I do say that it requires discipline. I observe the fact that the C3 team, who we agree are good, intelligent, thoughtful people, have fallen away from one or more practices a number of times. I don't fully understand what's going on, but I'm certain that doing your unit tests, always doing CRC sessions instead of leaping into coding, and such are not fully natural behaviors. Programmers with N years experience the other way seem to have a tendency to revert under stress. That sounds like a failure of discipline to me. -- rj
Let's talk more about XP requiring high discipline. I assert that it does not. I will grant that, to an outsider, it does seem to be an awful load of baggage to carry. But I believe that when you have used it for a while you come to realize that it is in fact very lightweight and the simplest thing that could possibly work. After someone experiences it, then it seems like CommonSense.
The first meeting I was in where ExtremeProgramming was suggested, I thought it required an extreme (no pun intended) amount of overhead, rigor, discipline. I didn't see the value or the power in it. UnitTests seemed too overwhelming and extra work. I figured an Excel spreadsheet would work just fine to manually verify results. Someone else wrote two unit tests for the sole purpose of guarding existing functionality. Finally, I had to go back and change that part of the system. It was then that I realized 1) how much faster the work got done, 2) how much easier it was to get it right, and 3) how little effort was actually required for UnitTests. AHA! I saw the error of my ways and proceeded to add about 60 additional UnitTests.
I think this is a good example of someone internalizing XP, and then having XP permeate the team's culture. XP practices have been spreading from developer to developer. If high discipline were required, we would expect it to have died out by now. After all, why would people choose to do something that is rigid and painful? Alistair asserts that people will always tend towards the lowest discipline. XP just seems like CommonSense to me now. -- JeanineDeGuzman
My view of XP seems very different than Ron's. My view of XP at C3 is frozen in time, just as XP was being born. When I left, making changes to the process was an important part of XP itself. I still retain that viewpoint. I see that Ron considers that first RefactoringIteration, when we all had to stop and refactor like crazy to be a stumble (FallingFromGrace). I consider it to be a perfectly reasonable thing to do as part of the XP process.
While it is true we have only become extreme in the last 18 months, let us note that C3's first RefactoringIteration occurred within the first 9 months. And for the record, VcapsProject has already stumbled while being extreme. But instead of considering it a failure or falling away from XP, we have embraced our problems and made it a part of our method. When we realized that a very important piece of the VcapsProject was way over-engineered, we talked about it for some time knowing that it needed to be refactored. But the code worked just fine. But we knew we would not be happy with it in the long run. So, the very first opportunity we had, we had an ExtremeProgrammingCodeReviews and put a pair on it for an entire iteration. A RefactoringIteration was the only reasonable thing for us to do, and it should be part of XP if it is not already. -- DonWells
Call it what you will, if you stumble, you stumble. If you stumble for more than a few days and don't notice it, something is wrong. We stumbled, finally noticed it, met for two straight days, continue to work on the details of how we should adjust the process. We found a number of things we had been working around, and some of them will take some time to fix. A willingness to face that there are problems and adjust to them is key to any success IMO, and particularly key in a lightweight methodology where dropping any practice can cause a serious drop in performance. -- RonJeffries
Well, I thought C3 was a pretty unusual project when I visited it, but C3 sounds mundane compared with Vcaps. The key factor you people seem to have internalized is find and fix failing ideas. cheers - Alistair
Isn't that exactly why C3 had their revival meeting, to figure out what was going wrong and fix it?
Correct as usual Ron. You did not say super. I believe we have come to an agreement. While I feel HighDisciplineMethodology is too strong a statement I can accept the statement XP requires discipline. -- DonWells
I'm cool with that. My current feeling is that it requires a little more than is natural to give when the stress gets on. That means you need some checks and balances to bring stuff to your attention. Regular meetings to talk about "how we're doing" might be sufficient. I'd like to see some mechanically-captured metrics as well, but that might not be Extreme. ;-> -- r
restarting the question of whether XP is a HighDisciplineMethodology....
...not announcing the intended responsibility, you make it a little harder for the next programmer to get going on the process. The responsibility statement is never spoken aloud. The programmers must do the full cycle to get the full benefit. ... But then, that's why XP is a HighDisciplineMethodology, and why you need to adhere to all of it (and why it is so fast when followed). -- AlistairCockburn
I thought we had agreed, after hearing testimonials from XP practitioners, that XP does not require unusual levels of discipline? -- DonWells
You agreed, I didn't and don't. -- Alistair.
Correct you are Alistair, you did not agree. RonJeffries, who worked on the C3 XP project, JeanineDeGuzman, who worked on the VCAPS almost XP project, and myself from C3 and VCAPS did come to an agreement. Perhaps we could come to an understanding if you tell us which of the XP projects you worked on and which of the practices you found hard to keep up with? -- DonWells
Ron has regularly agreed with me that XP is a HighDisciplineMethodology, in public. That leaves you and Jeanine. I think that if you two find it completely natural, then you are in great shape and I congratulate you. I think I could make a career following Kent (or any other high-discipline methodologist) around, cleaning up the pieces after people try to install XP (or whichever) and don't make it. So far, we have you and Jeanine who think XP is completely natural, and a much larger sampling of people who have tried XP practices and found them hard to follow. Just read around on wiki. I have spoken with another half-dozen who have similar experiences. The specific practices that are hard to follow are: PairProgramming, test-cases first, YouArentGonnaNeedIt, RefactorMercilessly, and 100% unit tests in an automated regression test harness.
Note once again that "hard to follow" does not mean "bad" or "not useful". It simply means "hard to follow". -- AlistairCockburn
Alistair- you know what takes "high discipline"? Knowing exactly what you want to do, but filling out 10 pages of use case documentation- prose, object model, interaction diagram- instead of just writing a test and making it run. That takes real discipline.
In the above I think you are confusing "hard to adopt" and "hard to follow". Adopting testing, refactoring, pairing, and simplicity are all certainly difficult, even though the practices are intellectually simple. Following them once adopted is not hard, even though everyone slips from time to time. --KentBeck
Good point (as usual), Kent. I'll try to ground my thoughts again. I started off at the top with the prediction, "unless [the coach] is replaced in his role, I quite expect to see the team not following the practices properly in less than 6 months." I think that is a fair test of a HighDisciplineMethodology.
There are high-discipline tactics that are ineffective, such as the project in which the people were told that after every single change, they had to go and update every single piece of documentation (or get fired). That project lasted around 6 months before it melted down. There are high-discipline tactics that seem to be effective, such as program derivation, CleanRoom, PSP, XP.
Where I got to in my thinking, and still am, was my observation that most software teams are really (astonishingly) sloppy in their habits. And yet, software has been coming out for 40 years. So what is there to do? One route is to get them to adopt better habits and, ergo, have a higher / faster delivery rate. The route I'm testing is to permit them to be their usual slapdash selves as much as possible, and try to detect the minimum discipline they need to get the software out. (I usually find the minimum I think is necessary is more than they are willing to do.)
In the meantime, I'll work on the "hard to adopt" vs. "hard to maintain" issue. Thanks -- AlistairCockburn
Alistair, I agree with Kent that the practices are relatively hard to adopt (though not nearly as hard as use cases) - I face lots of resistance to pair programming, unit tests and especially YAGNI. I'd go a little further, however. I think the practices, once established, are not only easy to follow but I have evidence that they are addictive. Here's one of several examples I've seen: after delivering TariffSystem, one of the programmers was dragged onto a high-pressure project which had just suffered two out of its three programmers resigning, and the remaining programmer was very junior. He was expected to pull it out of the hole and deliver it. Not only did he stick to the practices we had established, and did it under unreasonable pressure and lack of a "coach", I'd even say he increased the rigor with which he applied them. -- RobMee
Some C3 XP developers sometimes fall away from good practice. They do not hold as many CRC sessions as would be most effective, they do not ask for help when it would speed them up to do so, they test less effectively than they know how to do, and so on.
One might quarrel with the specific words "High Discipline", but it is true that some developers do reduce their use of some practices sometimes - even when it's pointed out to them. Maybe it is time pressure that causes them to do this, but I don't really know.
P.S. I'm no longer on C3 full time. Alistair's six-month clock has started. -- RonJeffries
Ron, you forgot to date-stamp that statement!! 6/25/99)
As it turns out I myself am one of those undisciplined (astonishingly) sloppy developers we have been talking about. Ron and Kent know me and will vouch for this. So you wonder how is it that I am able to follow the ExtremeProgramming rules? Well, I don't always. Sometimes I create a whole bunch of UnitTests all at one time! Sometimes I do a SpikeSolution and then add UnitTests and refactor it instead of throwing it away! Sometimes I get carried away and add extra stuff that has to be taken out later!
But!
I never release code with out UnitTests. I never let the UnitTests run at less than 100%. I always pair with someone. I take great pride in my ability to refactor out stuff that isn't needed or is hard to understand. I forgive myself and my teammates in advance for the mistakes we will make. I rely on my team to help me fix my mistakes. I make my knowledge and meager abilities available to the team so that they might rely on me to help them fix their mistakes. Together we make our chosen methodology work with out accusations, recriminations, or stress. We create quality software very rapidly and have a good time doing it.
XP is both a LowDisciplineMethodology and a HighToleranceMethodology because the practices are simple and easy to follow and you do not need to be perfect to be very productive. Working XP style is so much fun and so effective the rules fade away and just seem like the natural way to do things. -- DonWells
Good for you, Don. I know what you are saying about yourself is true.
However, I have observed these things, and others, on an ongoing Extreme Project:
But in my sincere and respectful opinion, you and Kent are closing your eyes to a fact: good and true people have fallen away from the practices. Since it has happened, surely they will do so again. Keeping on track with XP requires discipline, just the same as keeping in shape, keeping your weight down, or keeping your dancing up to snuff. Denial won't change the facts. Maybe something else, perhaps some measurements, could. -- RonJeffries
All very interesting, and so the test is running. I love trying out predictions, because then we learn something whether they come out right or wrong! In particular, if RobMee and DonWells are right that the practices are addictive, then my worries about the discipline issue will drop away, and we return to the merely-difficult adoption issue.
On high-discipline methodologies in general. If XP is a HDM, then we would expect to see it contain a way to refresh adherence to the practices. That's what we saw with Ron as coach. We have seen Ron refer to "refreshing the practices" and "revival meetings". This is appropriate. Kent's initial response to my 1998 comment about XP being a HDM was also appropriate - he immediately looked for ways to keep the practices in place.
So my next prediction from the model of people and methodologies: if a high-discipline methodology does not contain a practice-refreshing ritual or practice, then it needs such or people will fall away from the practices.
If DonWells is right, and XP is not a HDM, then it does not need such. I think it needs such. I suspect we'll learn the answer to this over time. -- AlistairCockburn
I feel sure that there has to be a refreshing practice. The group can, in my opinion, serve this function for itself, in a mutually-supporting way, just as substance-addicted folks help each other stay clean. My efforts with the team, when I encounter them, will be to remind them that they have to do it for themselves. I know that some of them are stepping up to the problem already. I do not believe that all XP teams will fall away without a coach - but I do believe members of any team will fall away without some supporting mechanism to note when they are going off and bring them back. -- RonJeffries
We had meetings at VCAPS to check the process and practices. Fixing problems with the methodology is an included part of XP. TheyreJustRules. And you know, it just isn't all that tough to get people together to talk, they actually seem to want to do it! If breaking the rules causes trouble the team will notice and call a meeting to talk about it and fix the problem.
But does the existence of a stabilizing practice mean it is high discipline? I think not. It just means: batteries included. -- DonWells
At the risk of creating a major tangent here... It sounds to me like this topic is working around the edge of a question which is easier to ask in an engineering framework.
The quote (from the top of this page) "a HighDisciplineMethodology, one in which the people will actually fall away from the practices if they don't have some particular mechanism in place to keep them practicing." reminds me of the distinction between systems which are open loop stable ones which are not. If we want systems (teams) which do not require an outside controller to continue to operate, open loop stability is our target.
However, I think it is wise to consider the possibility that open loop stability may not be the appropriate target for a system as complex as a development team. Perhaps we should set our target a little lower. DonWells seems to be arguing that XP does not require a large amount of effort to control (i.e. that the system is "controllable" with mere mortals at the wheel). This, rather than open loop stability, is usually the minimum standard for an acceptable mechanical system.
To make this a little more concrete (I hope), most of us can ride a bicycle but, without rider input, most bicycles are not open loop stable. Eventually the bike will fall unless someone takes effort to control it. During my undergraduate work, I had a professor who had "invented" an unridable bike. The thing was not only not open loop stable, it was not even controllable (assuming the best controller you had was a person). Many of the Methodologies I have seen seem to create systems (teams) which are not controllable in the sense that a "mere mortal" can never get a handle on enough of the variables to keep the thing from crashing.
I suspect (having never had the pleasure of working on an XP project) that XP works because it is very near the open loop stable region and it exposes enough critical metrics to allow a person to control it effectively.
Surely someone who remembers their control systems stuff (or game theory perhaps?) better than I do could make this much clearer (hint, hint).
Finally, (as everyone breaths a sigh of relief) I wonder if RonJeffries has considered applying the XP principals recursively to the XP Methodology? It seems that, perhaps by coincidence, many of the rules have been used at the meta-level (YAGNI, DoTheSimplestThingThatCouldPossiblyWork, etc.) but others (PairProgramming for example) are barely visible, at least from the outside.
Just some food for thought.
-- JeffShelby
I take the road that VeryMildXpOkay. There are some good "tips" in XP, but being forced down your throat like an enema from a hell-nurse is another matter.
6/25/99 - "I'm no longer on C3 full time. Alistair's six-month clock has started. -- RonJeffries 6/25/99"
12/25/99 - "For the record: As of 12/25/99, 6 months after the C3 coach had left, the C3 team was still following all of the XP practices."
2/1/2000 - "As of the first of February, 2000, the C3 project has been terminated without a successful launch of the next phase."
That last entry is misleading. From a conversation with RonJeffries, the cancellation of C3 was political and not related to the team's discipline or lack thereof. See also CthreeProjectTerminated -- JimLittle
See also: TechniqueWithManyPrerequisites
EditText of this page
(last edited May 6, 2013)
or FindPage with title or text search