Cedric Still Doesn’t Get Agile
Update: Martin Fowler pointed to . It seems Cedric did not give us the full picture. I have edited my post accordingly
After attending a less than stellar presentation on TDD, Cedric Beust confuses TDD with “Agile” and goes on to tell the world that agile is not good. Let’s have a look, shall we?
First of all, tests are not specs. Not even close. Somebody in the audience was quick to give a counter-example to this absurd claim by using a numeric example (’how do you specify an exponentiation function with a test?’)
I would not use unit tests for specs. Automatic acceptance tests on the other hand is really nice if you have a customer/product owner that will work with you. Now Cedric has previously stated that he does not really care for the labelling of tests (“However, when I write a test, I don’t really care if it’s a unit test or a functional test”) so that of course makes it harder for him.
And hey, testing an exponentiation function? How about providing test data with given parameters and answers? It would be a prime candidate for a FIT-test by the way.
Relying on tests as a design specification is lazy and unprofessional because you are only testing a very small portion of the solution space of your application (and of course, your tests can have bugs).
Why would you only test “a very small portion of the solution space of your application”?
Tests also fall extremely short of having the expressiveness needed to articulate the subtle shades that a real specification need to cover to be effective.
This is my main gripe with Cedrics rant. He seems to be completely oblivious to the great emphasis on customer interaction that agile methods make, which promotes a two way dialogue.
A specification written in a document is a one way communication. Even in high school psychology I learned how much more information was conveyed in a spoken dialogue than in writing.
This claim is part of a broader and more disturbing general Agilist attitude that is usually articulated like ‘Your code is your spec’, along with some of its ridiculous corollaries such as ‘Documentation gets out of date, code never does’.
What is so ridiculous with the last statement? I have never been involved in a large scale project where the documentation did not get out date.
As for the code being your spec: when you have code and documentation, and the latter does not correctly describe the former, it is out of date, which will you trust? And what do you read to know what the real world looks like? Map, meet terrain.
I am currently getting acquainted with a brand new project that is not even very big, and while I understand Java fairly well, there is no doubt in my mind that for ten minutes I spend trying to understand how a certain part of the application works, a five-line comment would have given me this knowledge in ten seconds.
Sure, if it is up to date, which you will have to read the code to find out. My general rule: if you feel the need, comment on why the code does what it does if it is not obvious. If you feel the need to comment on what the code does, the code is not clear enough. Refactor until done.
Very often, Agilists simply forget that their job is to produce software that satisfies customers, not software that meets some golden software engineering scale.
Again, this is simply ridiculous - all agile methods try to get customers as close as possible to produce just what they want. Anyone even remotely knowledgeable with agile methods knows that.
Frankly, it takes all of ten minutes to explain Test-Driven Development to a developer who’s never heard of it: ‘Write a test that fails and doesn’t compile. Make it compile. Then make it pass. Repeat’.
I actually find it quite hard to get developers to grasp TDD; people find testing something that does not exist confusing. This is of course the basis for behavior driven development, but let’s just be happy for Cedric now.
Some might find it picky, but leaving out ‘refactor’ in the TDD loop tells me that you somehow has not grasped the concept completely. But then Cedric might throw in a comment instead :).
‘What should we test now?’
‘How about: if we pop an empty stack, we get an exception’
This is quite easy to test, so I do not see why he could not add it. Read Jeffs answer
Stack s = new Stack(); try { s.pop(); fail("Should not get here"); } catch (Exception e){ //Ignore }
But I am dead sure Cedric knows this , too bad the presenter did not.
To be honest, I am becoming quite suspicious of Agile practices for that reason: all the presentations I have attended and books that I have read are always using toy implementations as examples. Stack, List, Money, Bowling… enough already!
Ignoring the fact that Cedric again confuses TDD and agile, he does have a point. Too many TDD presentations uses examples that are way too simplistic. They should point out the need of a modular architecture, and the fact that using TDD actually helps you get a clean, high cohesion - low coupling architecture.
And please, avoid smug and useless answers such as:
‘A lot of the classes I have to test are hard to isolate, do you have any advice regarding mocks?’
‘Well, if you had started with TDD in the first place, you wouldn’t be having this problem today’.
It is certainly not a helpful answer, but it is true nonetheless.
Fundamentally, I am disturbed by the Agilists’ dishonesty when it comes to presenting their arguments. They offer you all these nice ideas such as Test-Driven Development and Pair Programming but they never — ever — disclose the risks and the downsides. To them, Agility is a silver bullet that is applicable in all cases with no compromises.
Just to give one example, “Practices of an Agile Programmer” clearly states that agile is not for everyone.
The truth is that these practices come at a price, and for a lot of organizations, the price gets high very quickly. Agile development will never go far if its proponents keep ignoring these organizations and make condescending comments to its members.
Here Cedric is spot on. Yay!
I like Test-Driven Development. I really do, and I’m fortunate enough to work on a project that lets me use TDD most of the time. But the truth is: at times, I don’t do TDD because implementing a feature quickly is more important than a fuzzy feeling. And I’m also aware that TestNG is an open source project with less than five developers, all of them on the bleeding edge and aware of the latest advances in software engineering.
And this is my main beef with Agilists: I strongly suspect that most of them are spending their time on open source projects with like-minded fellows, but none of them have any experience what companies whose survival depends on shipping software have to go through to organize huge code bases growing thousands of lines of code every day under the combined push of hundreds of a developers, all with their personal background, education and bias.
My main beef with people opposing agility is that they basically say that too many of the developers out there are morons who cannot perform unless closely supervised and given clear instructions, and that there is no hope that that will ever change. It is a weird combination of pessimism and elitism
Now Cedric has a history of not liking agile methods, and that is fine with me. Whatever makes him happy. But his retoric in this case is like watching somebody who does not know karate perform a round house kick - lots of power and effort but misses the target completely.
July 13th, 2006 at 17:08
I keep finding responses to Cedric’s remarks all over the net. It seems he stirred people up quite a bit! I had a reaction, too.
I like your analogy with karate. It’s good that Cedric missed the target; you know what happens to a person’s leg when they do the kick incorrectly, but connect with the target with great force.
August 11th, 2006 at 15:49
I think you’re still not completely getting it for the same reason he didn’t: communication gaps. Cedric’s fundamental point is that people who push Agile aren’t necessarily communicating where the value is. And as a result, there’s general confusion.
Many push XP as dogma/rhetoric and claim it is Agile. Well, yes that is true - but it’s only one flavour and arguably a poor one as a general one-size-fits-all choice. Agile is meant to avoid such statements, yet here we have a flip side.
Dogmatism has taken hold with many converts to the Agile religion who insist others follow their version of Agile…this is hypocrisy at its purests. No wonder he was confused!
It does not however negate the basis of what I believe his point was and THAT is why it is resonating across the industry, unfortunately he did not communicate it well just as it seems Jeff failed to fully communicate what he was after…
In fact, it may be that the rapid iteration and tighter interaction is the biggest value to an Agile method. Communication is often poor. This is a prime example
However the “big stir” is only part of that. The unspoken issue is that Agile is being used to enforce sweat shops and INCREASE micromangement, not free professionals from it.
Creative, smart people work well when there is respect for their professionalism, their input and knowledge. Agile can go a long way towards encouraging this - but in many places XP is rammed down people’s throats with all privacy and ability to concentrate removed. No amount of Hawaiin Shirt Days or “rah team, have a free Coke” will address the fundamental lack of control over working environment.
But again - this isn’t communicated well by those driving the backlash.
Communication is key.
August 15th, 2006 at 21:53
Greg,
Cedric used a presentation on TDD talk fall out against “Agilism”, while at the same time distorting the words of the presenter. That is my main beef with his post.
And I agree that people in the XP community most certainly can be dogmatic, especially a few years back. But I am surprised by the rest of your post, I have no experiences of agile enforcing sweat shops. Any examples?
August 17th, 2006 at 18:20
Hi Marcus, it’s clear that what he discussed didn’t align with what was presented - the difference between “distorted” and “miscommunicated” is somewhat contextual and goes back to communication factors. Was it Misunderstood when heard or misunderstood during the subsequent relating or was there bias that distorted it on the way in or was it just done deliberately..?
I am currently seeing Agile being used for this purpose. I cannot unfortunately indicate where that is being done for obvious reasons.
However, this warning is not new, Tom DeMarco and Alistair Cockburn have both issued the caution previously. And there are a LOT of anecodotes of programmers bailing out of these jails, a quick surf on google shows them. However, it’s not “cool” to point it out and go counter-current, here’s an example of the complaint and how it’s brushed off: http://www.embedded.com/showArticle.jhtml?articleID=16700086
June 12th, 2008 at 17:42
“unfortunately he did not communicate it well just as it seems Jeff failed to fully communicate what he was after…”
Yeah, obviously I learned after this debacle. However, it was the same preso I had given to gobs of other developers, and never had any problems before. In prior talks, the dissenters actually voiced their concerns, etc., in the room, and we had honest discussions, as opposed to this case, where I was attacked after I left the building. I did express limitations of TDD, and so on. The talk was solicited as a very introductory overview of TDD, and that’s what it was. Certain people came in with other agendas, and they heard what they wanted to hear.
June 12th, 2008 at 18:13
Jeff,
Thanks for your comment. After this incident I have refrained from commenting on Cedrics writings. Not all gems in the Google mine I presume.