From: Brian Marick (marick@testing.com)
Date: Tue Apr 15 2003 - 00:40:40 EST
On Saturday, April 12, 2003, at 04:04 PM, David Lightstone wrote:
>> I don't think that the agile people intend the test suite to mirror or
>> represent an understanding of the problem to be solved. (I think most
>> people who write requirements documents do intend that.)
>>
>> I think the agile people intend the test suite to provoke correct
>> actions over the course of the project (including during maintenance).
>> One of my mottos is "An effective set of tests is one that provokes a
>> programmer to write the right program."
>
> I have no idea what this means.
Let me make an analogy. Phil Agre has a PhD from the MIT AI Lab. His dissertation program (as described in his _Computation and Human Experience_) played a video game competently. Unusually for programs of that type, it contained no "world model" (model of the state of the screen and pieces). Instead, it played by "looking" only just around an area of focus (a very limited part of the "world") and making routine and immediate responses rather than executing larger plans. He uses this to argue that competent performance doesn't necessarily require a world model. He uses other sources to argue that the importance of world models and larger plans is generally overrated when we talk about intelligent-seeming behavior. (I hope I've summarized well.)
So here's the analogy. Playing the game is constructing software over a series of iterations. Playing without a world model is playing without a model of the problem (that is, without universally understood requirements). Playing competently means satisfying the people who are paying for the software more than they are usually satisfied.
Now, people are not Lisp subroutines, and they have the habit of expressing themselves in terms of models. Can't stop 'em. But the hope is for a process that is robust in the face of incompleteness, ambiguity, conflicting understanding, and all those other things that plague requirements engineering.
This is very different from "depending on serendipity", as you put it below.
Now, as you point out, there are situations in which problem models are needed (just as Agre believes that some intelligent-seeming behavior like puzzle solving uses conventional planning and world models). The trick is to fit your strategy to the problem at hand. I think it's way too early to conclude that the agile methods only apply to small, low quality projects, as some people on this list seem to have.
Another possibly relevant reference: _Cognition in the Wild_ by Hutchins. A lot of it talks about group navigation (a problem solving activity) and describes how the people who do it use tools to reduce their cognitive load. They replace representation with other means to their end. For example, they lay out maps in a way that allows them to think less and understand less. In a similar way, (some) agile people rely upon tests as a tool to help them get where they're going, even though the tests don't directly represent the problem to be solved.
> Sounds nice, but I think it is a significant
> misdirection. (just can't clearly articulate why I believe this).
> Clearly
> (because Agile is referenced) there is a simultaneous evolution of the
> "effective set of tests" and the "right program" (quotes because of the
> inherant ambiguities present in the terms). The only question is
> whether
> there is a simultaneous evolution of the intended purpose of the
> program
> (its goal).
>
> If there is no evolution of the intended purpose, it might just be a
> good
> program construction strategy.
>
> If there is simultaneous evolution of the intended purpose, the
> mechanism
> which serves to construct the effective tests quite likely requires
> knowledge that can only be obtained a posteriori to the implementation.
> Hence my concern about possible misdirection
>
> As a possibly poor analogy. It is not possible to transform a doughnut
> into
> a sphere by means of smooth deformations. (recalled from a haphazzard
> study
> of algebraic topology and homotopy theory). This leads me to believe
> that
> there will be equivalence classes of programs which can easily be
> transformed into each other. It also leads me to believe that there
> will be
> programs which can not easily be transformed into easy other using an
> evolutionary strategy. Ergo if you wish to avoid unnecessary rework
> (non-smooth deformations), you have to know the equivalence class of
> the
> program. I don't know whether this is reasonable. A history of poorly
> maintained programs leads me to believe efforts to transform programs
> representative of one equivalence class into a representative of
> another
> equivalence class occures quite often. Ergo assuming general
> applicability
> is a simultaneous assumption of a posteriori knowledge.
>
> The alternative interpretation is assuming a control system involving
> a very
> sophisticated feedback mechanism. There is no guarentee that the fault
> observation mechanism, people, collectively implement a good observer
> (in
> the
> sense of control theory) for the state of the program under
> development.
>
>>
>> Does that require that the programmer "truly understand" the problem?
>> Maybe. But understanding isn't the goal. If the programmer could write
>> the right program without understanding the problem, that would be
>> fine.
>
> Also find with me. Depending upon serendipity, however, is not a
> reliable
> engineering strategy
>
>
>
>
> -----------------------------------------------------------------------
> --------
> To send a message to this mailing list send it to
> re-online@it.uts.edu.au.
> To unsubscribe from this mailing list, email majordomo@it.uts.edu.au
> with the
> message `unsubscribe re-online' in the BODY of the mail.
>
>
I'm program chair or cohost of these events: PLoP: <http://jerry.cs.uiuc.edu/~plop/plop2003/> Analogy Fest: <http://www.visibleworkings.com/analogyfest/> Please join me.
This archive was generated by hypermail 2.1.6 : Mon Apr 21 2003 - 09:00:10 EST