Software Reality
Extreme Programming

Site Map

XP Central
Case Against... Songs

Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:




Extreme Programming Hits the Mainstream...

<< XP From The Trenches 1: Rich Camden

XP From the Trenches: Vanilla XP

By David Van Der Klauw
15 December, 2002

I wrote this document in January 2003 to provide feedback to my department after they forced all software developers to do eXtreme Programming in an extremely rigid fashion they called “Vanilla XP”. Vanilla XP involved rigid adherence to the 12 XP principles, seven hours of pair programming per day, no solo programming and loss of personal desks and PCs.

Criticism and abuse were rampant during the implementation of Vanilla XP. In one ridiculous incident, a team was admonished for taking too long to have coffee and thereafter banned from having coffee before 10:30am. Most of that team quit the company soon after.

It was a very strict XP regime, and this explains why I am so highly critical of it. No doubt I would be less critical of a more sensible implementation of XP.

For publishing on the Internet I have corrected a few spelling mistakes in the original submission and have substituted “CompanyXYZ” in place of the actual company name.

This document will be placed on my home page at www.ozemail.com.au/~dvdk

Introduction

I have become known as being strongly against XP. This is not correct. I strongly support the good parts of XP. It’s only the bad parts that I am against.

My perception of XP is that it has taken many sound time proven practices, taken a few unsound practices, packaged them together and excluded other sound practices. By packaging them together as a dogma XP has buttressed itself against critical analysis.

By claiming that all practices are integral and self-supporting the proponents of XP can improperly use the good principles to justify the bad, instead of allowing each principle to be judged on its independent merits.

Imagine how angry Christians would be if I took the 10 commandments from the bible, added two of my own, packaged it as a new religion, and then used the merits of the original 10 to justify my additions. Something similar, I believe, is what has happened with XP.

Another problem is that XP specifically or effectively excludes many sound practices. XP states that design and coding documentation is not necessary because these are replaced by the knowledge sharing of pair programming combined with perfect memory.

Also the effect of 100% pair programming is to exclude the many benefits that come from solo programming, such as that certain kind of learning that only comes from discovering and trying out something by yourself.

I have decided to put together a criticism of XP in writing.

This is not meant to be a balanced view of XP. It is purely critical. I acknowledge that XP includes many sound practices, and also that XP might work very well on some projects.

Another issue is the definition of XP. The XP that I will discuss is the CompanyXYZ “Vanilla XP”, the rigid following of the 12 XP practices.

Following is my view of the flaws of XP after experiencing it for six months at CompanyXYZ.

The Major Flaws of XP

XP Flaw 1 – Packaged Dogma

XP can be described as 12 practices that must be followed closely.

Some obvious questions arise:

A) Is it a good idea to replace commonsense and judgement with close adherence to 12 practices?
B) If so, are the 12 XP principles the best possible 12 practices to follow?

To put the questions another way:

A) Should you follow a Dogma?
B) Is XP the best Dogma?

Question A - should you follow a Dogma?
No. I believe that it is a great idea to try to follow several time-tested basic principles as a guide, tempered by experience, judgement and practicalities. Rigidly adhering to a dogma is not the way to success in a complex and changing field such as software engineering.

Question B - Is XP the best Dogma?
I don't believe that XP is the best dogma available.

Imagine you had a friend who was going off to run his own software company. He asks you to give him 12 practices to follow in order to be a success. Would you give him the 12 XP practices?

I think not. I would suggest something like this:

1) Know your market
2) Hire the best people available
3) Motivate your people
4) Keep the customer happy
5) Manage risk
6) Plan ahead, short-term and long-term
7) Maintain balance - don't overemphasis any one aspect of software development
8) Use incremental development
9) Use recent hardware and technology but avoid the latest
10) Keep studying and learning
11) Learn from your mistakes
12) Make rules but trust the judgement of your people to break the rules when needed

I spent just ten minutes thinking of these rules, even so I am sure that they are a better guide to success than the XP practices.

