BT

"Agile People Do Get It" -- Uncle Bob

| by Deborah Hartmann Preuss Follow 0 Followers on Jun 16, 2006. Estimated reading time: 2 minutes |
As is usual with a rant, Cedric Beust's lengthy diatribe last week against "troubling comments" by an Agile speaker contains a grain of truth and at the same time, propagates a few misunderstandings.

Among his key complaints, are assertions like:
  • Tests are (executable) specs.
  • If it's not testable, it's useless.
And, more broadly: "Your code is your spec", and "Documentation gets out of date, code never does".

The trigger for his blog entry was a hands-on demonstration by Jeff Langr of Test Driven Development (TDD).  Beust complained about the quality of Langr's examples, and questioned the honesty of the demo.  Jeff Langr has responded in detail regarding his tests, and more generally addresses the subject that seems to have got Beust going: your code is your spec. Langr blogs:
Are tests specs? Yes, they can be, although in a small number of cases it's probably better to just write a brief English specification. But I'm doing test-driven development anyway, for other benefits that include fewer defects and better design.
He goes on to say that, given a choice between heavily documented code with no tests, or poorly written tests, and code without traditional documentation but having an adequate suite of tests (probably built with TDD), he'd choose the latter. This is the extreme, - when balanced with his previous quote, it's clear that he's not anti-documentation, he's simply using hyperbole to make a point.

While Beust does make some valid points, here's one statement which inaccurately paints all Agilists with the same dirty brush:
"Software is shipped with untested parts every day, and just because it's not entirely tested doesn't mean it's bad software or that the untested parts are 'useless'. Agilists just don't understand the meaning of calculated risk."  [emphasis added]
In response, "Uncle" Bob Martin concedes that
"if Agile evangelists use religious arguments, and don't connect with real developers with real problems, then they aren't going to get much further. The early adopters have adopted; and the next batch of folks are a bit more skeptical. To reach them we have to make much stronger arguments that are tied to the reality of development."
But Martin questions whether Beust is talking about risk or hope :-) and ends with this:
Actually, Agile People DO get it. We get it very well.  And we have gone very far into helping the rest of the industry get it.  There is hardly a big or small company that has not tried agile developent in one form or another, and there are many, many, that have invested significantly and are enjoying the benefits.

Agile is not a silver bullet. Agile is not THE ANSWER. But Agile techniques, and especially TDD, are very powerful techniques to get software written well, and to increase the level of professionalism in our industry.
Others who've jumped into the fray include Scott Ambler, with his TDD Myths and Misconceptions, and Ron Jeffries and others who are apparently holding an interesting discussion over on the PragProg yahoo group.  For those who aren't members of that mailing list, you can read Ron's take on a related absurd slogan in Automating "All" Tests: Slogan? Logical Impossibility? Foolishness?

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Distributed Conversation Summaries by Geoffrey Wiseman

I've gotta say, these "tying a community conversation together" threads are increasingly useful in a world of disconnected blogs and trackbacks; helps to give a high-level overview to someone who hasn't necessarily been able to track down all (or any) of the elements of a distributed conversation.

What specs? by Stephan Schmidt

I think there are two kinds of tests, developer tests (unit tests) and acceptance tests. Developer tests test the code against the design, acceptance tests test the system against the specs. So both are kind of encoded specs, developers tests are encoded design specs and acceptance tests are encoded szstem specs.

(Though I think you still need written specs/ requirements, depends on your customer)

bye
-stephan
--
stephan schmidt
cintoo lead
cintoo.org

Re: Distributed Conversation Summaries by Floyd Marinescu

Thanks Geoffrey, we aim to be a source for you to track what's going on, what matters, what's innovative. Each of our editors are watching all the blogs and sources in their communities and write the concise, summarized versions of what happened here, for your benefit.

Fowler adds his own thoughts by Stefan Tilkov

... although they are actually not new anymore, still relevant: martinfowler.com/bliki/SpecificationByExample.html

Re: Distributed Conversation Summaries by Deborah Hartmann

Thanks, Geoffrey! I enjoyed pulling this one together - felt more constructive than just ranting about someone else's rant.
Each of our editors are watching all the blogs and sources
That being said, it's just not possible to follow it all in real time :-) though we try. If you spot a good connection you think we can use, I hope you'll use the contribute news button at the top of the page!

Re: Scrum by Deborah Hartmann

Yes, with Scrum, a manageable amount of work is done at any given time, so written specs are less important during development - the whole team is present at planning and has heard the customer explain the features, and the customer is regularly involved during development, so clarifications are made in real time.

Some of my Scrum teams have decided to write a 'spec' after the fact, which is delivered with the code at the end of the iteration. It's accurate because the decisions have been hammered out and the surprises have already been discovered and resolved. It also tends to be smaller... the team knows what is and what is not documented elsewhere (models, code, tests), and documents the gap only. Commonly this includes high-level english description (by way of introduction), UML, photos of whiteboard discussions held during development, acceptance test descriptions in english (from the planning meeting, augmented as needed during development). Note, in our case, we decided that these would be understood as historical artifacts, and would not be maintained. In this case, at project's end, a small amount of up-to-date doc would need to be produced, too. Time needs to be planned for this.

Agile says "do the minimum amount of work to accomplish your customer's goals" [paraphrase]. We mustn't forget that even if the team is temporary, the customer may own the code for a lot longer, and part of their need is an app that is maintainable. This means that the customer and team together must agree on what minimum level of documentation is required to accomplish that - and what form is appropriate. If they agree that the regression suites (unit, acceptance, performance, etc.) (automated or not) are adequate, then that's what they should do!

Documentation needs differ from one team/customer to the next and should always be discussed in the context of a given application - a quick-and-dirty website and an FDA-regulated app might have different documentation requirements. Might :-) It requires a conversation. In my opinion, that's a benefit of having one person on the team focused on process - the ScrumMaster is responsible to make sure that communication between team and customer is adequate - and that includes a discussion about legacy artifacts. I find it helps to ask the team - what would you need a year from now if you were asked to do maintenance on a piece of this code, that had evolved?

It's even more helpful if the customer is in the room - I start by asking them: is it important to you that this app be maintainable a year from now? "Oh yes!" is typically the answer. Later, when the pressure is on, the customer is aware of the cost of deferring documentation, a common tactic to gain development time. (We all know what "defer" means, right?) Now team and customer can have a meaningful conversation, and make good choices :-)

deb

Half a Pattern is a Recipe for Grief by Deborah Hartmann

I think, from experience, that some of the persistent misconceptions out there about XP come from the experience of teams who have implemented parts of XP without understanding how the missing parts balance out the pattern, so they can't compensate for them.

I just came across this wonderful entry again, by Ron Jeffries called "We Tried Baseball and It Didn't Work" :-)
www.xprogramming.com/xpmag/jatBaseball.htm

Yes, this explains exactly what I've seen. For heaven
's sake, who on earth could enjoy Baseball??
Have a look :-))

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT