From: David Lightstone (david.lightstone@prodigy.net)
Date: Sun Apr 13 2003 - 07:04:03 EST
>
> On Wednesday, April 9, 2003, at 09:47 AM, Jane L Huang wrote:
> > "Agile methods have taught us a great deal about automated testing,
> > both at the unit level and at the system level. Agile methods have
> > also taught us that well written automatic tests are better at
> > specifying requirements than prose documents are."
> >
> > He then goes on to claim that "a good automated test can also be a
> > good requirements document."
>
> I'm another person who's said things like that, but I'm increasingly
> coming to think that's not the right way to talk. I don't like the
> words "specifying" or "document". I think they sidetrack discussion.
>
> 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. 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
This archive was generated by hypermail 2.1.6 : Mon Apr 14 2003 - 09:00:10 EST