Imagine there was a competition where developers submitted their best 12 practices for software development. All entries were given a score by an expert panel of judges. How well would XP score? My feeling is that XP would not score very highly at all when compared to other available practices.

The point I am trying to make is that XP should not be selected just because one or more of its principles have some merit. That is not good enough. XP should only be selected if you decide to follow a 12-practice dogma, and if those 12 XP practices are the best 12 available.

My impression of XP is that it is a way of allowing software to be written by people who are not really good enough to be writing software. By following these simple rules, novices can avoid disaster and get the job finished. For novices a 12-practice dogma like XP might be just what is needed to get them over the line. However for experienced professional developers I believe that a dogma and “one size fits all” philosophy is a major mistake.


XP Flaw 2 – Extremes are stupid

I believe that a major flaw in XP is that it takes things to an extreme. I believe in doing things in moderation, and trying to optimise the value by trading-off one factor against another. In life I find that rarely is the optimum achieved at some extreme point.

From the preface of “Extreme Programming Explained”:


XP takes commonsense principles and practices to extreme levels.

> If code reviews are good, we’ll review code all the time (pair programming)
> If testing is good, everybody will test all the time
> If design is good, we’ll make it part of everybody’s daily business
> If simplicity is good …
> If architecture is important, everybody will work defining and refining the architecture all of the time

… I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn all the knobs up to 10 …


Hello! Does anybody have a sound system at home? Can you tell me how good it sounds when you turn all the knobs to their maximum?

> If it is good to eat at lunch time, then let’s eat all of the time
> If pay rises are good then let’s have a pay rise every month
> If cleaning toilets is important then we’ll make it part of everybody’s daily business

Example – extreme simplicity
There is a lot of sense in doing things more simply. Einstein said “we should make all things as simple as possible, but no simpler”. However, let us use the example of taking simplicity to an extreme in order to show how taking something to an extreme narrows its range of applicability.

Here goes:
Many software developers make things more complex than necessary. If I advise that developers should write slightly more simple code then I’d probably be right in 99% of cases. Further, if I advise that developers should write moderately more simple code then I’d probably still be right in 90% of cases. However if I advise that developers should always write code that is extremely simple code then my advice would only be correct in very few cases.

The more extreme I become, the more I narrow the fit of my advice. It is a matter of statistics and bell curves and all that.

If the cap don’t fit …
The result of combining several practices to extreme levels is that XP will only fit very rare situations.

The book says “XP is a light-weight methodology for small-to-medium sized teams developing software in the face of vague or rapidly changing requirements”. That is a very narrow focus. This is precisely the point I am making. Extreme practices make for an extremely limited range of suitability. And I am not convinced that much of the work done by CompanyXYZ product development fits within this narrow range. Last time I looked CompanyXYZ was a large team programming for well known largely unchanging requirements. Why are we doing XP?


XP Flaw 3 – Short Time Frame

XP concentrates on the extremely short time frame to the exclusion of other timeframes.
XP says that programmers tend to waste time planning for a future which may never occur. The XP solution is to not plan ahead at all. In my opinion this is a serious fault, and a case of throwing out the baby with the bathwater.

Spending within a business hinges around payback periods. Whether the spending is dollars or time, the decision to spend or not should always be done on its payback period. A common payback period to use within business is 2 to 3 years.

The short time frame of XP makes the serious error of eliminating many fruitful tasks that would pay themselves back in a few short months or years.

I don’t deny that most software development work should payback in days or weeks. However the flaw I am highlighting is that XP excludes valuable tasks with a medium or long payback period.

One symptom of the short time frame is that CompanyXYZ is neglecting all learning exercises in favour of completing immediate customer tasks. Many CompanyXYZ programmers feel that their skills are being used up and not replenished. Like a foolish farmer who eats his breeding stock or his seed corn, CompanyXYZ is not allowing its programmers to take time to learn anything that does not have an immediate payoff to a customer.

