| View previous topic :: View next topic |
| Author |
Message |
server
Guest
|
 Posted: Tue Jun 24, 2003 5:50 am Post subject: A Challenge for all TDD programmers, ICFP |
 |
|
| message unavailable |
|
| |
|
 Back to top |
Shayne Wissler
Guest
|
| Posted: Tue Jun 24, 2003 5:50 am Post subject: Re: A Challenge for all TDD programmers, ICFP |
|
|
"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:HFKJa.3058$I63.1473@newssvr19.news.prodigy.com...
| Quote: | 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.
| Quote: | 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 |
|
| |
|
| Back to top |
Uncle Bob (Robert C. Mart
Guest
|
| Posted: Tue Jun 24, 2003 6:05 am Post subject: Re: Extreme programming and interfaces. |
|
|
"4Space" <4Space@NoSpam.com> might (or might not) have written this on
(or about) Tue, 10 Jun 2003 14:36:29 GMT, :
| Quote: | I'm hoping to get some opinions on this subject.
One of the points of Extreme programming is that you should refactor
mercilessly. How does this apply with interfaces? I've read some XP
resources that state you should not be afraid to change an interface (change
is the only constant in software etc), and some (admittedly not XP
resources) that assert that interfaces, once published, should be immutable.
For class libraries, I don't think it's feasible to alter design whilst
guarunteeing that the interface will not change.
|
Published interfaces are hard to change. Therefore interfaces must be
pretty stable before you publish them. There are two schools of
thought on how to get the interfaces stable.
1. Lots of up front design and thought experiments.
2. Develop the interface in conjunction with a small but
representative population of programs that use it. Publish it once it
stabilizes for those users.
The second is the XP way.
Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python | |
|
| |
|
| Back to top |
Uncle Bob (Robert C. Mart
Guest
|
| Posted: Tue Jun 24, 2003 6:39 am Post subject: Re: A Challenge for all TDD programmers, ICFP |
|
|
"John W. Wilkinson" <john.wilkinson@spirentcom_removethis.com> might
(or might not) have written this on (or about) Mon, 23 Jun 2003
08:40:30 +0100, :
| Quote: | Is TDD an appropriate technique for a project such as this contest where:
1. the requirements are fully known and fixed
2. the duration of the project will be very short, ie 3 days
2. there is no maintenance phase
|
Yes, it's a very applicable approach for a task with those three
attributes. Programmers write the tests to make sure that their code
works as expected. (Frankly it's astounding to me that anyone would
argue against such a policy.) Programmers write tests *first* to make
sure that they know what the code they are about to write is supposed
to do.
| Quote: | The main benefit of TDD, so I am told, is to produce code that can be more
easily maintained/refactored? Hence its use in Agile methodologies that are
aimed at projects with uncertain or changing requirements.
|
That's one reason, but there are others. Writing tests first can be a
good way to sneak up on a simpler solution than one had anticipated.
Writing tests first is a good way to make sure you know precisely what
you are about to write. Writing tests first is also a very technique
for supporting changes to the code, even when the requirements don't
change.
Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python | |
|
| |
|
| Back to top |
Dave Harris
Guest
|
| Posted: Tue Jun 24, 2003 7:35 am Post subject: Re: A Challenge for all TDD programmers, ICFP |
|
|
olczyk@interaccess.com (Thaddeus L Olczyk) wrote (abridged):
| Quote: | There is no place in the rules where it says
that "The program should be faster than competing programs".
|
The 3rd (2000) contest was the ray-tracer. Some quotes from the task
description:
Submissions will be evaluated on their correctness, speed
of execution, and set of implemented GML features. [...]
Judging of the contest entries will proceed in three phases. [...]
The third phase will compare the performance and implemented
features of the submissions.
See http://www.cs.cornell.edu/icfp/task.htm for the full text. It's clear
that speed is an important winning criteria, second only to correctness.
The 4th (2001) contest uses speed as a tie-breaker.
Remember that the task is different each year. We don't yet know the 6th
(2003) task. When I wrote: "Usually they are a bit woolly, like...", I was
giving typical examples from previous years. Performance usually plays a
role, partly for practical reasons (they have to get all the entries run
in a reasonable time), and partly because they want to dispell the myth
that functional languages are slow.
One of my favourite comments comes from the "CuttySark" team in 2000.
Their program took over 3 days on one of the tests.
We are proud to be one of (or the only) entries for which
computation of the images takes longer than the programming
contest itself: it was hard to code, it should be hard to run  .
They were using Python.
| Quote: | Nor does it say "it's robots should beat the other robots".
|
The 5th (2002) contest task description says,
The winner of a game is the robot who has the highest score at
the end of the game.
I paraphrase this by saying the robot with the highest score beats the
other robots. My robot can beat your robot by getting a higher score on a
given map, even if both robots are never on the map together.
The 4th (2001) contest wasn't about robots, but it also had open-ended
criteria. It was about optimisation; the winning program had to produce
smaller output than the others.
| Quote: | It just another apriori excuse by an incompetent programmer for
failing at something.
|
Actually, I wasn't making an excuse. I was doing the opposite - showing
how the winning criteria were open-ended, making the ICFP contest the kind
of project where test-driven design should excel.
-- Dave Harris, Nottingham, UK |
|
| |
|
| Back to top |
Dave Harris
Guest
|
| Posted: Tue Jun 24, 2003 7:35 am Post subject: Re: A Challenge for all TDD programmers, ICFP |
|
|
jgrigg@mo.net (Jeff Grigg) wrote (abridged):
| Quote: | ...which is a good environment for Test Driven Development (TDD).
|
Absolutely. Maybe I should have spelt that out, for the hard of thinking.
-- Dave Harris, Nottingham, UK |
|
| |
|
| Back to top |
4Space
Guest
|
| Posted: Tue Jun 24, 2003 3:31 pm Post subject: Re: Extreme programming and interfaces. |
|
|
| Quote: | 1. Lots of up front design and thought experiments.
2. Develop the interface in conjunction with a small but
representative population of programs that use it. Publish it once it
stabilizes for those users.
The second is the XP way.
|
Yeah, I think that number 2 is the way to go. The problem I came up against,
particularly from some developers was that they believed as soon as they
linked to an interface, it should be immutable. I guess we need to be able
to do more prototyping with the various internal customers to get an
interface hammered out, then publish it for testing, then when it appears
stable, decalre it immutable.
btw, I insisted that our team swear an oath by placing their right hands on
your 'Agile Software Development' book (well strictly speaking, it's my
book, but you get my meaning.) and declaring an allegiance to the agile
process. If this doesn't increase our productivity by 3000%, I may lose
their commitment.
Cheers,
4Space |
|
| |
|
| Back to top |
Daniel Parker
Guest
|
| Posted: Tue Jun 24, 2003 4:11 pm Post subject: Re: Extreme programming and interfaces. |
|
|
"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o.b@objectmentor.com> wrote in
message news:vm8ffvcilieegka7aepcoremesqiu795b9@4ax.com...
| Quote: |
Published interfaces are hard to change. Therefore interfaces must be
pretty stable before you publish them. There are two schools of
thought on how to get the interfaces stable.
1. Lots of up front design and thought experiments.
2. Develop the interface in conjunction with a small but
representative population of programs that use it. Publish it once it
stabilizes for those users.
The second is the XP way.
You don't need the representative population of programs, you need the use |
cases, what the programs will require of the interface, and experience
surely suggests that it is possible to define that without actually building
the programs. Many interfaces suffer from being too much slanted to the
producer of the interface rather than the more numerous and later arriving
consumers, and it is hard to see how a code centric approach would improve
upon that. The "small but representative population of programs that use
it" is not likely to be all that representative in the early days; it is
hard to see how that could be the case unless you've done a considerable
amount of "up front design," or rather up front coding which to XP'ers often
seems to be the same thing.
Regards,
Daniel Parker |
|
| |
|
| Back to top |
Daniel Parker
Guest
|
| Posted: Tue Jun 24, 2003 5:07 pm Post subject: Re: database design resources |
|
|
"John Davis" <jrefactor@hotmail.com> wrote in message
news:3ef4b4d4@news.totallyobjects.com...
| Quote: | I am new to database design, and as well as object-oriented design. I want
to know if there are any good database design books, or resources
available
on the web.
Thanks!
I'd recommned |
Handbook of Relational Database Design
by Candace C. Fleming, Barbara von Halle
Regards,
Daniel Parker |
|
| |
|
| Back to top |
4Space
Guest
|
| Posted: Tue Jun 24, 2003 5:37 pm Post subject: Re: Extreme programming and interfaces. |
|
|
| Quote: | You don't need the representative population of programs, you need the use
cases, what the programs will require of the interface, and experience
surely suggests that it is possible to define that without actually
building
the programs. Many interfaces suffer from being too much slanted to the
producer of the interface rather than the more numerous and later arriving
consumers, and it is hard to see how a code centric approach would improve
upon that. The "small but representative population of programs that use
it" is not likely to be all that representative in the early days; it is
hard to see how that could be the case unless you've done a considerable
amount of "up front design," or rather up front coding which to XP'ers
often
seems to be the same thing.
|
I think I'd contend that there would likely be a gap between the Use Cases
and the code, a gap that would be best bridged by prototyping and developing
in conjuntion with the representative client cross-section.
Cheers,
4Space. |
|
| |
|
| Back to top |
David Lightstone
Guest
|
| Posted: Tue Jun 24, 2003 5:38 pm Post subject: Re: A Challenge for all TDD programmers, ICFP |
|
|
"Shayne Wissler" <thales000@yahoo.com> wrote in message
news:cfNJa.5029$e26.2560@rwcrnsc52.ops.asp.att.net...
| Quote: |
"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).
| Quote: |
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)
| Quote: |
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
| Quote: | 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
| Quote: |
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
|
|
| |
|
| Back to top |
David Lightstone
Guest
|
| Posted: Tue Jun 24, 2003 5:45 pm Post subject: Re: A Challenge for all TDD programmers, ICFP |
|
|
"Thaddeus L Olczyk" <olczyk@interaccess.com> wrote in message
news:1jvefv8sf1p7ol6gubs0utd6rcob134fts@4ax.com...
| Quote: | On Mon, 23 Jun 2003 20:05:55 GMT, "David Lightstone"
david._NoSpamlightstone@prodigy.net> wrote:
"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20030623183133.12175A@brangdon.madasafish.com...
john.wilkinson@spirentcom_removethis.com (John W. Wilkinson) wrote
(abridged):
Is TDD an appropriate technique for a project such as this contest
where:
1. the requirements are fully known and fixed
They aren't, really, in this contest. Usually they are a bit woolly,
like,
"The program should be faster than competing programs" or "its robots
should beat the other robots". They are open-ended.
Don't be silly. Those are not requirements.
You mean "those are not the requirements"?
^^^
|
No I mean exactly what I stated, they are not requirements. They are an
evaluation metric for a competition. They do not in any way what-so-ever
serve to describe attributes of the system in need of development. They do
however describe the relationship that the developed system would have to
alternatively developed systems.
As a rhetorical question consider - Please describe one attibute derivable
from the statement, and indicate how it was derived.
| Quote: |
Because they are not. There is no place in the rules where it says
that "The program should be faster than competing programs".
The only place in the rules it says anything about time is the
requirement that each move not take more than 1 second of CPU
time. People asked and it was clarified that this meant averaged
over the period of delivering packages ( the robots burned fuel, when
the fuel ran out the move was over ), rather than each move using
less then one second ( so one move might take 2.98 seconds, but if the
next took 0.01 each you were OK ). The second place entry actually
used the whole second. After it finished calculating it's move it
used the rest of the time to project it's options. So "how fast" had
little to do with it. Just a time limit. Typical of many real
programs.
Nor does it say "it's robots should beat the other robots". It says
the winning robot will be the one that scores the most over a
series of different scenarios. ( Where the circumstances vary greatly.
One scenario might be where the map is a maze like structure. In
another the terrain is wide open. The robot might have lots of fuel
but only carry one package at a time. In another the robot carries
many packages but has little fuel. The point is to write code that
optimizes the score. In fact it's a traveling salesman problem with
some unique weighting problems. ).
It just another apriori excuse by an incompetent programmer for
failing at something.
|
I kind of think we are not in disagreement, we seem to be focusing on
different aspects
| Quote: |
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once. |
|
|
| |
|
| Back to top |
David Lightstone
Guest
|
| Posted: Tue Jun 24, 2003 5:49 pm Post subject: Re: A Challenge for all TDD programmers, ICFP |
|
|
"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20030624003735.5515A@brangdon.madasafish.com...
| Quote: | david._NoSpamlightstone@prodigy.net (David Lightstone) wrote (abridged):
"The program should be faster than competing programs" or "its robots
should beat the other robots". They are open-ended.
Don't be silly. Those are not requirements.
Whatever you call them, they are things you are required to do in order to
win.
|
The English language is such a marveleous thing.
Requirements describe the system being developed, not the tasks which the
developer must perform in order to accomplish the development
Requirements describe the system being developed, not the reason the system
needs to be developed
| Quote: |
-- Dave Harris, Nottingham, UK |
|
|
| |
|
| Back to top |
Christopher Barber
Guest
|
| Posted: Tue Jun 24, 2003 8:06 pm Post subject: Re: Extreme programming and interfaces. |
|
|
"Daniel Parker" <danielaparker@windupbird.com> writes:
| Quote: | "Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o.b@objectmentor.com> wrote in
message news:vm8ffvcilieegka7aepcoremesqiu795b9@4ax.com...
Published interfaces are hard to change. Therefore interfaces must be
pretty stable before you publish them. There are two schools of
thought on how to get the interfaces stable.
1. Lots of up front design and thought experiments.
2. Develop the interface in conjunction with a small but
representative population of programs that use it. Publish it once it
stabilizes for those users.
You don't need the representative population of programs, you need the use
cases, what the programs will require of the interface, and experience
surely suggests that it is possible to define that without actually building
the programs.
|
No, experience suggests quite the opposite! It is extremely difficult to
correctly identify all of the relevant use cases without actually trying to
build something. On the other hand, prototyping will also not identify all of
the issues either. In practice, you really need to combine the two approaches
to design good interfaces.
- Christopher |
|
| |
|
| Back to top |
Shayne Wissler
Guest
|
| Posted: Tue Jun 24, 2003 8:24 pm Post subject: Re: A Challenge for all TDD programmers, ICFP |
|
|
"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:cDXJa.714$Mc4.66197600@newssvr15.news.prodigy.com...
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | The problem here is that sometimes there just is no
solution
|
For instance?
| Quote: | 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.
| Quote: | 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 |
|
| |
|
| Back to top |
|
