A Challenge for all TDD programmers, ICFP

[Shayne Wissler]

"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:HFKJa.3058$I63.1473@newssvr19.news.prodigy.com...
Then requirements have little importance in software development.
Because when it comes right down to it, fulfilling "open ended" statements like the above are what makes the difference in the marketplace. Your reasoning exceeds my ability to comprehend, can you fill in some of
the missing details. Like: (1) how requirements have little importance;

Oh, I didn't say that. I said that given your apparent conception of them,
they would have no importance.
and (2) why you believe that the marketplace is driven by open ended statements.

The marketplace is driven by need fulfillment, not checking off "objective"
requirements. Whoever fills the actual need best, wins (well, not
universially, but that's a different subject).

When people talk about "objective" requirements, they're usually referring
to concrete, specific, spelled-out attributes for the product. But in the
real world, a range of attributes will fulfill the need. Rookie programmers
need the "requirements" spelled out, so they can mechanically crank out the
code and have a nice, orderly, clean little checklist to measure their
progress. Expert programmers understand the problem at hand, the real need
of the customer, so that they can create the best value, so they can keep an
eye out for opportunities to maximize the fidelity to that need (from which
they create the "spelled-out" requirements).

There's nothing at all wrong with "fuzzy" requirements. You just have to
hand them to the right person so he can turn them into your todo list for
you.


Shayne Wissler

[David Lightstone]

"Shayne Wissler" <thales000@yahoo.com> wrote in message
news:cfNJa.5029$e26.2560@rwcrnsc52.ops.asp.att.net... "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message news:HFKJa.3058$I63.1473@newssvr19.news.prodigy.com... Then requirements have little importance in software development. Because when it comes right down to it, fulfilling "open ended" statements
like the above are what makes the difference in the marketplace. Your reasoning exceeds my ability to comprehend, can you fill in some of the missing details. Like: (1) how requirements have little importance; Oh, I didn't say that. I said that given your apparent conception of them, they would have no importance.

(1) Well you decide what you stated, and then explain away to your hearts
content.

(2) As for your belief about my conception of requirements you can perhaps
also explain how you reached that erroneous conclusion.

The statement win the competion is not a requirment (for a system).
and (2) why you believe that the marketplace is driven by open ended statements. The marketplace is driven by need fulfillment, not checking off
"objective" requirements. Whoever fills the actual need best, wins (well, not universially, but that's a different subject).

Nobody disputes that need fulfillment is a driving factor. Between that need
and any implemented system there is an accomplishment strategy and a belief
that an integrated collection of characteristics will adequately fulfill the
need. You may call that collection whatever you wish, some people call them
requirements (because a priori they do not know if the collection fulfills
the need or whether the collection can be implemented)

When people talk about "objective" requirements, they're usually referring to concrete, specific, spelled-out attributes for the product. But in the real world, a range of attributes will fulfill the need.

Sorry but you are wrong here. There is an implied certainty in your
statement, a belief that the attributes will indeed be adequate. Few people
have such a priori knowledge. I do agree however that once a validated
solution to the need has been found, there will usually (but not always) be
a range of alternative solution obtainable as minor deviations from the
original solution. The problem here is that sometimes there just is no
solution
Rookie programmers need the "requirements" spelled out, so they can mechanically crank out
the code and have a nice, orderly, clean little checklist to measure their progress. Expert programmers understand the problem at hand, the real need of the customer, so that they can create the best value, so they can keep
an eye out for opportunities to maximize the fidelity to that need (from
which they create the "spelled-out" requirements).

You have completely neglected the scale of the development effort, and as a
result erroneously concluded that the coordination aspects can be
accomplished by having big, better, and smarter experts. There are capacity
limitations to consider. You haven't and as a result naievely believe that
the skills of an expert scale to a collection of experts. It is an nonlinear
orgainzational phenomena, roughly equivalent to - adding an additional
programmer will slow/speed (depending on the amount of required
communication amongst the programmers) things up
There's nothing at all wrong with "fuzzy" requirements. You just have to hand them to the right person so he can turn them into your todo list for you.

I suspect here that you are confusing the tasks of solution formulation
(stategy) and implementation
Shayne Wissler

[Shayne Wissler]

"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:cDXJa.714$Mc4.66197600@newssvr15.news.prodigy.com...
The marketplace is driven by need fulfillment, not checking off "objective" requirements. Whoever fills the actual need best, wins (well, not universially, but that's a different subject). Nobody disputes that need fulfillment is a driving factor. Between that
need and any implemented system there is an accomplishment strategy and a
belief that an integrated collection of characteristics will adequately fulfill
the need.

"Adequate" generally isn't good enough in the marketplace.
You may call that collection whatever you wish, some people call them requirements (because a priori they do not know if the collection fulfills the need or whether the collection can be implemented)

Requirements are a specific instance of a description of something that
could fulfill the need. It should always be understood that they aren't the
only possible set, that they can be refined or radically altered just like a
design can be.
When people talk about "objective" requirements, they're usually
referring to concrete, specific, spelled-out attributes for the product. But in
the real world, a range of attributes will fulfill the need. Sorry but you are wrong here. There is an implied certainty in your statement, a belief that the attributes will indeed be adequate.

That thought didn't occur anywhere in what I wrote.
Few people have such a priori knowledge. I do agree however that once a validated solution to the need has been found, there will usually (but not always)
be a range of alternative solution obtainable as minor deviations from the original solution.

You lack vision.
The problem here is that sometimes there just is no solution

For instance?
Rookie programmers need the "requirements" spelled out, so they can mechanically crank out the code and have a nice, orderly, clean little checklist to measure their progress. Expert programmers understand the problem at hand, the real
need of the customer, so that they can create the best value, so they can
keep an eye out for opportunities to maximize the fidelity to that need (from which they create the "spelled-out" requirements). You have completely neglected the scale of the development effort, and as
a

No, I have not.
result erroneously concluded that the coordination aspects can be accomplished by having big, better, and smarter experts. There are
capacity limitations to consider. You haven't and as a result naievely believe that the skills of an expert scale to a collection of experts. It is an
nonlinear orgainzational phenomena, roughly equivalent to - adding an additional programmer will slow/speed (depending on the amount of required communication amongst the programmers) things up

Thanks for trying, but your imaginations of what I'd say regarding scaling
issues are totally off.


Shayne Wissler

[David Lightstone]

"Shayne Wissler" <thales000@yahoo.com> wrote in message
news:U2_Ja.7049$Bg.4920@rwcrnsc54... "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message news:cDXJa.714$Mc4.66197600@newssvr15.news.prodigy.com... The marketplace is driven by need fulfillment, not checking off "objective" requirements. Whoever fills the actual need best, wins (well, not universially, but that's a different subject). Nobody disputes that need fulfillment is a driving factor. Between that need and any implemented system there is an accomplishment strategy and a belief that an integrated collection of characteristics will adequately fulfill the need. "Adequate" generally isn't good enough in the marketplace. You may call that collection whatever you wish, some people call them requirements (because a priori they do not know if the collection
fulfills the need or whether the collection can be implemented) Requirements are a specific instance of a description of something that could fulfill the need. It should always be understood that they aren't
the only possible set, that they can be refined or radically altered just like
a design can be.

Could???? You know a priori that they could. Good for you. Then you will
never need either an evolutionary or incremental development, just go
straight waterfall and be done with it. They are just a guess at the
characteristics.
When people talk about "objective" requirements, they're usually referring to concrete, specific, spelled-out attributes for the product. But in the real world, a range of attributes will fulfill the need. Sorry but you are wrong here. There is an implied certainty in your statement, a belief that the attributes will indeed be adequate. That thought didn't occur anywhere in what I wrote.

I guess you use "concrete, specific, spelled-out attributes" as a substitute
for, - soft, vague, sketched out attributes
Few people have such a priori knowledge. I do agree however that once a validated solution to the need has been found, there will usually (but not always) be a range of alternative solution obtainable as minor deviations from the original solution. You lack vision.

I am certain you will hve no difficulty explaining to the world your ability
to reach such foolish conclusions
The problem here is that sometimes there just is no solution For instance?

That you inquire for an example indicates the extent to which you are either
trolling or ignorant. I leave it for you to decide

Consult any book on control theory, you will readily learn that there are
necessary conditions which must be satisfied in order to successfully
develop a controller. I'm certain you can find phenomena which fail to
satisfy either the controllability or observability criteria (they will be
there as examples). Develop a controller for such a system would be a
ptretty good example

I can prove it, but I would speculate most software development shops fail
to satisfy those criteria. Ergo efforts to develop control systems for them
are bound to fail (say isn't extreme programmang an attempt to do just that) Rookie programmers need the "requirements" spelled out, so they can mechanically crank
out the code and have a nice, orderly, clean little checklist to measure their progress. Expert programmers understand the problem at hand, the real need of the customer, so that they can create the best value, so they can keep an eye out for opportunities to maximize the fidelity to that need (from which they create the "spelled-out" requirements). You have completely neglected the scale of the development effort, and
as a No, I have not. result erroneously concluded that the coordination aspects can be accomplished by having big, better, and smarter experts. There are capacity limitations to consider. You haven't and as a result naievely believe
that the skills of an expert scale to a collection of experts. It is an nonlinear orgainzational phenomena, roughly equivalent to - adding an additional programmer will slow/speed (depending on the amount of required communication amongst the programmers) things up Thanks for trying, but your imaginations of what I'd say regarding scaling issues are totally off.

Then shout to the world how - "Expert programmers understand the problem at
hand, the real need of the customer, so that They can create the best
value, so they can keep an eye out for opportunities to maximize the
fidelity to that need (from which they create the "spelled-out"
requirements)." - scales. The world awaits with baited breath
Shayne Wissler

[David Lightstone]

"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:rw_Ja.3013$mk3.1641@newssvr16.news.prodigy.com... "Shayne Wissler" <thales000@yahoo.com> wrote in message news:U2_Ja.7049$Bg.4920@rwcrnsc54... "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in
message news:cDXJa.714$Mc4.66197600@newssvr15.news.prodigy.com... > The marketplace is driven by need fulfillment, not checking off "objective" > requirements. Whoever fills the actual need best, wins (well, not > universially, but that's a different subject). Nobody disputes that need fulfillment is a driving factor. Between
that need and any implemented system there is an accomplishment strategy and a belief that an integrated collection of characteristics will adequately
fulfill the need. "Adequate" generally isn't good enough in the marketplace. You may call that collection whatever you wish, some people call them requirements (because a priori they do not know if the collection fulfills the need or whether the collection can be implemented) Requirements are a specific instance of a description of something that could fulfill the need. It should always be understood that they aren't the only possible set, that they can be refined or radically altered just
like a design can be. Could???? You know a priori that they could. Good for you. Then you will never need either an evolutionary or incremental development, just go straight waterfall and be done with it. They are just a guess at the characteristics. > When people talk about "objective" requirements, they're usually referring > to concrete, specific, spelled-out attributes for the product. But
in the > real world, a range of attributes will fulfill the need. Sorry but you are wrong here. There is an implied certainty in your statement, a belief that the attributes will indeed be adequate. That thought didn't occur anywhere in what I wrote. I guess you use "concrete, specific, spelled-out attributes" as a
substitute for, - soft, vague, sketched out attributes Few people have such a priori knowledge. I do agree however that once a validated solution to the need has been found, there will usually (but not
always) be a range of alternative solution obtainable as minor deviations from
the original solution. You lack vision. I am certain you will hve no difficulty explaining to the world your
ability to reach such foolish conclusions The problem here is that sometimes there just is no solution For instance? That you inquire for an example indicates the extent to which you are
either trolling or ignorant. I leave it for you to decide Consult any book on control theory, you will readily learn that there are necessary conditions which must be satisfied in order to successfully develop a controller. I'm certain you can find phenomena which fail to satisfy either the controllability or observability criteria (they will be there as examples). Develop a controller for such a system would be a ptretty good example I can prove it, but I would speculate most software development shops fail
sorry - can't prove (for those who can't correlate the inconsistency between
speculate and prove)
to satisfy those criteria. Ergo efforts to develop control systems for
them are bound to fail (say isn't extreme programmang an attempt to do just
that) > Rookie programmers > need the "requirements" spelled out, so they can mechanically crank out the > code and have a nice, orderly, clean little checklist to measure
their > progress. Expert programmers understand the problem at hand, the
real need > of the customer, so that they can create the best value, so they can keep an > eye out for opportunities to maximize the fidelity to that need
(from which > they create the "spelled-out" requirements). You have completely neglected the scale of the development effort, and as a No, I have not. result erroneously concluded that the coordination aspects can be accomplished by having big, better, and smarter experts. There are capacity limitations to consider. You haven't and as a result naievely believe that the skills of an expert scale to a collection of experts. It is an nonlinear orgainzational phenomena, roughly equivalent to - adding an additional programmer will slow/speed (depending on the amount of required communication amongst the programmers) things up Thanks for trying, but your imaginations of what I'd say regarding
scaling issues are totally off. Then shout to the world how - "Expert programmers understand the problem
at hand, the real need of the customer, so that They can create the best value, so they can keep an eye out for opportunities to maximize the fidelity to that need (from which they create the "spelled-out" requirements)." - scales. The world awaits with baited breath Shayne Wissler

[Shayne Wissler]

"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:rw_Ja.3013$mk3.1641@newssvr16.news.prodigy.com...
You may call that collection whatever you wish, some people call them requirements (because a priori they do not know if the collection fulfills the need or whether the collection can be implemented) Requirements are a specific instance of a description of something that could fulfill the need. It should always be understood that they aren't the only possible set, that they can be refined or radically altered just
like a design can be. Could???? You know a priori that they could. Good for you. Then you will never need either an evolutionary or incremental development, just go straight waterfall and be done with it. They are just a guess at the characteristics.

I imagine that you have a lot of fun playing chess with yourself. At any
rate, your ability to create strange new ideas to put into your opponent's
mouth is quite impressive.
Few people have such a priori knowledge. I do agree however that once a validated solution to the need has been found, there will usually (but not
always) be a range of alternative solution obtainable as minor deviations from
the original solution. You lack vision. I am certain you will hve no difficulty explaining to the world your
ability to reach such foolish conclusions

I am certain that "the world" (i.e., the 10 or so people who hang out in
these newsgroups) doesn't need an explanation of what is quite clear.
The problem here is that sometimes there just is no solution For instance? That you inquire for an example indicates the extent to which you are
either trolling or ignorant. I leave it for you to decide

When cornered, cry "troll". Well, I think all 10 of us are up on that
tactic. Try a new one.
Consult any book on control theory, you will readily learn that there are necessary conditions which must be satisfied in order to successfully develop a controller. I'm certain you can find phenomena which fail to satisfy either the controllability or observability criteria (they will be there as examples). Develop a controller for such a system would be a ptretty good example I can prove it, but I would speculate most software development shops fail to satisfy those criteria. Ergo efforts to develop control systems for
them are bound to fail (say isn't extreme programmang an attempt to do just
that)

If something is impossible, it isn't a real need.


Shayne Wissler

[Universe]

Shayne Wissler wrote:

"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message news:HFKJa.3058$I63.1473@newssvr19.news.prodigy.com...
Then requirements have little importance in software development. Because when it comes right down to it, fulfilling "open ended" statements like the above are what makes the difference in the marketplace. Your reasoning exceeds my ability to comprehend, can you fill in some of the missing details. Like: (1) how requirements have little importance;
Oh, I didn't say that. I said that given your apparent conception of them, they would have no importance.
and (2) why you believe that the marketplace is driven by open ended statements.
The marketplace is driven by need fulfillment, not checking off "objective" requirements. Whoever fills the actual need best, wins (well, not universially, but that's a different subject).
When people talk about "objective" requirements, they're usually referring to concrete, specific, spelled-out attributes for the product. But in the real world, a range of attributes will fulfill the need. Rookie programmers need the "requirements" spelled out, so they can mechanically crank out the code and have a nice, orderly, clean little checklist to measure their progress. Expert programmers understand the problem at hand, the real need of the customer, so that they can create the best value, so they can keep an eye out for opportunities to maximize the fidelity to that need (from which they create the "spelled-out" requirements).

Interesting the fantasies surrounding large-scale software engineering
that's part of an org with a mature, scientific, repeatble and
*objecttively* improvable sw-eng process.

Elliott
--
OO software rests upon class abstractions expressed in class method
*behaviors*. The sum of class method behaviors is the overall class
*role*. Class role should have primary responsibility for managing class
data such that the impact of class data is driven by the operation of
class methods.
~*~ Get with OO fundamentals, get OO. ~*~
-
We Don't Need US Fat Cat's Geopolitical Hegemony!
People of the World Demand US Stop Now!
-
* http:\\www.radix.net/~universe *
@Elliott 2003 my comments ~ newsgroups+bitnet OK

[David Lightstone]

"Shayne Wissler" <thales000@yahoo.com> wrote in message
news:LH_Ja.8723$XG4.8573@rwcrnsc53... "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message news:rw_Ja.3013$mk3.1641@newssvr16.news.prodigy.com... Consult any book on control theory, you will readily learn that there
are necessary conditions which must be satisfied in order to successfully develop a controller. I'm certain you can find phenomena which fail to satisfy either the controllability or observability criteria (they will
be there as examples). Develop a controller for such a system would be a ptretty good example If something is impossible, it isn't a real need.

Unfortunately you do not a priori know that it is impossible
Shayne Wissler