In business there are many techniques that will give a short-term boost to productivity but with long-term damage. These techniques are often pushed by consultants or managers who can come in, quickly show a short-term gain, cash out, and then leave the problems behind for someone else. I believe that XP is one of these quick fix fads.

The short term emphasis leads to less quality of coding. There are many altruistic reasons for writing quality code, but one benefit of the conventional code ownership is that it forces you to write quality code so that you won’t be stuck with a mess in a few months or years time. With conventional code ownership if you failed to plan ahead, they would get you back to fix it. With XP however, any problems down the track are not your problem. Therefore less care and less quality results.


XP Flaw 4 – Estimation and Spikes

Estimating the time a job will take is one of the most difficult aspects of software engineering. XP attempts to solve this problem by demanding accurate estimates for routine work, and requiring investigative “spikes” for tasks that cannot be accurately estimated. I believe that this is a serious flaw in XP.

Estimating software is so hard to do because, unless you are a complete idiot, every job involves something you have never done before. After all, if you have done it before, a copy and paste from your archive will only take seconds.

XP pretends that work can be conveniently divided into routine work that can easily be accurately estimated (but yet too hard for a single person to do by themselves) and groundbreaking work that will always require an investigative spike, then throw away code, then estimate, write tests, then perform the task. If only life was so simple.

Perhaps your car’s accelerator could be replaced with two speed buttons – one speed for highway cruising, and one speed for local roads.

In reality there is a full spectrum of routine/experimental work that is experienced throughout just about every task; just as your car experiences a range of speed on every journey.

Eg. as I code a FOR LOOP it might be 100% routine, I use a familiar API function but in a new way 50% experimental / 50 routine, then I try to cast the return to an unfamiliar type and it is 100% experimental.

The distinction between spikes and production code is not a useful distinction. The two are heavily entwined and cannot be separated.

I am not saying that there is no value in making an estimate and re-evaluating when the time is up. Estimating is worthwhile but will never be accurate. Trying to make it so with the worthless distinction of a spike is futile.

I am not saying that there is no place for dedicated spikes, nor that work is never 100% routine. What I am saying is that a great deal of work cannot sensibly be divided into the categories of experimental or routine because it is a mix of both. Forcing this distinction is a flaw in XP.

XP Flaw 5 – Collective Ownership – No Specialists

I believe that a serious flaw of XP when used on large projects is the lack of specialisation.

According to XP it is too dangerous to have people specialising on one area of your software because a truck accident could kill a small number of them and thereby do great damage to your team.

XP involves collective ownership where everybody is equally allowed to work on any area of the software, and you therefore have a high “truck count”, meaning a truck accident would have to kill a high number of people in your team in order to remove any knowledge from the team.

(Working under XP with collective ownership makes each developer a “jack of all trades – master of none”.)

I have no doubt that collective ownership works well on small projects of short duration, however it is bound to fail on large projects of long duration.

Take the example of ProductXYZ, which involves interfacing with hardware like PLC’s, communicating via TCP, has a graphics designer and realtime display, database backend, etc.

It is clear that in order to be a world-class product CompanyXYZ needs to have experts in the area of:

1) Hardware interfacing
2) Network communication
3) Realtime software, multi-threading
4) Graphics
5) Databases

(To say nothing about testing, builds, installations, release management, source control, project management, PC network administration, etc)

Now it is well and good to hope to find people who are expert in all five areas, but in reality this can’t be done. By banning specialisation and forcing your people to work on all areas, you are spreading your team too thin. You are removing the deep expertise that is necessary to make a world-class software product.

My suggestion is to not embrace the collective ownership of XP blindly. Do your own risk analysis on the level of specialisation in your team.

Is there really a risk that a truck accident will kill half your team? Or is there a greater risk that people will leave the company if they are forced to work on areas that don’t interest them?

Some areas may be highly specialist but not that hard to learn. In these cases you might have one expert and one person with some knowledge ready to rapidly fill the shoes should the expert leave. An example might be installation writing.
Other areas might be so critical that you need several experts.

Other areas might be so simple and basic that all people can and should know them.

