Extreme Payoff

Just a comment on what I've been reading here lately: For a long while now, I've noticed that people program (and projects run) in two basically different ways: One I term locally better and the other globally better. Locally better decisions make things go faster in the short run (eg writing all these test cases will take me forever!), while globally better decisions do the opposite (writing all these test cases will save us countless hours a few months down the road). Unless you have lots of experience, it's very hard to even identify which things you are doing will save you time in the long run (I'm a LazyProgrammer); this is especially difficult in a team, because some things are worse for you individually, but much better for the project overall.

Does this mesh with what you guys are saying? --AnthonyLander

Partly yes, partly no. For example, XP doesn't invest in building for the future (see e.g. YouArentGonnaNeedIt), relying instead on the combination of tests and refactoring to evolve the system to where it really needs to go. We hold that the tests help us to go faster now, and that refactoring helps us go faster overall.

I would like to say that XP takes the long view of the project, but that it doesn't invest a lot now in hope of return later. --RonJeffries

Absolutely no. The trick is to do activities that all have short term payoff, so they all make sense even under stress, but whose emergent properties give good long term results. Writing all those test cases makes me go faster at the end of an hour. Of course, there are lots of combinations of short-term-payoff activities that crash and burn. --KentBeck (feeling absolutist)

Kent, when you are acting like a methodologist, you are thinking about the long term. When you are acting like a coach, you are thinking long term. It is only when you are in the heat of programming that you just think short term. That is part of the magic of ExtremeProgramming; you've designed it so that programmers can just worry about the short term and be confident that the long term will work out. This is powerful because programmers tend to worry mostly about the short term anyway, so this way they can do what they are good at and not get into trouble later. --RalphJohnson

I didn't mean to say that all short-term decisions are bad -- though on rereading what I wrote, I suppose that I did (oops). The testing example is not quite good either. Variable naming and code formatting are better: Each programmer would be happy in the short term to do things his or her own way, but clearly there are (rapidly) diminishing returns as the code size increases.

...But it's an interesting question: Is programming a greedy process (ie do lots of good short-term decisions make for long-term benefits?) --AnthonyLander

With my Computer Scientist hat on, I can "prove" that problems exist such that you can't climb the hill. With my Real Life hat on, and it's a very old and experienced hat, I don't run into many real situations that can't be resolved quite effectively with good short-term decisions. I can't even remember the last time.

In real projects, I think good short-term decisions, refactoring, and addressing risk early result in perfectly satisfactory implementations. --RonJeffries

I can remember quite a few short-term oriented decisions that were bad. I can remember quite a few short-term decisions that propagated erroneous datastructures to the point where fixing them required effort - and annoyed clients and management. Why, isn't win32 the some of such decisions? (Though, since it is successful, that argument might go either way).

And if SOME short-term decisions really ARE bad, all Xp really say "make good decisions and you will succeed" - thanks. Or maybe there's more.

I'll admit that many long-term decisions were bad. Indeed, the point that long term decision are more likely to bad simply because it's harder think long-term is WELL taken. Maybe, it's matter of being shamelessly greedy when you can be greedy.

I think the schizophrenia of wiki is making me go two different ways. Enjoy.

--Joe Solbrig

I think this concept of being locked into a solution isn't addressed by XP as much as it should be. If I create a database schema and release it to my customers -- then there now exists a certain inertia to stay with this schema. If the next release takes a 1:1 relationship and makes it 1:M, then I have to write a program that updates the db schema , and any reports the client has designed against my version1 schema will break.

--TomJohnson

What you mean is that with the right value system, making good short term decisions leads to good long term results. The problem is getting the right value system.

This is true outside the realm of programming, too. I think that is the purpose of a value system. We need to figure out the way to live so that when we are the middle of life we "do the right thing". When our neighbor comes over to argue with us, we are not going to start thinking about how this will affect our life ten years from now, but we react according to the way we were taught, and the way we taught ourselves. The time for reflection is when things are quiet, and that is when we should decide to be peaceful or to stand up for our rights.

ExtremeProgramming teaches that flexibility is crucial, that you have to preserve flexibility now. Keeping your system flexible means that you can add features quickly now, which has good short term results, but it also means that you can almost certainly respond to changes in the distant future. But it takes a lot of education to learn how to keep systems flexible, and how to refactor them to make them that way. Just like it takes a lot of education to make a child learn to do the right thing. Some people figure it out on their own, but most learn from their parents. In the same way, a few programmers will figure ExtremeProgramming out on their own, but most will learn it from someone else. Probably because they were forced into it!

-RalphJohnson

Nicely put, Ralph. Me 'at's off to da duke! --RonJeffries

Ralph, your statement that started with "This is true outside the realm of programming, too" up there is simply beautiful. ThankYou. --AnthonyLander

One very attractive feature of ExtremeProgramming is that it tries to ride, instead of quelling, the deepest of urges in any true programmer, namely the urge to hack. This makes XP true to its parts, the programmers, and gives it some of The QualityWithoutaName --AndersChrigstrom

I like Ralph's conclusions, but I'm not sure that "ExtremeProgramming teaches that flexibility is crucial". It seems to me that tenets like "do the simplest thing that could possibly work" don't seem likely to deliver particularly flexible software. In fact, ExtremeProgramming as I understand it says that a comprehensive test suite is a good thing because it lowers the risks in aggressive restructuring. If that's true, then the value of flexible software is actually reduced. ExtremeProgramming teaches that flexibility is futile: the ability to rewrite is crucial. Is this a fair outsider's view? I'm not sure I like it as a philosophy. --DaveCleal

We've left you with a misunderstanding, Dave. In fact, XP produces very flexible software, and it's not an accident. Recall that the DoTheSimplestThingThatCouldPossiblyWork practice has two parts: first, pick and implement a simple approach to the solution; second, refactor the system so that it is the simplest possible implementation (OnceAndOnlyOnce) of the simple approach. It is the refactoring that leaves the system flexible.

It is true that XP builds a system without unused potentially useful code. It is not true that it builds a system that's inflexible, i.e. hard to modify. Good factoring results in flexibility. --RonJeffries

One of the soft benefits that we observed on my most recent project was a flattening of the stress curve. In a throw-it-over-the-wall development scenario the curve is sinusoidal, with peaks at the end of development and during testing. XP's iterative and collaborative approach flattens the curve so that the stress is spread out over the entire release. --DaveRooney