Weblogs Forum - Religion's Newfound Restraint on Progress

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Religion's Newfound Restraint on Progress

55 replies on 4 pages. Most recent reply: Apr 11, 2008 8:15 AM by Matt Drayer

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 55 replies on 4 pages [ « | 1 2 3 4 | » ]

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: the "TDD-or-acceptance" question

Posted: Oct 14, 2007 8:29 PM

> Isaac Gouy wrote:
-snip-
> > It also fails to address the enormous cost of testing -
> > when 35% of code written is test cases we have a
> > problem.

Michael Feathers wrote
> It's funny. When I read that, my first thought was that
> no one would see the cost of thinking as a problem, and
> yet that is exactly what accounts for the cost of TDD.

afaict the 35% I quoted had nothing to do with TDD (people have been writing test cases for a long time before TDD came along) - did you watch any of the video?

-snip-
> I don't really have much patience any longer for
> cost-based objections to quality techniques.

When I read that, my first thought was uncomplimentary.

Software is thrown at users so they can find the bugs because of cost-based objections. The objections won't disappear because of your lack of patience, they need to be addressed - the costs need to go down.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: embrace quality

Posted: Oct 14, 2007 9:27 PM

John Zabroski wrote
> @Alan Cooper: "The impression I get from XP is that it
> addresses the problems of corporate developers."

> What does that even mean? Is that a good or bad thing?

Neither good nor bad, and both good and bad.

Neither good nor bad - simply that it addresses the problems of a particular kind of software development and not other kinds of software development.

Good - the problems of developers need to be addressed.

Bad - the focus is on the developers not on the business, the scope's too small.

> @maybe we can agree with Alan Cooper's emphatic Rather
> than "embrace change," I would say, "embrace quality."
>
> What's the gross impact? Is it existential? Is it
> practical?
>
> In my eyes, a comparison of XP and Interaction Design is
> being devolved to comparing two slogans.

Well, slogans and argument by assertion.

Why let anyone get away with saying "design" or "quality" without any qualification? Design of what? Quality of what? Quality of the code base? Quality of the development process? Quality of the created products / services?

> I'm naive, but I always looked at the benefit of
> most of XP as synergy. In particular, continuous
> integration. There is a lot to like about combining
> phases, and it's worth noting the quote from Alan Cooper
> comes from a discussion about phases and whether or not
> they are a Good Thing.

Why do you think that starting from a given product/service design would prevent continuous integration of code?

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: the "TDD-or-acceptance" question

Posted: Oct 15, 2007 2:22 AM

> > Isaac Gouy wrote:
> -snip-
> > > It also fails to address the enormous cost of testing
> -
> > > when 35% of code written is test cases we have a
> > > problem.
>
>
> Michael Feathers wrote
> > It's funny. When I read that, my first thought was
> that
> > no one would see the cost of thinking as a problem, and
> > yet that is exactly what accounts for the cost of TDD.
>
> afaict the 35% I quoted had nothing to do with TDD (people
> have been writing test cases for a long time before TDD
> came along) - did you watch any of the video?

Yes, I watched the first half a few days ago, and it seemed very close to the presentation I saw from someone from the same company at JAOO the other week. I didn't think that 35% was a number that was leveled directly at TDD. For my point, I don't care where the tests come from. Anyone who thinks 35% is excessive is bound to be surprised at > 50%.

> > I don't really have much patience any longer for
> > cost-based objections to quality techniques.
>
> When I read that, my first thought was uncomplimentary.
>
> Software is thrown at users so they can find the bugs
> because of cost-based objections. The objections
> won't disappear because of your lack of patience, they
> need to be addressed - the costs need to go down.

And they can. It's like anything else. You can rush, but in the end it costs more. It's the paradox of quality. A little more effort ends up saving time. I put cost based objections to quality in the same category as the advice to avoid cleaning in a kitchen to go faster. From what I've seen, in good restaurant kitchens, they clean constantly, and it keeps everyone out of the weeds.

James O. Coplien

Posts: 40
Nickname: cope
Registered: May, 2003

Re: the "TDD-or-acceptance" question

Posted: Oct 15, 2007 3:06 AM

> From what
> I've seen, in good restaurant kitchens, they clean
> constantly, and it keeps everyone out of the weeds.

Some of the Kaizen thinking (the stuff regarding mura, mudi, mudi) related to eliminating waste is an explicit foundation of Lean and of Scrum. The people who brought you Kaizen suggest that any exercise designed to improve productivity start with this little ceremony:

http://www.npccmauritius.com/5sdetails/