In a cricket team it would be nice to have 11 top class all-rounders, but in reality a typical team might have one all-rounder, 3 specialist bowlers, one wicket keeper, and 6 specialist batsmen, one who can bowl and one who can wicket keep at a pinch. This is the same degree of specialisation I would expect in a software team.

There are two approaches here to getting the depth and breadth of knowledge. (Depth being how much is known on one area, breadth being how many areas are known). With collective ownership you firstly ensure full breadth of knowledge and then try to achieve depth if possible. (Which you can’t on a large project) The other approach is to firstly achieve the depth of knowledge you need and then try to increase breadth. This is the approach I recommend for CompanyXYZ.


XP Flaw 5 – Pair Programming

I believe that overuse of pair programming is a major flaw in XP.

Before I make comment on pair programming (pairing) I want to make the point that it is a complex issue, not a Boolean variable to be decided YES or NO, RIGHT or WRONG.

Pairing is a lot like marriage in the type of questions and answers that arise. Imagine the reaction I would get if I made a few general comments about the benefits of marriage and then insisted that every person should be married and that CompanyXYZ only employ married people. There would be outrage.

Yet this is exactly how the complex issue of pairing is approached by many people.

Learning by pairing
Remember a lesson at school or university. The teacher gives a general introduction of the topic, then works one or two examples on the board then sets you some problems to attempt by yourself. You consult the board and/or your textbook then attempt the questions. Should you have trouble, the teacher is there to help.

Imagine how silly it would be if instead of all this the teacher just sat beside you and you both commenced working on the problems together. Whenever your writing slowed, the teacher told you what to write and when you were confused the teacher took your book and completed the problem instead of letting you think it through and work it out yourself.

This is exactly what we do with our pairing.

To me, the worst aspect of pairing is that it prevents me from stopping, investigating and learning, at my own pace when the need arises. When I am pairing I have the responsibility not to waste the time of, or bore my partner, as I investigate something. As a result I will often skip the opportunity of learning or investigating. Pairing raises the cost of learning and wastes many opportunities for investigation and improvement of my skills and the product.

Let them eat cake
Is pairing better than working alone?

It is better in the same way that cake is better than bread, wine is better than water and meat is better than vegetables. It is better in the right circumstances, but it is definitely not better for all circumstances.

How much meat do we need?
I tried to find an analogy to show how much pairing we should do. The best I could find is meat vs. vegetables.
Vegetarians eat only vegetables and do not eat meat. Without debating that topic let’s agree that while it is possible to get everything our body needs from vegetables, it is difficult. Most vegetarians will freely admit this.

Therefore a lazy vegetarian who neglects to monitor their diet would be better eating some meat.

I have made a graph showing the health of such a lazy vegetarian as they replace vegetables with meat.

Diminishing returns of eating meat


The “high gain” area is where the meat is providing the vital trace elements, iron and protein that the body was previously deprived of.

The “cost exceeds diminishing return” area is where the high percentage of meat increases the amount of fat and free radicals while not providing any further health benefit.

The “disastrous exclusion area” is where the 100% meat diet causes severe problems due to the total absence of certain vitamins and fibre that come only from vegetables.

The pairing graph
Now I have made a graph showing the productivity of programmers who replace solitary programming with pairing.

Diminishing returns of pair programming

The “high gain” area is where the programmers pick up those vital tips and knowledge that can only be learned from watching another programmer in action. As a solitary programming they were deprived of these.

The “cost exceeds diminishing return” area is where the high percentage of pairing increases the time taken, frustration, etc, while not providing any further benefit to the tasks.

The “disastrous exclusion” area is where the 100% pairing causes severe problems due to the total absence of certain learning and experience that comes only from solitary programming and study.

How much pairing would I recommend?
I would recommend that the pairing level be adjusted to its optimum. How so? Well I don’t have a crystal ball to tell me the perfect levels so I would suggest a method that can be used:

