Programmer's Weblog

Extreme programming too extreme?

Tuesday, June 9, 2009

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.

Labels:

3 comments

Comments

Blogger Ορέστης
June 9, 2009 at 8:35 PM

+1

Anonymous Anonymous
September 11, 2009 at 4:33 PM

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.

Blogger Kamil Dworakowski
September 11, 2009 at 9:37 PM

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.

leave feedback