Green eggs and ham

XP offers total risk management, providing the lowest exposure to risk that is currently possible in software development. So, my question to you, New Zealand, is why aren't you all doing it? What, precisely, is the problem?

Extreme programming (XP) has been used successfully for hundreds of projects. It’s the process of choice for Chrysler, it has been used in investment banking firm Goldman Sachs and it has been employed by many other large and small organisations all over the world. It has even been used here in New Zealand, with success, and there has been interest from some of the country's leading companies.

XP offers total risk management, providing the lowest exposure to risk that is currently possible in software development. It also offers higher quality, often producing software with few, if any, discernable defects. All of this is achieved with low staff turnover, for no extra cost. And, the final product is much closer to what the customer intended than is possible with any other way of developing software.

So, my question to you, New Zealand, is why aren’t you all doing it? What, precisely, is the problem?

Really, I’m not joking, I want to understand. Please email me your responses to these questions and we’ll see if we can clear things up a little for you. I can, and will, guess as to the reasons, but we’ll all benefit from some hard data, so please, tell me why you aren’t doing it?

My first guess as to your answers is that you "think" XP can’t work, or that it can’t provide the benefits described above. Ron Jeffries, one of the "three extremos" (the people who invented XP), once asked: “There is speculation and experimentation. Which is more likely to lead to a correct conclusion?”

So if you are speculating that XP won’t work, why not try it and find out? In a lot of cases it would take a great deal of hard work to produce something disastrous. Remember Green Eggs and Ham by Dr Seuss: “You don’t like it, so you say, try it, try it and you may, try it and you may, I say.” We teach this to our children, and then forget it in professional life.

My second guess is that you don’t know enough about it to start a project using it. Well, there are a few good consultants in New Zealand who are experienced XPers, myself included; help is available.

So inexperience isn’t a "good enough" excuse.

My third guess is that you think that XP won’t fit in your organisation for political reasons. My response to this is that if you’re letting politics interfere with doing a good job, then your living in Dilbert, and I’m sorry for you. Again though, you are speculating about the effects of XP, and about the mind-sets of the people around you.

Experimentation is better than speculation in that it works, so if you try XP you may find interesting effects.

So politics isn’t a "good enough" excuse (although it comes close).

My final guess is that you’re just looking at the size of the change it will entail, and throwing your hands up in despair. To these people I can suggest that you bring in help, not just for XP, but also for your organisation. Change is necessary, always, and it is going to happen. It's up to you to decide if the changes are going to be controlled, or uncontrolled. If you try XP, then you are controlling a change, for the better. If you don’t try XP, then change will happen, it will be out of control, and may not be for the better.

So fear of change isn’t a "good enough" excuse.

I have one last comment that may help you in your decision to try XP or not. XP produces high-quality software considerably faster than any other method. We usually have our first release one or two weeks into the project.

There are two companies, A and B (you’re working for B). They’re both developing similar products. Both products are for the same market. A uses XP, B uses something else. A rough estimate would put both projects at about three months' work.

After three weeks A can go to market with a working, high quality, cut-down product. This product is now eating market share, and probably generating revenue, and market feedback. Company B is just completing the requirements-gathering phase.

A week later company A releases a second version of the product, built upon the first. This one again offers high quality but has added features. This is again released to the market, generating more feedback, more revenue and more market share. Company B has now had the requirements signed off, and is working on the architecture. Design is continuing apace, but it will be another week or two before they can begin coding.

Another week passes, a third release for A, five weeks into the project. The market is going wild. Company B cancels the project, because there is no way they will be able to compete in two months' time, when the entire market will be focused on A’s product and its constant enhancement.

Of course, not all of us are in this sort of commercial situation, are we?

Dollery is a Wellington-based IT consultant. His website is here. Send email to Bryan Dollery. Send letters for publication in Computerworld to Computerworld Letters.

Join the newsletter!

Error: Please check your email address.

Tags extreme programming

More about Goldman

Show Comments