Regularly ask the programmers if they want more or less pairing. Adjust the level a little bit at a time by majority vote, until half want more and half want less. Once this point is reached you consider whether the pairing level can be further adjusted on an individual person and/or task basis.

Two minds are better than one
Two minds are better than one. But then again a chain is only as strong as its weakest link, a train is only as fast as its slowest carriage, and too many cooks spoil the broth. Which adage applies to pairing?

No one will argue that in many situations two minds are better than one.

Therefore all CompanyXYZ programming should be done in pairs if we make a few further assumptions:

> Putting two people in front of one computer automatically makes their minds work together effectively
> CompanyXYZ is happy to pay twice as much to get the better result
> Programmers enjoy pairing and will not leave CompanyXYZ for an alternative arrangement

Justify the cost?
When the value of pairing is questioned, its supporters will often point out one case in which a partner was helpful. They use this as proof that all coding should be done in pairs.

This is a classic case of the “one size fits all” flaw. I have paired now for more than six months, I’ve had times where the partner taught me stuff, helped increase speed, found bugs I missed, I’ve had a few good chats and have had great fun on some days. That’s not good enough.

It is necessary to do a proper cost benefit analysis of the practice of pairing.
For something to be justified it is not good enough to find one benefit. Benefits must exceed costs and there must be no better alternative.

Don’t ask:
Can a partner ever be of any value?

Do ask:
Is a partner of sufficient value to justify the cost?
Does the partner cause additional problems?

To pay off pair programming must deliver the average task in half the time it would take a solitary programmer to deliver the task to the same quality. My experience indicates that this order of speed increase is not occurring. In fact I think many tasks take much longer.

XP proponents will come back with two arguments:

A) Sometimes the quality is higher than is achievable by a singleton
B) Occasionally the pair will rapidly solve a problem which a solitary programmer would be stuck on

Rather than dispute these claims, I will concentrate on the impact of the far more frequent occurrence where the pair does not get the task done faster, and in effect takes twice the man hours on the job.

When investing money a sobering fact is that to break even after a loss, the percentage gain needed is greater than the percentage loss taken. For example a 10% loss needs 11% gain, a 20% loss needs a 25% gain to take you back to even, and a 50% loss needs a 100% gain. It turns out that these mathematics apply to XP’s pairing with equally alarming results.

Consider the case where a pair is normally taking one hour to do tasks on which a singleton takes two hours. In this case, pairing is as effective as singletons (singleton being a solo programmer).

Now consider should the pair fail to work faster on just one task and instead takes the full two hours. In this case to catch up they would have to work at twice their normal rate for the next two tasks. That’s right, after taking as long as a singleton on just one task, they would need to work at four times the speed of the singleton for the next two tasks just to catch up.
You do the maths if you don’t believe me.

I believe that in the real world a pair will often take as long as a single programmer to do a task. They may occasionally work faster, quality may even be higher, they may avoid getting stuck occasionally. But on balance, the frequent slowness will overwhelm these benefits as the mathematics shows.

Three’s a crowd?
If two minds are better than one, are three minds better than two? If it makes sense to place two people on one computer then why not turn up the volume, take it to an extreme, and place three or four people on the one computer?

Don’t laugh off this question; it is a very important question. The defence of pairing relies on certain hard to prove claims about better quality, knowledge sharing and collaboration. All of these claims support tripling and quading in addition to pairing.

When I asked the XP expert, Dr Neil Roodyn, he told me that any more than two people results in slower communication and decision making because there is more than one channel of communication. I find this answer to be unconvincing. Surely the fastest communication and decision making occurs within the brain of a solitary programmer.

When it comes to programming I think two is a crowd.

Labourer or Artist
In my analysis of pairing I thought about all kinds of work where people worked as a pair.
Police and airline pilots pair for safety and backup. Labourers pair for greater lifting power.

Creative professions do not pair. Remember too many cooks spoil the broth. Can you imagine two painters creating a masterpiece by taking turns with the brush?

Most professions do not pair simply because the cost is not justified. Bus drivers, taxi drivers, bank tellers, judges, teachers, and 99% of all workers do the job with the smallest unit that can do the job – one person.

Is a programming job more like the jobs that justify pairing, or more like the jobs that don’t justify pairing?
I think programming is more like the jobs that do not justify pairing or do not suit pairing.

Pairing replaces documentation
A tenet of XP is that documentation (such as design diagrams and detailed comments in the code) is unnecessary because since everyone works on all of the code, chances are one member of the pair will have worked on any piece of code and will therefore understand it without documentation.

I believe that this lack of documentation is a serious flaw of XP which will affect all except the smallest teams on the shortest projects. The fact is that everyone does not work on all of the code. If you’ve got 8 in a team – 4 pairs, you get to see ¼ of the code as it is written. Sure you will modify some code and debug through some more, but I think it is fair to say, that if the code is well written and works, each team member will never see much of the code. If the project continues over the years, people will leave and new people will join, and the situation gets worse.
Even if you have written the code yourself, it does not mean you remember it. I have had to relearn code I wrote months or years before.

My experience suggests that some basic documentation is necessary and pairing in no way reduces the need for documentation of code and design.

The quality contradiction
XP has a contradiction regarding how it achieves quality.

On one hand it uses exhaustive testing to guarantee quality. XP states that you should write tests first and write the minimum code needed to pass the tests. If all the test pass, then by definition the product works.

One the other hand, XP claims that programmers must pair in order to write code of appropriate quality.

The obvious question: If the testing guarantees quality then why do you need the pairing for quality?

Who likes pairing?
Forced 100% pairing is like a forced marriage. It might work out but it would surely be better if it was voluntary and stood on its own merits.

Ideally the forced pair would be ideal at pairing and would work ideally together. In the real world however, things are a bit different. I have made a few generalisations and have placed them in italics. These are not absolute truth, but are generally true.

When pairing a bossy and quiet person, the bossy person will tend to dominate the quiet person. It is likely the quiet person will dislike pairing, whereas the bossy person will like the extra power they have.
Bossy people like pairing, quiet people do not.

When pairing an expert with a novice, the novice will tend to slow the expert and the expert will tend to teach the novice. The novice will probably enjoy this whilst the expert may not.
Novices like pairing, experts do not.

When pairing a high achiever with a low achiever, the high achiever will get less done and will no longer be able to take credit for the high achievement. The low achiever however will get more done, and will be able to take partial credit for the work, as well as avoid the criticism and responsibility for his previous poor results.
Low achievers like pairing, high achievers do not.

Whilst my statements are only generalisations if correct they would tend to suggest that if 100% forced pairing was brought into a company quiet high-achieving experts would dislike pairing and leave the company, whilst bossy low-achieving novices would like pairing and stay.

I have not written this section in order to insult any particular person, or to infer characteristics to someone who likes pairing. I write it simply to be thought provoking.

Stick to the task
XP claims that when programming alone, programmers tend to take experimental detours rather than sticking strictly to the task. XP claims this is a serious problem and “solves” this by pair programming, with strict estimation and tracking of time taken.

I have something very important to say about this. I believe that the experimental detours are good. They are vital learning that most programmers need. Think about it, why do so many programmers do it? It is because it comes naturally. Do programmers naturally do a stupid thing, or do they naturally do a sensible thing?

When is the best time to investigate something that you don’t understand fully? When you come across a task that might benefit from it, when the task is right there fresh in your mind.

Under XP you should make a note of the possible spike, complete your task, then discuss the possible spike with your team, write it up on the board as a spike, and then do it. If something good comes from it, you discuss it with the team and customer and then write a test for it, and then include it in the production code (working as a pair of course)

Is it any wonder that these investigations never get done? What happens if you just have a nagging thought that a really useful function or object lies just around the corner – how do you explain that to the team and get permission to do it?

