The Artima Developer Community
Sponsored Link

Weblogs Forum
Religion's Newfound Restraint on Progress

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

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 55 replies on 4 pages [ « | 1 2 3 4 ]
Lasse Koskela

Posts: 5
Nickname: lkoskela
Registered: Oct, 2007

Re: Religion's Newfound Restraint on Progress Posted: Oct 27, 2007 3:58 AM
Reply to this message Reply
Advertisement
> 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.

I believe it was intended to reference an ADC2004 paper by Angela Martin, Robert Biddle, and James Noble, titled "The XP Customer Role in Practice: Three Studies":

http://www.mcs.vuw.ac.nz/~angela/publications/Martin-ADC2004Submission1.2.pdf

This paper, in its conclusions summarize the trio's findings like this:

"The existing XP Customer practices appears to be achieving excellent results but they also appear to be unsustainable, and so constitute a great risk to XP projects, especially in long or high pressure projects."

Instead of saying that the "on-site customer" has been partially discredited, I'd rather say that the on-site customer role may need to be fulfilled by a customer team rather than an individual. After all, the core idea of having the customer represented on-site is perfectly valid--the issue is sustainability when this representation is embedded into a single individual.

Geir Hedemark

Posts: 1
Nickname: geirhe
Registered: Oct, 2007

Re: the "TDD-or-acceptance" question Posted: Oct 27, 2007 3:24 PM
Reply to this message Reply
> Do "good restaurant kitchens" spend 35% 50% of their time
> cleaning or do they redesign the kitchen to reduce
> spillage?

They do both.

> 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?

I have wondered wether to answer this for a week or so. I´ll bite.

That is the wrong rhetorical question to ask.

Now, I am a software developer. You can more or less put any development-related label on me, and I will have done that job in the past. I am no guru. I frequently make mistakes. I hope I learn from them.

I am also a foodie. I have done the wedding dinner for a friend of mine, I have cooked a 7 course meal for 35 bikers, I regularly cook food for many people with as high a quality as I can. I am not a trained cook, but I know a bit about what is needed to avoid having 50 dinner guests needing to go potty at the same time on two lavvies. This would be the dinner for the wedding, by the way. If you want to do a scallop carpaccio, be very sure of your produce.

A restaurant kitchen does not clean because they are production oriented. They clean in between tasks because doing their regular tasks (which is production, granted) will suffer if they constantly need to redo stuff because they contaminate food with scraps from whatever they did before. In software development, we would call this "reducing the bug count so you can get some real work done". We could even call it "not starting from scratch every four years because nobody can understand what the mess does any more".

Clearing away the stuff from the last thing you did and disinfecting the bench is part of something called "mise en place". Roughly, it means you need to keep track of what is going to happen. It has very little to do with the physical act of cleaning and everything to do with how you organize your work.

When you are juggling five dishes in varying states of completion, you really need to have some kind of control over that project. You also don´t have time to run around, fetching things, putting things away, trying to find where you put your tongs or where those dishes are, and, oh gods, the salmon just got burnt.

I should say "I burnt the salmon". Bugs don´t happen by themselves.

That is why there usually is a strict regime in place where you clear away whatever you don´t need, you wash down your bench, and you fetch whatever foodstuffs and utensils you need for whatever you are going to do next. You never, ever put dirty dishes in the sink - you need that sink for other stuff than as a container for dirty dishes. About 20% of the time in a kitchen is spent doing what you think of as "making food". The rest of the manpower is used to put everything in order for putting a dish out blindingly fast as soon as someone wants it. In restaurants with a fair throughput there is usually a person dedicated to ensuring the dishes are clean.

As you can see, this is a way of thinking about quality and work organization. No sauce involved.

Now, back to the wrong rhetorical question. You seem to think that there is nothing to learn from production environments. If that is the case, I think you are wrong. Mise en place is a must-have for developers too. If all you do is answer the questions of the people who put their nose in the door, fixing bugs or trying to find stuff you need, you will not get any real work done. This has absolutely nothing to do with the state of your desk.

If you think the software development community is the first profession to tackle these kinds of issues, you really are living a very shielded life. That is why your rhetorical question was wrong. I think you would be better served by trying to find stuff that you can use than by writing other very competent people off as "in manufacturing".

I will get off my high horse now.

Geir

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: the "TDD-or-acceptance" question Posted: Oct 27, 2007 6:15 PM
Reply to this message Reply
Geir Hedemark wrote
-snip-
> If you think the software development community is the
> first profession to tackle these kinds of issues, you
> really are living a very shielded life. That is why your
> rhetorical question was wrong. I think you would be better
> served by trying to find stuff that you can use than by
> writing other very competent people off as "in
> manufacturing".

I think "the software development community" is better off observing the projects they are working on, and investigating and reducing the problems they actually encounter, than making-up stories about restaurant kitchens.

A big part of the reason other manufacturers took 30 years to close the gap was that they initially copied specific rituals instead of copying the general method of continuous improvement - context matters, training people to solve problems by experiment matters.

Harvey Sugar

Posts: 1
Nickname: nerd1951
Registered: Nov, 2007

Re: Religion's Newfound Restraint on Progress Posted: Nov 8, 2007 5:10 PM
Reply to this message Reply
Sometimes a platitude says it all. A colleague once said to me, "You can't test quality into a product." The statement struck me as profound and I think it sums up your argument.

Bruce Eckel

Posts: 874
Nickname: beckel
Registered: Jun, 2003