It's something I'd like to try out at <a href="http://www.campscrum.com/">Camp Scrum</a> next week.

So continuous (or at least periodic) cleaning is a fundamental principle.

However, there is no testing or test-like activity involved that I can see.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: the "TDD-or-acceptance" question

Posted: Oct 15, 2007 3:45 AM

> > From what
> > I've seen, in good restaurant kitchens, they clean
> > constantly, and it keeps everyone out of the weeds.
>
> Some of the Kaizen thinking (the stuff regarding mura,
> mudi, mudi) related to eliminating waste is an explicit
> foundation of Lean and of Scrum. The people who brought
> you Kaizen suggest that any exercise designed to improve
> productivity start with this little ceremony:
>
> http://www.npccmauritius.com/5sdetails/
>
> It's something I'd like to try out at <a
> href="http://www.campscrum.com/">Camp Scrum</a> next
> week.
>
> So continuous (or at least periodic) cleaning is a
> fundamental principle.
>
> However, there is no testing or test-like activity
> involved that I can see.

True, but when you take an idea from one discipline and apply it to another, there's always the issue of how to map it. The most meaningful mapping I see there would make code our primary workspace.

Yes, keep the desk clean, but really, keep the classes and methods clean. That's where the real work happens. When you want to do that, though, you're immediately faced with the confident change question: How scared were you when you were cleaning? Do you know whether you've broken anything? Tests are helpful feedback.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: the "TDD-or-acceptance" question

Posted: Oct 15, 2007 4:00 AM

Jim,

I want to ask you something directly. We've met a couple of times, so I hope you know that I'm just being direct; it's hard to read tone over the web.

Here's my question. You point at these couple of studies on TDD and your response seems to be to throw TDD out. Why? If we're trying to learn something isn't the best response to take a look at the projects that are doing TDD with good results, compare them to the ones that aren't and then try to form another hypothesis? Isn't that best if we really want to know?

FWIW, an issue of IEEE Software over the summer had a wide range of results from studies of projects using TDD.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: the "TDD-or-acceptance" question

Posted: Oct 16, 2007 6:16 PM

Michael Feathers wrote
-snip-
> I didn't
> think that 35% was a number that was leveled directly at
> TDD. For my point, I don't care where the tests come
> from. Anyone who thinks 35% is excessive is bound to be
> surprised at 50%.

As you understood TDD was not involved your "the cost of thinking" response seems nothing more than smoke.

-snip-
> It's like anything else. You can rush, but
> in the end it costs more. It's the paradox of quality. A
> little more effort ends up saving time. I put cost based
> objections to quality in the same category as the advice
> to avoid cleaning in a kitchen to go faster. From what
> I've seen, in good restaurant kitchens, they clean
> constantly, and it keeps everyone out of the weeds.

Once again the "quality" of what?

Do "good restaurant kitchens" spend 35% 50% of their time cleaning or do they redesign the kitchen to reduce spillage?

Do "good restaurant kitchens" do meal design up front, or do they believe the chefs should take a different approach with each plate while the customers wait?

> Yes, keep the desk clean, but really, keep the classes
> and methods clean.

Yes let's insist that everyone keeps their desk clean because the important thing is the ritual - why bother asking if they are more effective with a messy desk.

Yes let's insist that everyone keeps the classes and methods clean because the important thing is the ritual - why bother asking if they are more productive with some messy classes.

If they were bothered about ritual, the people who brought us Kaizen (not the government of Mauritius) would operate pure JIT without inventory buffers but they are bothered about being productive so they still have some inventory buffers.

> an issue of IEEE Software over the summer

Congratulations, that is a little more helpful than some of the vague gesturing towards studies on TDD we've had so far.

It would be a lot more useful if you said which articles you meant instead of leaving us to play guessing games!

Maybe you meant the May/June 2007 Guest Editors' Introduction: TDD--The Art of Fearless Programming which among other things summarizes "selected TDD empirical studies from industry and academia"?

It's online and freely accessible after a "guest" login:
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=
/dl/mags/so/&toc=comp/mags/so/2007/03/s3toc.xml&DOI=10.1109/MS.2007.75

Lasse Koskela

Posts: 5
Nickname: lkoskela
Registered: Oct, 2007

Re: the "TDD-or-acceptance" question

Posted: Oct 17, 2007 4:29 AM

Isaac Guoy wrote:
> Michael Feathers wrote:
> > little more effort ends up saving time. I put cost based
> > objections to quality in the same category as the advice
> > to avoid cleaning in a kitchen to go faster. From what
> > I've seen, in good restaurant kitchens, they clean
> > constantly, and it keeps everyone out of the weeds.
>
> [...] Do "good restaurant kitchens" spend 35% 50% of their time
> cleaning or do they redesign the kitchen to reduce spillage?

