Tuesday, June 9, 2009

Extreme programming too extreme?

Is extreme programming as a methodology over? Has Kent Beck killed it himself? Until now he insisted that you not write a single line of code without a failing test. He was talking about his daughter who allegedly can not even imagine writing code without tests first (in his book about test driven development)!

Extreme programming is a set of good practices but the problem is the emphasis on taking them to the extreme thus ignoring the cost/benefit ratio. There is an obvious trade-off here.

It would be optimal if people wrote just the right amount of tests, not too little and not too much, to maximise the ROI. That of course is very hard to judge, but for sure the answer is not 100% coverage in all cases, as Kent kindly observes in his post.

Extreme programming is flawed as a methodology, but I want to argue that it is good for learning the craft.

People have natural inclinations for not testing, not integrating continuously but programming a feature for days not syncing with the main code base, underestimating features and than putting in long hours, etc. Extreme programming is like a correction program for these unwholesome inclinations. :)

Aristotle noted in the Nicomachean Ethics that the best way to reach the golden mean is to aim at the opposite extreme.

In the dimension of testing, for example, people will naturally tend to write too little tests, usually none. Practising extreme programming forces us to go to other extreme: from none tests to 100% coverage no matter the cost. This teaches that you can write tests you didn't previously realized, but more importantly it changes the mindset of the programmer. After practising extreme programming you will find yourself uncomfortable without the safety net of tests, and while you will not necessarily want 100% coverage you will be in a much better position to judge how much testing is really needed.

I am glad that I was a part of an extreme programming team for almost 2 years now. We might have been too extreme, but too extreme in the good direction. 4:1 ratio of tests to code that we have might be an overkill, but it is certainly better than no tests at all. I feel similarly about other practices.


Ορέστης said...


Anonymous said...

One of my gripes about extreme programming, it leaves little to design. Testing and coding are good, but there should be equal emphasis on Design as there is for testing.

In my opinion, a good ratio is 40-20-40, that is 40% towards design, 20% towards coding, and 40% towards testing.

Of course this depends on the type of projects you are on; smaller projects design are less important so are probably more suited towards extreme programming. Medium - large projects are more suited towards other development processes.

Kamil Dworakowski said...

XP as such does not appear to be putting much emphasis on design. Though people promoting xp would protest. The refactoring is to adjust the design to the growing code base.

A project will have a number of constraints, which all have to be addressed, design is the structuring that meets these constraints. The assumption is that as the project grows it takes more and more constraints, some of which may be contradictory, and the design needs to be adjusted. Here comes refactoring.