Re: Religion's Newfound Restraint on Progress Posted: Nov 9, 2007 10:31 AM
Reply to this message Reply
> Sometimes a platitude says it all. A colleague once said
> to me, "You can't test quality into a product." The
> statement struck me as profound and I think it sums up
> your argument.

Myself, I think that testing alone doesn't produce quality. Quality is a subtle, elusive thing that also requires insight, skill, and possibly abilities we have yet to (and may never) isolate.

On the other hand, I don't think it will work to try to produce quality without testing.

So my platitude is: "Testing is necessary for quality, but not sufficient."

Bill Cole

Posts: 1
Nickname: methuselah
Registered: Nov, 2007

Re: the "TDD-or-acceptance" question Posted: Nov 30, 2007 6:45 PM
Reply to this message Reply
> If you think the software development community is the
> first profession to tackle these kinds of issues, you
> really are living a very shielded life. That is why your
> rhetorical question was wrong. I think you would be better
> served by trying to find stuff that you can use than by
> writing other very competent people off as "in
> manufacturing".

Well put.

James is absolutely correct that we're too focused on fads and re-labeled techniques. I admire and respect the intellectual courage he puts on the line by raising this issue.

But I think another point he makes needs to be emphasized also - what if we took the efforts expended into TDD and instead invested them into "traditional" reviews and walk throughs? It's an empirical fact that defect prevention is a more efficient quality approach that defect detection.

The religious tone of many replies here validates the title. Only now are empirical studies coming out that prove/disprove assertions made by the XP community. Which means that (right or wrong) for the last seven years XP advocates have been peddling unsupported moonshine.

XP has always seemed like Snake Oil to me. Call me old-fashioned, but I came out of the Software Engineering community, and I cannot envision *any* large mission-critical system being developed using XP. Its impossible for me to imagine designing and producing an Atlas rocket or 737 with "Customer" interviews.

I would also offer that the pernicious quality of YAGNI effects not only architecture, but development infrastructure as well.

As for metaphors, I would suggest that the Systems Engineering discipline created by the Dod/Aerospace community fifty years ago is still 100% relevant today for large-scale software development.

Regards;

Miles Whitener

Posts: 5
Nickname: mwhitener
Registered: Nov, 2007

Re: Religion's Newfound Restraint on Progress Posted: Dec 6, 2007 10:19 AM
Reply to this message Reply
Jim,

Joel Spolsky has buried some nice nuggets regarding T?D here:

http://www.joelonsoftware.com/items/2007/12/03.html

Miles Whitener
MultiParadigm.com

Steve Freeman

Posts: 3
Nickname: smgfreeman
Registered: May, 2006

Re: the "TDD-or-acceptance" question Posted: Jan 16, 2008 8:08 PM
Reply to this message Reply
As Michael Feathers put it in another comment, all the good stuff starts as moonshine. Not least because you have to have tried it for a while before you can measure it, or even understand what to measure. As it happens, there are a couple of data points. The original C3 project arrived at their balance of practice by trying stuff and measuring the results; it worked in their situation, obviously not everywhere else. Industrial Logic has been doing organisational studies for a while that suggest that XP is cost-effective, sorry I don't have the reference handy.

I've read the publicly available papers from the VTT and, as Lasse said, they're not very convincing. If anything, the literature seems to be slightly in favour of TDD, with stronger results on industrial rather than student projects.

Is XP suitable for large-scale projects. Unadorned, certainly not and I don't know anyone who makes that claim. I /do/ know of a company that's been using an adaption of XP for pacemakers and it works for them (and the Feds).

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: the "TDD-or-acceptance" question Posted: Jan 17, 2008 2:09 AM
Reply to this message Reply
> As it happens, there are
> a couple of data points. The original C3 project arrived
> at their balance of practice by trying stuff and measuring
> the results; it worked in their situation...

Unless I'm mistaken, the C3 project never delivered and the customer was so impressed that XP was banned withing that company...

Lasse Koskela

Posts: 5
Nickname: lkoskela
Registered: Oct, 2007

Re: the "TDD-or-acceptance" question Posted: Jan 17, 2008 9:38 AM
Reply to this message Reply
> > As it happens, there are
> > a couple of data points. The original C3 project
> arrived
> > at their balance of practice by trying stuff and
> measuring
> > the results; it worked in their situation...
>
> Unless I'm mistaken, the C3 project never delivered and
> the customer was so impressed that XP was banned withing
> that company...

The C3 project did deliver and the system paid salaries of several thousand people. In the last two years of the project's lifetime, apparently they did not deliver another release, however.

It's also apparently true that XP was "banned" after C3 but there's also signs of them resuming the use of XP afterwards.

This is all hear-say, however. I wasn't on the C3 project.

Neither was Martin Fowler but he does point out that the Wikipedia page, for example, doesn't seem to reflect what really happened: http://martinfowler.com/bliki/C3.html

Matt Drayer

Posts: 1
Nickname: mattdrayer
Registered: Apr, 2008

Re: Religion's Newfound Restraint on Progress Posted: Apr 11, 2008 11:15 AM
Reply to this message Reply
Thanks for the great POV. I've often found myself arguing the same point about the focus on implementation-specfic skills versus overall problem solving and solution design.

Matt
http://organicapp.blogspot.com

Flat View: This topic has 55 replies on 4 pages [ « | 1  2  3  4 ]
Topic: Religion's Newfound Restraint on Progress Previous Topic   Next Topic Topic: Interview with Handango's Will Pinnell


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us