I haven't worked in a good restaurant kitchen myself. Have you?

With that said, I suspect that good restaurant kitchens don't spend half of their time cleaning because 1) they don't spill and, 2) when they spill, they clean up immediately. Other than being a safety hazard, those stains take longer to clean up when they've stuck.

And then there's the whole broken window syndrome and other fluffy cognitive psychology stuff that, to summarize, suggests that it's easier to keep delivering good food to customers when the kitchen is kept clean at all times.

Isaac Guoy wrote:
> Do "good restaurant kitchens" do meal design up front, or
> do they believe the chefs should take a different approach
> with each plate while the customers wait?

The problem with analogies is that they break down if you take them too far.

Yes, kitchens do design their menus up front. However, it's important to note that the menu design is closer to software development than turning out a plate from that menu--which is a more or less repeatable process. The menu design has been, in a good restaurant, an iterative process of several inspect and adapt cycles.

Again, this is still just an analogy and shouldn't be taken too far.

Lasse

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: the "TDD-or-acceptance" question

Posted: Oct 17, 2007 5:31 AM

Isaac wrote:
> As you understood TDD was not involved your "the cost of
> thinking" response seems nothing more than smoke.

Sigh. Address the point. The cost of writing tests in TDD is thinking cost.

> > an issue of IEEE Software over the summer
>
> Congratulations, that is a little more helpful than some
> of the vague gesturing towards studies on TDD we've had so
> far.
>
> It would be a lot more useful if you said which articles
> you meant instead of leaving us to play guessing games!
>
> Maybe you meant the May/June 2007 Guest Editors'
> Introduction: TDD--The Art of Fearless Programming which
> among other things summarizes "selected TDD empirical
> studies from industry and academia"?
>
> It's online and freely accessible after a "guest" login:
> http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePat
> h=
> /dl/mags/so/&toc=comp/mags/so/2007/03/s3toc.xml&DOI=10.1109
> /MS.2007.75

Thanks for the link, Isaac. I'm actually out of town right now and I don't have that issue of IEEE Software with me. When I responded to Jim, it was merely to point him in the direction of other research. I don't recall the particular article that had it. If he chooses to look into it, I'm sure he'll do what you did: look into it.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: the "TDD-or-acceptance" question

Posted: Oct 17, 2007 12:01 PM

Michael Feathers wrote
> Sigh. Address the point. The cost of writing tests in
> TDD is thinking cost.

When you already know that TDD was not used, you already know that any claims you wish to make about TDD are in this case irrelevant.

> When I responded to Jim, it was merely to point
> him in the direction of other research. I don't recall
> the particular article that had it. If he chooses to look
> into it, I'm sure he'll do what you did: look into it.

And he still won't know if he's stumbled across the article you had seen - only you can tell us that.

The toc and abstracts are online
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/so/&toc=comp/mags/so/2007/03/s3toc.xml

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: the "TDD-or-acceptance" question

Posted: Oct 17, 2007 1:16 PM

Lasse Koskela wrote
-snip-
> I haven't worked in a good restaurant kitchen myself. Have
> you?

No, not even in a bad restaurant kitchen.

> With that said, I suspect that good restaurant kitchens...
-snip-

Let's cut to the chase, speculation about what happens in restaurant kitchens is unhelpful.

Restaurant kitchens are not analogues of software development.

Bad analogies comparing the conceptual work of software development to physical work do not illuminate they obfuscate.

I think that's as clear to Michael Feathers as it is to you.

(Sorry Michael talking about the "contextual in software development" and then ripping homolies out of kitchen context is at least contradictory.)

> However, it's important to note that the menu design is
> closer to software development than ...

imo No it isn't important to note that!

My guess is that as few of us have experience of menu design as we do of working in a kitchen restaurant - pointing to our shared ignorance of kitchen work or menu design or anything else is unhelpful.

We share experience of conceptual work, we share experience of programming, we share experience designing software products - sensible discussion has to be based on our shared knowledge.

Lasse Koskela

Posts: 5
Nickname: lkoskela
Registered: Oct, 2007

Re: the "TDD-or-acceptance" question

Posted: Oct 18, 2007 3:33 AM

> Let's cut to the chase, speculation about what happens in
> restaurant kitchens is unhelpful.
>
> Restaurant kitchens are not analogues of software
> development.
>
> Bad analogies comparing the conceptual work of software
> development to physical work do not illuminate they
> obfuscate.
>
> I think that's as clear to Michael Feathers as it is to
> you.

I'm sorry, Isaac. It's not clear to me.

Analogies and metaphors can be useful until they're taken too far. To paraphrase Martin Fowler, a metaphor is useful if it helps you formulate questions and it's dangerous if you use it to justify answers.

I assume Michael was trying to help you understand his perspective by sharing a metaphor of the restaurant kitchen. He was not (I assume) implying that restaurant kitchens would be like software development. He was (I assume) implying that there's something about restaurant kitchens as a workplace that, for Michael, seem to also be true for a code base as a software developer's workplace. I see the similarity so I appreciate the metaphor. You don't see the similarity (I assume) so you don't appreciate the metaphor. That's how it is--metaphors don't work every time and for everyone.

While you might not like metaphors, that doesn't mean they're not useful in general.

> > However, it's important to note that the menu design is
> > closer to software development than ...
>
> imo No it isn't important to note that!

If you're pointing out a "flaw" in a metaphor by taking it so far that it breaks down, why shouldn't I point out a "flaw" in that activity, too?

In hindsight, I realize that perhaps I shouldn't have done that. I did, however, and I apologize.

> We share experience of conceptual work, we share
> experience of programming, we share experience designing
> software products - sensible discussion has to be based on
> our shared knowledge.

I've participated a number of discussions that I considered sensible even though they involved the use of metaphors. A shared context is definitely important but I feel that metaphors are often a useful means for communicating ideas for which that shared context does not exist.

--

I realize we've drifted rather far away from the topic and it makes me sad.

Lasse

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: the "TDD-or-acceptance" question

Posted: Oct 18, 2007 12:35 PM

Don't be sad!

Lasse Koskela wrote
-snip-
> I assume Michael was trying to help you understand his
> perspective by sharing a metaphor of the restaurant
> kitchen. He was not (I assume) implying that restaurant
> kitchens would be like software development. He was (I
> assume) implying that there's something about restaurant
> kitchens as a workplace that, for Michael, seem to also be
> true for a code base as a software developer's workplace.

Look at the context: Oct 15, 2007 2:22 AM

Is metaphor being used to justify Michael's "A little more effort ends up saving time" answer?

-snip-
> While you might not like metaphors, that doesn't mean
> they're not useful in general.

"Too often, we use metaphor to gloss over inexact thinking..."

Style: Toward Clarity and Grace, Joseph M Williams

-snip-
> If you're pointing out a "flaw" in a metaphor ...

I'm pointing out that the use of metaphor successfully de-railed any examination of costs/benefits into musings on how little we know about restaurant kitchens.

-snip-
> A shared context is definitely important but I
> feel that metaphors are often a useful means for
> communicating ideas for which that shared context does not
> exist.

We're software developers - a shared context does exist!

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: the "TDD-or-acceptance" question

Posted: Oct 19, 2007 12:08 PM

James O. Coplien wrote
> Some of the Kaizen thinking (the stuff regarding mura,
> mudi, mudi) related to eliminating waste is an explicit
> foundation of Lean and of Scrum. The people who brought
> you Kaizen suggest that any exercise designed to improve
> productivity start with this little ceremony:
>
> It's something I'd like to try out at next
> week.
>
> So continuous (or at least periodic) cleaning is a
> fundamental principle.
>
> However, there is no testing or test-like activity
> involved that I can see.

I find it comical that you've made these comments in a discussion which you began with "... we have invented and are following religions, or perhaps even cults, intent on ceremonies and rituals rather than thinking or inspection."

What costly problem have you observed in the software development process that might possibly be reduced or eliminated by continuous or periodic cleaning (whatever that means in software development)? How much will the problem be reduced? How will you know that the problem has been reduced by that amount?

When you don't start with answers to those questions you aren't doing something that "the people who brought you Kaizen" would recognise as Kaizen.

When you do that little ceremony in software development just because that little ceremony is performed in manufacturing you are engaged in nothing more than ritual.

Steven E. Newton

Posts: 137
Nickname: cm
Registered: Apr, 2003

Re: Religion's Newfound Restraint on Progress

Posted: Oct 26, 2007 10:25 PM

Does anyone have a corrected citation for the following assertion?

"on-site customer has also been at least partially discredited (Martin and Noble)."

The link is to http://agile.vtt.fi/docs/publications/2004/2004_eurospi_customer_in_an_xp _project.pdf, which is actually the Juha Koskela and Pekka Abrahamsson paper again. Are the author credits wrong or was it intended to cite a different study.

Flat View: This topic has 55 replies on 4 pages [ « | 1 2 3 4 | » ]

Previous Topic

Next Topic