Now that I have suggested that experimental detours are good I know what the XP proponents will argue. They will ask how do you stop a programmer from spending all of the time on useless detours. Self discipline and commonsense is the answer.
If you’ve just spent ½ a day on an unfruitful detour then it makes sense to stick strictly to your tasks for the next day or two so that you have something to show for your effort.

An unproductive programmer, whether due to detours or otherwise, will be obvious from the lack of output in the long run. Similarly the high productivity of a creative detour-taking programmer will also be obvious in the long run, even if the odd day is wasted on a detour.

XP Flaw 6 – Aspects of Testing

Software testing is an art and a science in itself. Software is sometimes easy to write, but is often hard to test and impossible to prove. What to do?

XP solves the problem of testing by simply insisting the everything be tested and with a test written before the code. If only life was so simple.

Whilst acknowledging that testing is very important and something that CompanyXYZ has neglected, I believe that XP oversimplifies the difficulty of testing and misallocates testing resources.

Whilst test-first coding is an interesting concept, I believe that the reality is different to the XP theory. My experience is that many things that can be test-first coded are so simple that a test is unnecessary. On the other hand, many things of moderate or greater complexity cannot be test-first coded. Only after the coding is finished is it possible to envisage the tests. I am not hard line about this, and may change my opinion over time.

As to degree of testing I think XP makes the dangerous simplification of applying the same degree of testing to all areas. My concept of bug finding is something like this:

A programmer should find 9/10 bugs before checkin, the automatic tests should find 9/10 remain bugs before handover to QA, and QA should find 9/10 remaining bugs to customers who find 9/10 and 1/10 remains undiscovered. Therefore the customer only sees 1 in 1000 bugs.

My belief is that this is good enough quality. Sure it would be nice if the customer saw zero bugs, but are they prepared to wait years longer or pay twice as much for this level of quality? – probably not.

I understand that some people have gone overboard with the tests that they write. Tests have been written for some things (like constructors) that can never fail. Some testing of module internals has been so detailed and extensive that it greatly increases the cost of ever changing the internals of the modules in the future. This is not agile programming.

Rather than obsess about XP’s testing simplifications I would suggest to instead do a lot of thinking about how best to test. Spend a reasonable percentage of total time on testing, and test as much as possible for the given time and resources. When a customer finds a problem, add new tests so that no customer will ever see that problem again.
Test what the customer sees first. As those tests fail add more detailed internal tests to pick up faults that are actually occurring.

Conclusion

XP has some serious problems when applied badly, or to unsuitable projects.

The main problem with XP is the way a dogma is used to replace judgement and commonsense and excludes valuable practices.

The worst practice of XP is the overuse of pair programming. The worst aspect of this is not the pair programming itself, but the loss of the benefits of solo programming such as learning. Pair programming is also expensive and no proper cost benefit analysis seems to have been made.

The second worst practice of XP is collective ownership with the lack of specialisation that goes with it.

Other problems such as the short time frame, division of routine and experimental, strict estimation and testing have been discussed.

The common theme is the disempowerment of the programmer that occurs under XP:

> Loss of the ability to use judgement - replaced by rule following
> Loss of individual decision making power - replaced by pair decisions
> Loss of code ownership and area of expertise
> Loss of freedom and privacy
> Loss of ability to experiment, learn and invest for future

Moving Forward

My suggested actions for CompanyXYZ would be:

> Stop following the XP rules blindly, and instead use commonsense and judgement. Preferably replace the term XP with something that reflects ownership of the methodology
> Reduce pair programming in favour of learning activities and solo programming where judgement dictates. Perhaps 4 hrs of solo programming per day per person would be a good starting point
> Require expertise first and breadth of knowledge (collective ownership) last. All code must be worked on either by an expert, or with an expert, or be reviewed by an expert (an expert in the areas covered)
> Replace test-first coding and 100% testing, with sensible testing
> Provide whatever is necessary to bring back pride of workmanship
> Provide whatever is necessary to make the programmers happy. People are individuals. Find out what motivates each one

 


Why not leave a message on the Software Reality XP Forum?

<< Back to XP Central

<< Back to Lifecycle

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.