A challenge to proponents of Unit Testing.
Thaddeus L Olczyk
Of all the tenets of XP the one that I would have said
that I was most agreement with.
The one property that those who know me generally attribute
to me is meticulousness, and as a part of being meticulous I take Unit
Tests very seriously.
But more and more I've begun to doubt the efficacy of having a
complete test suite. I've never left a project with a set of
regressive tests that was anywhere near complete, and I begin
to doubt that many people do. ( Of course there is the exception
of a project that expects ten LOC per month per programmer,
ala old style COBOL programs. Since the code is so little, it is
easier to generate tests for it. Most projects nowadays require
at least 1000 LOC per programmer-month. )
The only open-source project I know of that does do unit testing is
gcc. And it does not use the "XP" unit testing tools (JUnit, SUnit,
CppUnit etc.), but uses expect instead.
So I offer a challenge. There are many, many open source projects:
programming languages ( python, ruby, the squeak vm, clisp etc.),
utilities ( ls, diff, grep, wc, etc. ), tools ( gimp, emacs, vi etc. )
and many others. Choose one where the source code is over 500
lines ( any less and it would hardly by a test ) and setup a system of
unit tests for it. If the code is not appropriately designed for unit
testing, then the onus is on you to refactor the project so that it
can be unit tested
The system of unit tests will be judged complete when the tests are
1) fully regressive, 2) comprehensive, and the maintainer of the
project is comfortable adding unit tests.
Questions about the nature of the challenge are welcome. Suggestions
for criteria for the challenge are welcome. Excuses are not. Nor are
explanations of projects where no one can see the code ( talk is
cheap, but many consultants are not and often IT managers are not
happy with the results of the consultants efforts ). Projects where
the person did not write a significant amount of the source on their
own are not welcome. ( The number of projects where: some "leader"
[ an IT manager, a consultant etc. ] claims that his process is the
major reason for the success of the project; but the programmers in
the
trenches say that it is the result of skunk works, extremely late
hours etc. and happened in spite of the process not because of it; are
legion. )
In other words it's time to put up, shut up or act like the kind of
consultant that gives consultants a bad name.
John Roth
"Thaddeus L Olczyk" <olc...@interaccess.com> wrote in message
news:3bfc87a6...@nntp.interaccess.com...
> For a long time I've been a proponent of Unit Testing.
Goody. So have a lot of people that never managed to
make it work without draconian management.
> Of all the tenets of XP the one that I would have said
> that I was most agreement with.
From what you say, you don't understand the XP spin on
unit testing.
> The one property that those who know me generally attribute
> to me is meticulousness, and as a part of being meticulous I take Unit
> Tests very seriously.
As far as meticulousness goes, see the comments about
your use of English.
> But more and more I've begun to doubt the efficacy of having a
> complete test suite. I've never left a project with a set of
> regressive tests that was anywhere near complete.
I presume you meant regression tests. I hesitatate to think of
what a regressive test might be...
Regression tests are not the same as unit tests, although they
can be included in the unit test suite. Regression tests are
specifically defined as tests that insure that you don't ship an
update with bugs that you fixed in a prior update.
Whether people do or not is kind of irrelevant to the point you
are trying to make.
> The only open-source project I know of that does do unit testing is
> gcc. And it does not use the "XP" unit testing tools (JUnit, SUnit,
> CppUnit etc.), but uses expect instead.
gcc got started a long, long time before the xUnit test tools were
availible. I'd question whether expect qualifies as a unit test tool in
any case; it is fine as an acceptance test tool in certain environments,
of which Unix command line programs are one such case. If it is
being used as a unit test tool (defining unit tests as tests of code
that
isn't directly accessable from the user interface, without invoking
large parts of the application in question,) then it's being used to
run the test suite remotely.
> So I offer a challenge. There are many, many open source projects:
> programming languages ( python, ruby, the squeak vm, clisp etc.),
> utilities ( ls, diff, grep, wc, etc. ), tools ( gimp, emacs, vi etc. )
> and many others. Choose one where the source code is over 500
> lines ( any less and it would hardly by a test ) and setup a system of
> unit tests for it. If the code is not appropriately designed for unit
> testing, then the onus is on you to refactor the project so that it
> can be unit tested
Doesn't make sense in context. XP requires that the unit tests
be written in conjunction with the code. You're talking about adding
unit tests to a project that doesn't have any, and XP specifically
points that out as a practice that you shouldn't do.
> The system of unit tests will be judged complete when the tests are
> 1) fully regressive, 2) comprehensive, and the maintainer of the
> project is comfortable adding unit tests.
Are you sure you didn't learn how to create challenges on alt.astrology?
> Questions about the nature of the challenge are welcome. Suggestions
> for criteria for the challenge are welcome. Excuses are not. Nor are
> explanations of projects where no one can see the code ( talk is
> cheap, but many consultants are not and often IT managers are not
> happy with the results of the consultants efforts ). Projects where
> the person did not write a significant amount of the source on their
> own are not welcome.
> ( The number of projects where: some "leader"
> [ an IT manager, a consultant etc. ] claims that his process is the
> major reason for the success of the project; but the programmers in
> the trenches say that it is the result of skunk works, extremely late
> hours etc. and happened in spite of the process not because of it; are
> legion. )
One of the XP practices is the 8 hour day. XP is a package of
practices, and people who claim to be practicing XP but work
their people more than 8 hours a day are not doing so.
> In other words it's time to put up, shut up or act like the kind of
> consultant that gives consultants a bad name.
The third clause in your syntax doesn't make sense.
Even as a troll, it's kind of lame.
John Roth
>
>
>
>
>
Keith Ray
"John Roth" <john...@ameritech.net> wrote:
> be written in conjunction with the code. You're talking about adding
> unit tests to a project that doesn't have any, and XP specifically
> points that out as a practice that you shouldn't do.
Not precisely true.
The usual XP advice for untested code is to add acceptance tests, and
whenever the untested code needs to be bug-fixed, enhanced, modified, or
refactored, add unit tests as needed (when possible).
Kent Beck
I believe Ant and JUnit both meet your criteria (although I'd like to write
more JUnit tests).
Kent
Christophe Thibaut
The funny part comes when you want to refactor a code that has no unit test
attached to it. One major reason for not testing code is that it is written
in such a way that you cannot find out how to define or handle unit test
fixtures for it. Simply said, people don't test because they don't see
clearly what they coded.
Refactoring is the remedy. But refactoring needs a safety belt wich is ...
a lot of unit tests.
David B Lightstone
"Christophe Thibaut" <cthi...@club-internet.fr> wrote in message
news:3BFD7337...@club-internet.fr...
Safety belt indeed!!! The absense of one makes refactoring,
reengineering etc. one of the more difficult tasks. So this begs
the question, is the challenge a realistic goal? How on earth
are you going to know if you have refactored something correctly,
unless you have adequate documentation of some form or another
(unit test, specification, requirements, or design)?
>
>
Keith Ray
"David B Lightstone" <david.li...@prodigy.net> wrote:
[...]
>
> Safety belt indeed!!! The absense of one makes refactoring,
> reengineering etc. one of the more difficult tasks. So this begs
> the question, is the challenge a realistic goal? How on earth
> are you going to know if you have refactored something correctly,
> unless you have adequate documentation of some form or another
> (unit test, specification, requirements, or design)?
Acceptance tests provide the necessary testing when unit tests are not
available.
David B Lightstone
"Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
news:k1e2i3t4h5r6a7y-12...@news1.rdc1.sfba.home.com...
Acceptance Test, as I understand the term, and XP may be using an XP
variation on the term, an acceptance test is performed by the
customer.
Unless there is some sort of agreement as to what will be developed
(ie rigerous requirement documents), the Acceptance Test Development
Criteria and the XP Software Development Requirements will be a bit
different. Defineitely not suitable of safety critical system. (Its
not the bug you tested for that will kill you, its the behavior that
you didn't anticipate. Eventually the system will surprise you) So
what is being tested?
Peter Hansen
>
> "Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote:
> >
> > Acceptance tests provide the necessary testing when unit tests are
> > not available.
>
> Acceptance Test, as I understand the term, and XP may be using an XP
> variation on the term, an acceptance test is performed by the
> customer.
XP defines it the same way, although one might better say "performed
_for_ the customer". It is also _defined_ by the customer, or at
least with the customer.
> Unless there is some sort of agreement as to what will be developed
> (ie rigerous requirement documents), the Acceptance Test Development
> Criteria and the XP Software Development Requirements will be a bit
> different.
Why develop a rigorous requirements document when the customer
has already developed a rigorous acceptance test? (i.e. the
test encodes the requirements) The software is designed to
pass the test, so by definition it meets the requirements.
--
----------------------
Peter Hansen, P.Eng.
pe...@engcorp.com
David B Lightstone
"Peter Hansen" <pe...@engcorp.com> wrote in message
news:3BFD9E22...@engcorp.com...
Test encode something, when they are validated they encode the
requirements.
Against what is the Acceptance Test validated, and by whom?
How do you know the tests are consistent?
When the product fails a test is it because the test was bad, or the
product?
John Roth
"David B Lightstone" <david.li...@prodigy.net> wrote in message
news:8AeL7.207$yw7.28...@newssvr16.news.prodigy.com...
>
> "Christophe Thibaut" <cthi...@club-internet.fr> wrote in message
> news:3BFD7337...@club-internet.fr...
> > Refactoring is the remedy. But refactoring needs a safety belt
> > which is ... a lot of unit tests.
> >
That's not exactly correct. Refactoring itself can be done with
whatever tests are availible. The XP practice of "merciless
refactoring" requires the safety net of comprehensive, automated
unit tests, otherwise you are going to be justifiably cautious.
If you're going to do refactoring in an XP environment on
a legacy project, then you need to develop the unit tests for
everything you touch as part of the refactoring. While that's
more work that it would be if you already had the tests, it
meets the XP goal of not doing things until you need to. The
first time you need those unit tests is when you refactor that code.
> Safety belt indeed!!! The absense of one makes refactoring,
> reengineering etc. one of the more difficult tasks. So this begs
> the question, is the challenge a realistic goal? How on earth
> are you going to know if you have refactored something correctly,
> unless you have adequate documentation of some form or another
> (unit test, specification, requirements, or design)?
That's one of the reasons why he suggested an existing open
source project, I suspect. You've got a known target, and if you
use a project that is known to be reasonably clean (and the ones
on his list that I recognize have that reputation) then you're not
trying to reproduce bugs. Python, for example, has an excellent
set of documentation, and (I believe) a reasonable set of tests.
John Roth
John Roth
> >
> > "Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote:
> > >
> > > Acceptance tests provide the necessary testing when unit tests are
> > > not available.
> >
> > Acceptance Test, as I understand the term, and XP may be using an XP
> > variation on the term, an acceptance test is performed by the
> > customer.
>
> XP defines it the same way, although one might better say "performed
> _for_ the customer". It is also _defined_ by the customer, or at
> least with the customer.
I used to think so, until I saw Robert Martin's comments in another
thread. He seems to be recommending that the programming team
create a specialized language that the customer (and QA department,
if one is involved) can use to specify the tests. It's an interesting
point, because then the programming team can be responsible for
running the tests and reporting on their success (or not,) while the
customer retains responsibility for directly specifying the content of
the tests.
We may be saying the same thing, though.
John Roth
Peter Hansen
>
> "Peter Hansen" <pe...@engcorp.com> wrote:
> > David B Lightstone wrote:
> > >
> > > Acceptance Test, as I understand the term, and XP may be using an XP
> > > variation on the term, an acceptance test is performed by the
> > > customer.
> >
> > XP defines it the same way, although one might better say "performed
> > _for_ the customer". It is also _defined_ by the customer, or at
> > least with the customer.
>
> I used to think so, until I saw Robert Martin's comments in another
> thread. He seems to be recommending that the programming team
> create a specialized language that the customer (and QA department,
> if one is involved) can use to specify the tests. It's an interesting
> point, because then the programming team can be responsible for
> running the tests and reporting on their success (or not,) while the
> customer retains responsibility for directly specifying the content of
> the tests.
>
> We may be saying the same thing, though.
Yes, we are. :-)
Max Ischenko
In comp.object Thaddeus L Olczyk <olc...@interaccess.com> wrote:
> So I offer a challenge. There are many, many open source projects:
> programming languages ( python, ruby, the squeak vm, clisp etc.),
> utilities ( ls, diff, grep, wc, etc. ), tools ( gimp, emacs, vi etc. )
> and many others. Choose one where the source code is over 500
> lines ( any less and it would hardly by a test ) and setup a system of
> unit tests for it. If the code is not appropriately designed for unit
> testing, then the onus is on you to refactor the project so that it
> can be unit tested
Ruby uses Rubicon testsuite for the language itself, written of course in
Ruby.
>
--
"Besides, I think [Slackware] sounds better than 'Microsoft,' don't you?"
(By Patrick Volkerding)
Thaddeus L Olczyk
wrote:
>
>Ruby uses Rubicon testsuite for the language itself, written of course in
>Ruby.
>
I have a project that I wanted to try Ruby out on. One thing that
impressed me was the smallness of libraries. I would click on
OK in the file select dialog and even before I could look down the
download was finished.
Impressive considering I had just spent 14+ hours downloading the
CinCom VisualWorks Smalltalk ( free noncommercial edition )
( sorry James ).
I'll take a close look.
James A. Robertson
To solve this very problem we are in the process of setting up a
non-commercial edition annual subscription. For a nominal annual fee,
we'll send a CD with each new release
John Roth
"Max Ischenko" <m...@malva.com.ua> wrote in message
news:8jukt9...@barloo.malva.com.ua...
>
> In comp.object Thaddeus L Olczyk <olc...@interaccess.com> wrote:
>
> > So I offer a challenge. There are many, many open source projects:
> > programming languages ( python, ruby, the squeak vm, clisp etc.),
> > utilities ( ls, diff, grep, wc, etc. ), tools ( gimp, emacs, vi
etc. )
> > and many others. Choose one where the source code is over 500
> > lines ( any less and it would hardly by a test ) and setup a system
of
> > unit tests for it. If the code is not appropriately designed for
unit
> > testing, then the onus is on you to refactor the project so that it
> > can be unit tested
>
> Ruby uses Rubicon testsuite for the language itself, written of course
in
> Ruby.
If Ruby itself is written in C (as I suspect) then that is an acceptance
test.
Unit tests go directly to the object / method / function level at as low
a level as possible.
John Roth
Christophe Thibaut
As a matter of fact, our untested code refactoring involves lots of
pains and effort, because our tests suites are forced to move along with
the code. We have user acceptance tests (and a ton of bug reports :-),
not much doc about the domain problem (except the lecacy system written
in clipper). It is quite a long process.
>
> >
> >
Daniel T.
>I used to think so, until I saw Robert Martin's comments in another
>thread. He seems to be recommending that the programming team
>create a specialized language that the customer (and QA department,
>if one is involved) can use to specify the tests.
And when are we going to have time to do this? And who will validate the
tests to ensure that the specialized language and is correct? Do we make
a specialized language that tests the specialized language?
Ron Jeffries
wrote:
The time comes from reduced debugging. And a little open-minded
thought will suggest that a simple comma-separated command script will
work just fine.
XP teams all over are actually doing this, which suggests to me that
it's not that hard, and that they find it valuable.
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
Keith Ray
"Daniel T." <notda...@gte.net> wrote:
XP Roles:
Customer - (required) person who knows the requirements, and has
authority to decide questions about the requirements. The Customer
writes Stories (light-weight Use-Cases), defines Acceptance tests and
validates test-results. (Customer's delegate may help define and
implement Acceptance Tests, see Tester.)
Programmer - (required) person who designs and implements Unit Tests,
code to pass the Unit Tests and Acceptance Tests. May also implement
Acceptance Tests on behalf of the Customer if there are no Testers on
the project.
Tester - (optional) helps Customer implement, specify, and validate
Acceptance tests. May also help Programmers define and implement Unit
Tests.
Coach - (optional) helps the team learn the XP practices; keeps the team
on track. Not recommended to be the same person as Manager or
Programmer, because Coach needs to see the bigger picture.
Manager - (optional) forms the team and makes sure the team can make
progress. Handles company politics, etc.
Requirements Analyst - (optional) helps the Customer gather and validate
requirements.
(Did I leave out any other "who" answers?)
Requirements gathering practices and validating requirements are
"outside of XP". Those practices will differ depending on the project
environment -- a project to create a website with little monetary risk
would have much different requirements gathering and validating
practices, compared to a project producing a software-controlled medical
device.
As for "Time" -- all estimates for a Story should include time to create
Story's Acceptance Tests, if the programmers are also writing those
Tests.
David B Lightstone
"Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
> In article
<notdanielt3-BDA5...@paloalto-snr1.gtei.net>,
> "Daniel T." <notda...@gte.net> wrote:
>
> > "John Roth" <john...@ameritech.net> wrote:
> >
But isn't this the root cause of the Software Development Crisis?
Peter Hansen
>
> XP Roles:
>
> Customer - (required) person who knows the requirements, and has
>
> Programmer - (required) person who designs and implements Unit Tests,
>
> Tester - (optional)
> Coach - (optional)
> Manager - (optional)
> Requirements Analyst -
> (Did I leave out any other "who" answers?)
You forgot the "other" programmer. Need a pair! :-)
I would suggest that Tester and Requirements Analyst are not
necessary in such a list. There are dozens of potential roles
programmers can assume, and those are but two. Manager and
Coach I believe deserve explicit listing as above, although
perhaps they could be the same person in small teams (?).
David B Lightstone
> David B Lightstone a écrit :
>
> > "Christophe Thibaut" <cthi...@club-internet.fr> wrote in message
> > news:3BFD7337...@club-internet.fr...
> > > Keith Ray a écrit :
> > >
> > > > In article <tvqb6hg...@news.supernews.com>,
> > > > "John Roth" <john...@ameritech.net> wrote:
> > > >
> >
> > Safety belt indeed!!! The absense of one makes refactoring,
> > reengineering etc. one of the more difficult tasks. So this begs
> > the question, is the challenge a realistic goal? How on earth
> > are you going to know if you have refactored something correctly,
> > unless you have adequate documentation of some form or another
> > (unit test, specification, requirements, or design)?
> >
>
> As a matter of fact, our untested code refactoring involves lots of
> pains and effort, because our tests suites are forced to move along
with
> the code. We have user acceptance tests (and a ton of bug reports
:-),
> not much doc about the domain problem (except the lecacy system
written
> in clipper). It is quite a long process.
>
I think you have just given the answer to the challenge question.
>
> >
> > >
> > >
>
Keith Ray
"David B Lightstone" <david.li...@prodigy.net> wrote:
> But isn't this the root cause of the Software Development Crisis?
What are you talking about? The "Crisis" is (1) there are more wishes
than fishes and (2) many projects are managed so ineptly that they fail.
XP helps brings realism into the "wishing" and "fishing", and offers a
methodology to those who are willing to use it.
Peter Hansen
>
> "Christophe Thibaut" <cthi...@club-internet.fr> wrote:
> >
> > As a matter of fact, our untested code refactoring involves lots of
> > pains and effort, because our tests suites are forced to move along
> > with the code. We have user acceptance tests (and a ton of bug reports
> > :-), not much doc about the domain problem (except the lecacy system
> > written in clipper). It is quite a long process.
>
> I think you have just given the answer to the challenge question.
Not quite. Not at all in fact. The "challenge question" (it didn't
seem so much a challenge question as simply a challenge: pointless
and without a specified objective except to improve a single project
by adding some tests ... whatever) ... as I was saying, the challenge
question included this statement:
"If the code is not appropriately designed for unit
testing, then the onus is on you to refactor the project
so that it can be unit tested."
It seems to me that is what poor Christophe's team is having to
accomplish. They haven't even gotten to the stage of having lots
of unit tests to support their refactoring.
David B Lightstone
people could understand the significance of your reply. I have
replaced it.
"Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
news:k1e2i3t4h5r6a7y-26...@news1.rdc1.sfba.home.com...
> In article <46BL7.583$_r5.149...@newssvr16.news.prodigy.com>,
> "David B Lightstone" <david.li...@prodigy.net> wrote:
>
>> In article
<notdanielt3-BDA5...@paloalto-snr1.gtei.net>,
>> "Daniel T." <notda...@gte.net> wrote:
<snip>
>
>>> Requirements gathering practices and validating requirements are
>> >"outside of XP".
>> But isn't this the root cause of the Software Development Crisis?
>
> What are you talking about? The "Crisis" is (1) there are more
wishes
> than fishes and (2) many projects are managed so ineptly that they
fail.
>
Your (2) was my initially articuated position. I do not think XP will
do anything to address the problem. The critical element which appears
to be mismanaged (in my opinion) is the requirements gathering and
validating activities. These have been declared outside the scope of
XP.
Whether XP is successful or not I will not know. I have no realistic
expectations of working at a firm that uses XP methodology.
If it proves successful it will be attributable to expunging the
difficult root cause problem from the task of software development. If
you set the bar low enough you will always be successful. The sad part
of the situation is that the ignorant will believe the XP includes
within its scope the difficult problem
>
> XP helps brings realism into the "wishing" and "fishing", and offers
a
> methodology to those who are willing to use it.
>
On this we disagree. It does little more that push the monkey onto
someone elses back
David B Lightstone
I guess we are going to have to ask Christophe a lot of detailish type
questions
specifically about how "... our tests suites are forced to move along
with the code."
I think he has gotten to the stage of having lots of unit tests to
support refactoring.
Keith Ray
"David B Lightstone" <david.li...@prodigy.net> wrote:
>
> "Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
> news:k1e2i3t4h5r6a7y-26...@news1.rdc1.sfba.home.com...
>
>>"outside of XP".
>
>But isn't this the root cause of the Software Development Crisis?
>
>> What are you talking about? The "Crisis" is (1) there are more
>> wishes
>> than fishes and (2) many projects are managed so ineptly that they
>> fail.
>
> Your (2) was my initially articuated position. I do not think XP will
> do anything to address the problem. The critical element which appears
> to be mismanaged (in my opinion) is the requirements gathering and
> validating activities. These have been declared outside the scope of
> XP.
I disagree. Deathmarch projects fail because no one wanted to give them
a realistic chance to succeed, not because of failures in requirements
gathering and validating activities. Other kinds of projects fail for an
infinite variety of reasons. Weinberg, in one of the volumes of
"Software Quality Management", mentions that management behavior has
much greater impact on project success than any other factor (with some
numbers to back it up). He gives an example of a manager who would date
the female contractors that he hired, and then fire them when he wanted
to end the affair.
Perhaps I've been lucky in that almost all projects that I've been on,
have shipped working code and have been deemed successes, and the few
projects that were cancelled were cancelled because of financial
mis-management (or mergers) that were completely unrelated to these
projects.
> Whether XP is successful or not I will not know. I have no realistic
> expectations of working at a firm that uses XP methodology.
<http://c2.com/cgi/wiki?CompaniesDoingXp>
<http://c2.com/cgi/wiki?XpHelpWanted>
> If it proves successful it will be attributable to expunging the
> difficult root cause problem from the task of software development. If
> you set the bar low enough you will always be successful.
Can you explain "set the bar low enough"?
Some people have said that XP requires "too much": a Customer on-site,
who is available to answer questions, and has authority to make
decisions about the details of requirements. Some may have intimated
that XP was "cheating" by requiring this level of commitment -- a level
of commitment that a Deathmarch project would never get. If a project
had that level of support, they might say, it could work no matter what
methodology was used.
Perhaps that's true. Perhaps that statistic {from Casper Jones?) that
highest level of project successes (55%) comes from projects of six or
fewer people (right in the middle of the XP-recommended size range) ALSO
implies that XP projects will benefit from successes due to environment,
rather than the methodology.
> The sad part
> of the situation is that the ignorant will believe the XP includes
> within its scope the difficult problem
>
> >
> > XP helps brings realism into the "wishing" and "fishing", and offers
> a
> > methodology to those who are willing to use it.
> >
> On this we disagree. It does little more that push the monkey onto
> someone elses back
I'm not sure what monkey you were talking about, since I was talking
about fishes and wishes.
Wishes are feature requests... fishes are programmers. In XP,
programmers give estimates, the customer chooses which ones to implement
first. The programmers codes, the customer determines if the code passes
the tests. In many XP teams, the story is not "complete" until it passes
its tests.
If you're saying a project can't be successful unless some expert
validates that the tests are testing the right things in the right way,
then you are blowing smoke, or trying to sell something. There have
been many successful (non-XP) projects that didn't have very formalized
Verification & Validation, and did not even have the automated
acceptance testing that XP requires. I think most of them, just like XP,
had people using the product at frequent intervals during the
development process, in addition to whatever informal testing they may
have had.
Kent Beck said XP is asking the question "How little can we do and still
build great software?". There have been successful projects that do
less. See Cockburn's description of Crytal Clear and other Agile
Methodologies in his book and website -- he seems to be formalizing
methods used by successful projects, rather than making something up and
then seeing if it could work.
There are (of course) LOTS of projects out there that are not
successful, using or mis-using various methodologies, including the
ever-popular "code and fix" -- no methodology. The ones that don't have
disabling management could probably benefit by trying XP, possibly
AUGMENTED by whatever practices their niche may require.
Ron Jeffries
<david.li...@prodigy.net> wrote:
>The critical element which appears
>to be mismanaged (in my opinion) is the requirements gathering and
>validating activities. These have been declared outside the scope of
>XP.
It is true that we do not address in detail how to come up with an
INITIAL set of stories. However, it seems to me that these things in
combination address requirements gathering and validation:
- have at least one domain expert who knows what the problem is as a
member of the team;
- explain requirements verbally and by provision of unambiguous
acceptance tests
- request stories in order of highest business value / lowest cost
first;
- deliver running software every couple of weeks so that users can
see what it is they have wrought.
I would agree that these are not _conventional_ approaches to
requirements gathering and validation, but it seems to me that they
are in fact requirements gathering and validation.
We could discuss whether they are appropriate or optimal. But why
would one say that requirements gathering and validation are outside
XP?
Thanks,
Peter Hansen
> > > "Christophe Thibaut" <cthi...@club-internet.fr> wrote:
> > > >
> > > > As a matter of fact, our untested code refactoring involves lots of
> > > > pains and effort, because our tests suites are forced to move along
> > > > with the code. We have user acceptance tests (and a ton of bug reports
> > > > :-), not much doc about the domain problem (except the lecacy system
> > > > written in clipper). It is quite a long process.
> > >
> > > I think you have just given the answer to the challenge question.
> > It seems to me that is what poor Christophe's team is having to
> > accomplish. They haven't even gotten to the stage of having lots
> > of unit tests to support their refactoring.
>
> I guess we are going to have to ask Christophe a lot of detailish type
> questions specifically about how "... our tests suites are forced to
> move along with the code."
>
> I think he has gotten to the stage of having lots of unit tests to
> support refactoring.
I might be wrong, but I read what he wrote above as indicating
that he does *not* yet have unit tests (the part about "untested code
refactoring") but that he *does* have user acceptance tests (the part
about "we have user acceptance tests").
But maybe I read that wrong.
Keith Ray
<674EB92D80254D6C.D15E6E3F...@lp.airnews.net>,
Ron Jeffries <ronje...@REMOVEacm.org> wrote:
Because I said it, and I was quoting
<http://groups.yahoo.com/group/extremeprogramming/message/37158>
which said...
>From: drawstho@a...
>Date: Wed Oct 24, 2001 9:58 am
>Subject: Re: [XP] Re: Customer versus End User
>
> This is a crucial thing that both Kent and Ron have said in the past few
> days:
> requirements generation and validation are outside the scope of XP.
>
> This is important because it puts a nice box around the toolset that we call
> XP
> and shows us where to fit it in within our projects. It is purely at the
> development end of things, dealing with the Customer and Developer. At the
> other end, where the Customer deals with Users, we need to do something else.
>
> As I have said before, I hope that XP itself does not try to expand to fill
> the
> void. XP is a very good toolkit for the Developer/Customer end of things, and
> I
> think that it will only get messy if it tries to expand...
>
> Dan ;-)
>
> In a message dated Wed, 24 Oct 2001 4:51:13 AM Eastern Daylight Time, Ron
> Jeffries <ronjeffries@a...> writes:
>
> > Around Tuesday, October 23, 2001, 11:50:37 PM, Charlie Poole wrote:
> >
> > > So, have I caught on to a real difference here, or am I imagining
> > > it? In any case, it strikes me that there may actually be room in
> > > the universe for both approaches.
> >
> > No real difference. XP doesn't presently address the question, and the
> > whole team notion is much of the solution, probably. I believe that
> > much of requirements generation is chronologically prior to where XP
> > projects -- of today -- typically start.
> >
> > Ron Jeffries
> > www.XProgramming.com
> > The fact that we know more today, and are more capable today,
> > is good news about today, not bad news about yesterday.
Peter L Jones
[snip]
>
> XP Roles:
>
[snip]
>
> Programmer - (required) person who designs and implements Unit Tests,
> code to pass the Unit Tests and Acceptance Tests. May also implement
> Acceptance Tests on behalf of the Customer if there are no Testers on
> the project.
Okay, I've seen a lot of commentary in this group about XP and Agile
methods. The above is so close to what I've come to see as "the right
way" for developing (i.e. the most realistic and efficient compromise to
the time-cost-quality triangle) that I want to read some more.
I like the "customer" role definition, although it looks a lot harder to
achieve.
Recommendations on websites are welcome!
Regards,
-- Peter
David B Lightstone
"Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
> In article <cXBL7.600$m77.15...@newssvr16.news.prodigy.com>,
> "David B Lightstone" <david.li...@prodigy.net> wrote:
> >
> > "Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
> > news:k1e2i3t4h5r6a7y-26...@news1.rdc1.sfba.home.com...
> >
> >> Requirements gathering practices and validating requirements are
> >>"outside of XP".
> >
> >But isn't this the root cause of the Software Development Crisis?
> >
> >> What are you talking about? The "Crisis" is (1) there are more
> >> wishes
> >> than fishes and (2) many projects are managed so ineptly that they
> >> fail.
> >
> > Your (2) was my initially articuated position. I do not think XP will
> > do anything to address the problem. The critical element which appears
> > to be mismanaged (in my opinion) is the requirements gathering and
> > validating activities. These have been declared outside the scope of
> > XP.
>
> I disagree.
I will assume you disagree about requirements gathering and validation being
the root cause of the managerial problems. If not please clarify
> Deathmarch projects fail because no one wanted to give them
> a realistic chance to succeed, not because of failures in requirements
> gathering and validating activities.
Mr Yourdon has well articulated why and how Death Marchs fail. They
are inherently prone to failure buy virtue of INADEQUATE resource
allocation. Your contention that they were not given a chance to succeed
is cirrect, but it completely misses the point. Death Marchs often fail
<snip>
>
> > If it proves successful it will be attributable to expunging the
> > difficult root cause problem from the task of software development. If
> > you set the bar low enough you will always be successful.
>
> Can you explain "set the bar low enough"?
By placing the difficult task outside of the scope of the methodology
Thats like lowering the earnings estimate, so that it easily can be met
>
> Some people have said that XP requires "too much": a Customer on-site,
> who is available to answer questions, and has authority to make
> decisions about the details of requirements.
This in away is an aspect of the difficult part, but it does nothing to manage
the
difficult part. It just pushes the monkey onto the customers back. It will
have to be addressed and managed within the customer organization.
How will the customer manage that activity?
<snip>
>
> > The sad part
> > of the situation is that the ignorant will believe the XP includes
> > within its scope the difficult problem
> >
> > >
> > > XP helps brings realism into the "wishing" and "fishing", and offers
> > a
> > > methodology to those who are willing to use it.
> > >
> > On this we disagree. It does little more that push the monkey onto
> > someone elses back
>
> I'm not sure what monkey you were talking about, since I was talking
> about fishes and wishes.
>
> Wishes are feature requests... fishes are programmers.
The monkey is (in your notation) managing wishes
> In XP,
> programmers give estimates, the customer chooses which ones to implement
> first. The programmers codes, the customer determines if the code passes
> the tests. In many XP teams, the story is not "complete" until it passes
> its tests.
>
> If you're saying a project can't be successful unless some expert
> validates that the tests are testing the right things in the right way,
> then you are blowing smoke, or trying to sell something.
When the automatic testing that XP requires, indicates a failure. What happens?
I would quess that some sort of debug effort is initiated. At some point
during the debug effort a decision will be made either
(1) The code under test gets fixed
(2) The acceptance test gets changed
(3) The automatic test environment gets changed.
(2) is equivalent to validating the test. By pushing that activity to "outside
the scope of XP" an exercise in finger pointing is established.
> There have
> been many successful (non-XP) projects that didn't have very formalized
> Verification & Validation, and did not even have the automated
> acceptance testing that XP requires.
There have also been many that failed. What inference can be made based
upon that information?
<snip>
> Kent Beck said XP is asking the question "How little can we do and still
> build great software?". There have been successful projects that do
> less. See Cockburn's description of Crytal Clear and other Agile
> Methodologies in his book and website -- he seems to be formalizing
> methods used by successful projects, rather than making something up and
> then seeing if it could work.
Sounds like XP is a technology in Mr Moore's bowling ally
<snip>
David B Lightstone
"Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
> In article
> <674EB92D80254D6C.D15E6E3F...@lp.airnews.net>,
> Ron Jeffries <ronje...@REMOVEacm.org> wrote:
>
> > On Sat, 24 Nov 2001 00:35:20 GMT, "David B Lightstone"
> > <david.li...@prodigy.net> wrote:
> >
> > >The critical element which appears
> > >to be mismanaged (in my opinion) is the requirements gathering and
> > >validating activities. These have been declared outside the scope of
> > >XP.
> >
> > It is true that we do not address in detail how to come up with an
> > INITIAL set of stories. However, it seems to me that these things in
> > combination address requirements gathering and validation:
Hsving information presented to you in a disorganized fashion forces the
burdon of organization on to the receiver.
> >
> > - have at least one domain expert who knows what the problem is as a
> > member of the team;
Having an expert does not manage a problem, it conceals the need to manage
the problem
> > - explain requirements verbally and by provision of unambiguous
> > acceptance tests
Maximize the opportunity for misunderstanding and changing interpretation
by establishing a word of mouth culture
When the project is done, and accepted, the acceptance tests are always
unambiguous (by definition). Whether they are correct is another question
> > - request stories in order of highest business value / lowest cost
> > first;
Usually not known out front
> > - deliver running software every couple of weeks so that users can
> > see what it is they have wrought.
Thats great for Web sites, and business applications, but there are a lot
of embedded systems types (such as myself) that don't get testing platforms
(like cars or planes) every few weeks. This because the hardware is being
developed simultaneously and circuits just aren't releases one at a time
> >
> > I would agree that these are not _conventional_ approaches to
> > requirements gathering and validation, but it seems to me that they
> > are in fact requirements gathering and validation.
>
A disorganized blob of information forces the organization effort
to be performed by each and every member of the project. That is
the information itself necessary for the project is not managed
> >
> > We could discuss whether they are appropriate or optimal. But why
> > would one say that requirements gathering and validation are outside
> > XP?
>
> Because I said it, and I was quoting
>
> <http://groups.yahoo.com/group/extremeprogramming/message/37158>
>
<snip>
Ron Jeffries
<k1e2i3t...@1m2a3c4.5c6o7m> wrote:
>> We could discuss whether they are appropriate or optimal. But why
>> would one say that requirements gathering and validation are outside
>> XP?
>
>Because I said it, and I was quoting
>
><http://groups.yahoo.com/group/extremeprogramming/message/37158>
Yes. I think I have changed my mind. Or else I was talking about the
requirements gathering process before the first meeting with the team
... or both.
Dave Harris
> > [60 lines snipped]
>
> But isn't this the root cause of the Software Development Crisis?
I really wish you had left a little less of the context in, that way
people could understand the significance of your reply. You might have
been objecting to the XP role of "Coach" being optional, or something. I
gather from later articles that only the first sentence of the last
paragraph was significant.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Ron Jeffries
<david.li...@prodigy.net> wrote:
>> > It is true that we do not address in detail how to come up with an
>> > INITIAL set of stories. However, it seems to me that these things in
>> > combination address requirements gathering and validation:
>
>Hsving information presented to you in a disorganized fashion forces the
>burdon of organization on to the receiver.
Someone has to do this job. Why should it not be the team who are
going to build the software?
>> > - have at least one domain expert who knows what the problem is as a
>> > member of the team;
>
>Having an expert does not manage a problem, it conceals the need to manage
>the problem
Do you know of a way to gather and validate requirements without a
domain expert?
>
>> > - explain requirements verbally and by provision of unambiguous
>> > acceptance tests
>
>Maximize the opportunity for misunderstanding and changing interpretation
>by establishing a word of mouth culture
Because writing down what you don't quite mean in a form the reader
can't quite understand is so much better? On the contrary, it's pretty
well established that continuing conversation works better for
reaching understanding and agreement than any written form of
communication.
>
>When the project is done, and accepted, the acceptance tests are always
>unambiguous (by definition). Whether they are correct is another question
Isn't it always? What ways are you aware of for making sure that
requirements are correct? Please explain why showing the person with
the requirements the results of his requests is inferior to those
ways.
>> > - request stories in order of highest business value / lowest cost
>> > first;
>
>Usually not known out front
I've never met a customer who, given two requirements, was unable to
say which one he wanted to see first. And I've never met a team I
couldn't teach to estimate the cost of requirements. So yes, not known
before you start. Fairly easy to start knowing and to know better as
time passes.
>
>> > - deliver running software every couple of weeks so that users can
>> > see what it is they have wrought.
>
>Thats great for Web sites, and business applications, but there are a lot
>of embedded systems types (such as myself) that don't get testing platforms
>(like cars or planes) every few weeks. This because the hardware is being
>developed simultaneously and circuits just aren't releases one at a time
Yes, that does make it harder. I suppose you use simulators and the
like? Customers can understand those quite well, and the tests, while
not perfect, can be quite useful. But I expect that you already know
that, do you not?
>
>> >
>> > I would agree that these are not _conventional_ approaches to
>> > requirements gathering and validation, but it seems to me that they
>> > are in fact requirements gathering and validation.
>>
>
>A disorganized blob of information forces the organization effort
>to be performed by each and every member of the project. That is
>the information itself necessary for the project is not managed
Guess what. No matter what one provides, organized a lot or a little,
each individual still organizes it into her own mind. That's what
"understanding" is all about. It's quite efficient and practical to do
that organization and building of understanding as a team.
Folks are actually doing this stuff and reporting that they like it.
What could be causing that?
Ron Jeffries
<pljon...@Xspam-earthling.net> wrote:
>Okay, I've seen a lot of commentary in this group about XP and Agile
>methods. The above is so close to what I've come to see as "the right
>way" for developing (i.e. the most realistic and efficient compromise to
>the time-cost-quality triangle) that I want to read some more.
>
>I like the "customer" role definition, although it looks a lot harder to
>achieve.
>
>Recommendations on websites are welcome!
www.XProgramming.com : my site, of which I am perhaps overly fond, and
www.extremeprogramming.org , Don Well's site.
And lots of others. One good starting point might be
http://www.xprogramming.com/xpmag/whatisxp.htm , but definitely check
out Don's stuff as well.
And there's an extremeprogramming group on yahoo groups. Very active.
I mean VERY.
Regards,
Ron Jeffries
<david.li...@prodigy.net> wrote:
>When the automatic testing that XP requires, indicates a failure. What happens?
>I would quess that some sort of debug effort is initiated. At some point
>during the debug effort a decision will be made either
>(1) The code under test gets fixed
>(2) The acceptance test gets changed
>(3) The automatic test environment gets changed.
>
>(2) is equivalent to validating the test. By pushing that activity to "outside
>the scope of XP" an exercise in finger pointing is established.
Any of 1, 2, or 3 can happen. The team decides. Final call on what the
customer meant is owned by the customer. The customer is part of the
team. There is no "outside the scope of XP" aspect to this behavior.
It happens all the time, and the team just sorts it out.
John Roth
"David B Lightstone" <david.li...@prodigy.net> wrote in message
news:DwML7.623$Wc2.10...@newssvr17.news.prodigy.com...
>
<entire post snipped>
I've been looking at this thread, trying to find an appropriate place to
hang a comment, and failing. I'm just going to summarize what
I think is the issue.
<issue>
Mr. Lightstone appears to believe that a valid development
methodology needs a requirements management process. Since
XP does not include such a process, it is, therefore, not a
valid development methodology.
<end issue>
The hangup here is a scope confusion. I don't think anyone
doubts that having 'good' requirements, for some reasonable
value of 'good,' is essential to successful project completion.
David points out that XP shoves this responsibility onto the
customer's shoulders. This is quite true, and I don't think
it's a defect in the XP methodology.
The reason is that XP is a development methodology in
the sense that it is executed by people whose functional
job title is 'developer.' It's not executed by people whose
functional job title is 'business analyst' or 'systems analyst.'
The customer may or may not need one of those, but they
exist on the customer side of the interface. The fact that
traditional IS organizations and consultants include them
in 'development' is irrelevant. Developers build systems,
analysts derive systems.
John Roth
John Roth
I don't believe you did. You'll need to scroll back in the newsgroup
a ways, since Christophe posted quit a bit about the project and
the management problems a couple of months ago.
John Roth
David B Lightstone
"John Roth" <john...@ameritech.net> wrote in message
news:tvvkjdd...@news.supernews.com...
>
> "David B Lightstone" <david.li...@prodigy.net> wrote in message
> news:DwML7.623$Wc2.10...@newssvr17.news.prodigy.com...
> >
> <entire post snipped>
>
> I've been looking at this thread, trying to find an appropriate place to
> hang a comment, and failing. I'm just going to summarize what
> I think is the issue.
>
> <issue>
> Mr. Lightstone appears to believe that a valid development
> methodology needs a requirements management process. Since
> XP does not include such a process, it is, therefore, not a
> valid development methodology.
> <end issue>
Correct accessment
I would term it a development method.
Titles for such things are, however, unimportant
pedantic issues in this situation
>
> The hangup here is a scope confusion. I don't think anyone
> doubts that having 'good' requirements, for some reasonable
> value of 'good,' is essential to successful project completion.
>
Disagree with the interpretation. Its something other than scope confusion
Requirements are always dynamic in nature. Changing with the understanding
of the problem. Diffusing amongst the participants at varying rates of time.
>
> David points out that XP shoves this responsibility onto the
> customer's shoulders. This is quite true, and I don't think
> it's a defect in the XP methodology.
>
Irrespective of whether it is a defect or not in the XP methodology.
Shoving something onto the shoulders of you client or business
partner is bad policy. This is especially so in a problem solving
venture.
Perhaps XP restricts itself to situations where there
will be no problem solving. This I find highly unlikely, so
I believe it to be a significant defect
>
> The reason is that XP is a development methodology in
> the sense that it is executed by people whose functional
> job title is 'developer.' It's not executed by people whose
> functional job title is 'business analyst' or 'systems analyst.'
>
> The customer may or may not need one of those, but they
> exist on the customer side of the interface. The fact that
> traditional IS organizations and consultants include them
> in 'development' is irrelevant. Developers build systems,
> analysts derive systems.
>
I have never seen the clean boundary between Development
and Analysis that you seem to preceive. That is not to say
that such situations do not exist, they may indeed be quite
common. I just have never seen the clean boundary. This
is probably attributable to the nature of the work that
I have done, mostly embedded realtime.
>
> John Roth
>
>
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
news:B9490281141363AF.A0337997...@lp.airnews.net...<snip>
> >Having an expert does not manage a problem, it conceals the need to manage
> >the problem
>
> Do you know of a way to gather and validate requirements without a
> domain expert?
The issue is not the knowledge provided by the expert, it is
it's consistency, and temporal change. Those are the things which
are to be managed
<snip>
> Because writing down what you don't quite mean in a form the reader
> can't quite understand is so much better? On the contrary, it's pretty
> well established that continuing conversation works better for
> reaching understanding and agreement than any written form of
> communication.
>
I assume the deliberately confusing negative logic was for purposes
of exhibiting a need to gain clarification by converstation.
And when you reach agreement, you write it down, and review it
Otherwise it is little more than a verbal contract. (won't hold up
in court).
> >
> >When the project is done, and accepted, the acceptance tests are always
> >unambiguous (by definition). Whether they are correct is another question
>
> Isn't it always? What ways are you aware of for making sure that
> requirements are correct?
That is something that I do not plan to discuss in a public forum.
> Please explain why showing the person with
> the requirements the results of his requests is inferior to those
> ways.
>
I will assume you wish for me to compare and contrast the answer for
the previous question with the results of a successful implementation.
It is neither inferior nor superior. Its really a question of the risk
that one is willing to take. The risks associated with misevaluating
the requirements often exceed the extent of the risk that one is willing to take
>
> >> > - request stories in order of highest business value / lowest cost
> >> > first;
<snip>
> I've never met a customer who, given two requirements, was unable to
> say which one he wanted to see first.
That is a partially correct statement. It assumes that there is an consistent
ordering
of priorities. Not necessarily true.
In the world of psychology the absense of a consistent ordering is readily
observed.
There is a whole profession which helps people resolve the manifestations of
those
inconsistencies.
In the world or realtime systems there is the priority inversion problem. Treat
the phenomena as an analogy.
<snip>
@objectmentor.com Robert C. Martin
wrote:
>"John Roth" <john...@ameritech.net> wrote:
>
>>I used to think so, until I saw Robert Martin's comments in another
>>thread. He seems to be recommending that the programming team
>>create a specialized language that the customer (and QA department,
>>if one is involved) can use to specify the tests.
>
>And when are we going to have time to do this?
By avoiding all the rework and debugging we'd otherwise have to do.
One of the great revelations of XP is that writing tests save you gobs
of time.
>And who will validate the
>tests to ensure that the specialized language and is correct? Do we make
>a specialized language that tests the specialized language?
XP causes us to create three separate executable expressions of what
the program is supposed to do. Unit tests, acceptance tests, and the
program itself. Now, I'll grant you, that three is not enough for
perfect coverage. However, I think that very few of us are interested
in perfect coverage.
Robert C. Martin | "Uncle Bob" | Software Consultants
Object Mentor Inc. | rma...@objectmentor.com | We'll help you get
PO Box 5757 | Tel: (800) 338-6716 | your projects done.
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|
"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan
@objectmentor.com Robert C. Martin
<david.li...@prodigy.net> wrote:
>> Requirements gathering practices and validating requirements are
>> "outside of XP".
>
>But isn't this the root cause of the Software Development Crisis?
It is true that one prominent cause of project failure is a failure of
requirements gathering.
It is not quite true that gathering and validationg requirements is
outside of XP. It's also not quite false. XP does not provide any
guidance or practices for elucidating, gaterhing, and elaborating
requirements. On the other hand, XP does suggest that the customer
and stakeholders be present every two weeks when the next iteration is
demonstrated. During those demonstrations, any mis-communication of
requirements is highly likely to stand out and get corrected.
John Roth
>
> "John Roth" <john...@ameritech.net> wrote in message
> news:tvvkjdd...@news.supernews.com...
> >
> > "David B Lightstone" <david.li...@prodigy.net> wrote in message
> > news:DwML7.623$Wc2.10...@newssvr17.news.prodigy.com...
> > >
>
understanding
> of the problem. Diffusing amongst the participants at varying rates of
time.
Of course. Any discussion of XP shows that the
development team can propose stories at any time. It
remains the customer's responsibility to assess them
and prioritize them.
> >
> > David points out that XP shoves this responsibility onto the
> > customer's shoulders. This is quite true, and I don't think
> > it's a defect in the XP methodology.
> >
>
> Irrespective of whether it is a defect or not in the XP methodology.
> Shoving something onto the shoulders of you client or business
> partner is bad policy. This is especially so in a problem solving
> venture.
This is what I meant by 'scope' earlier. In a global analysis,
it's quite true that shoving a problem onto someone else's turf
may cause it to be unsolved, or solved incorrectly. However, we
do need to understand separation of responsibility.
Taking over someone else's responsibility because they are
not doing it may get the job done in the short term, but it
leads to confusion in the long term.
> >
> > The reason is that XP is a development methodology in
> > the sense that it is executed by people whose functional
> > job title is 'developer.' It's not executed by people whose
> > functional job title is 'business analyst' or 'systems analyst.'
> >
> > The customer may or may not need one of those, but they
> > exist on the customer side of the interface. The fact that
> > traditional IS organizations and consultants include them
> > in 'development' is irrelevant. Developers build systems,
> > analysts derive systems.
> >
>
> I have never seen the clean boundary between Development
> and Analysis that you seem to preceive. That is not to say
> that such situations do not exist, they may indeed be quite
> common. I just have never seen the clean boundary. This
> is probably attributable to the nature of the work that
> I have done, mostly embedded realtime.
The fuzzyness of the boundary is common in all endevours.
Most programmers with any experiance feel that the analysts
have messed up the requirements somewhere, and they are
frequently (although not always) correct.
My own domain, business systems
(mainly financial, credit and insurance) has nothing that
could not be done by a hoard of well trained and motivated
clerks, so the customer shouldn't have a tremendous amount
of difficulty creating requirements. Business analysts are
useful, but not always necessary.
Embedded real time is quite different in that there is no
parallel manual process. I shudder to think of operating
an oil refinery (of which there are several within a few miles
of here) manually, let alone a nuclear power plant or a
CAT scanner.
In that domain, the requirements would seem to be
something that are worked out with the engineers building
the machinery to be controlled, and there doesn't seem to
be a clean boundary.
My other domain, operating systems, mostly seems to
operate on requirements that have been synthesized out of
thin air, which I suppose says something or other.
The original XP project (CCC - Chrysler Compensation) was
a payroll application; the client knew exactly what they wanted,
and had little or no difficulty in stating it.
John Roth
e-mail address is not valid - ask on group if you want my e-mail.
Keith Ray
"David B Lightstone" <david.li...@prodigy.net> wrote:
> Irrespective of whether it is a defect or not in the XP methodology.
> Shoving something onto the shoulders of you client or business
> partner is bad policy. This is especially so in a problem solving
> venture.
You keep acting like the Customer (whose job title may be Product
Manager, Project Manager, Planner, Designer, Requirements Analyst or
Problem Solver), is not part of the team.
It is One Team.
Keith Ray
"David B Lightstone" <david.li...@prodigy.net> wrote:
>"Ron Jeffries" <ronje...@REMOVEacm.org> wrote :
> > Isn't it always? What ways are you aware of for making sure that
> > requirements are correct?
>
> That is something that I do not plan to discuss in a public forum.
ROFL !!!
Keith Ray
practices for developing software. It has been described as a
"high-discipline, low-overhead" methodology. XP has developers
programming in pairs, writing tests to verify all code, and continuously
refactoring code to improve the design. To quote Kent Beck: "XP is a
starting line. It asks the question, 'How little can we do and still
build great software?'"
comp.software.extreme-programming is a newsgroup for discussing this
methodology.
XP FAQ: <http://www.jera.com/techinfo/xpfaq.html>
XP and related Books:
"Extreme Programming Explained: Embrace Change" by Kent Beck;
ISBN 0-201-61641-6
"Planning Extreme Programming" by Kent Beck, Martin Fowler;
ISBN 0201710919
"Extreme Programming Installed" by Ron Jeffries, Chet Hendrickson, and
Ann Anderson; ISBN 0201708426
"Extreme Programming Applied" by Ken Auer, Roy Miller; ISBN 0-201-61640-8
"Adaptive Software Development" by James A. Highsmith III; ISBN
0-932633-40-4
"Agile Software Development" by Alistair Cockburn; ISBN 0-201-69969-9
"Refactoring: Improving the Design of Existing Code" by Martin Fowler;
ISBN 0-201-48567-2
"Extreme Programming Examined" by Giancarlo Succi and Michele Marchesi;
ISBN 0-201-71040-4
"Extreme Programming Explored" by William C. Wake; ISBN 0-201-73397-8
"Extreme Programming in Practice" by James W. Newkirk and Robert C.
Martin; ISBN: 0-201-70937-6
Web sites:
Extreme Programming: A Gentle Introduction
<http://www.extremeprogramming.org/>
XP magazine:
<http://www.xprogramming.com/xpmag/index.htm>
XP Test Frameworks:
<http://www.xprogramming.com/software.htm>
Junit test framework for java:
<http://www.junit.org/>
Wiki Pages on XP:
<http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap>
XP Universe Papers
<http://www.xpuniverse.com/xpuPapers.htm>
The Agile Modeling (AM) Home Page
http://www.agilemodeling.com
http://www.agilemodeling.com/essays/agileModelingXP.htm
Martin Fowler's Refactoring Home Page
http://www.refactoring.com
Object Mentor publications:
http://www.objectmentor.com/publications/articlesBySubject.html
XPlorations:
<http://xp123.com/xplor/>
Ron Jeffries
<david.li...@prodigy.net> wrote:
>
>> >Having an expert does not manage a problem, it conceals the need to manage
>> >the problem
>>
>> Do you know of a way to gather and validate requirements without a
>> domain expert?
>
>The issue is not the knowledge provided by the expert, it is
>it's consistency, and temporal change. Those are the things which
>are to be managed
What's unmanaged about the way XP does it?
Topmind
> The Extreme Programming (XP) methodology is a set of principles and
> practices for developing software. It has been described as a
> "high-discipline, low-overhead" methodology. XP has developers
> programming in pairs, writing tests to verify all code, and continuously
> refactoring code to improve the design. To quote Kent Beck: "XP is a
> starting line. It asks the question, 'How little can we do and still
> build great software?'"
>
I don't like writing in pairs. It bothers me to code with
somebody watching me and breathing down my neck.
Only the most social of people like that, and they
are probably in sales.
And, most female programmers are not the pick of
the litter in the looks department, so pairing is
not likely to result in something that would
allow woody to fill us full of endorhpines to
improve the experience.
Instead, programmers are mostly fat, hairly,
ugly trolls with bad breath and BO and funny
voices. I should know, I'm one.
Peer code review, fine; but why the pair stuff?
-T-
Ron Jeffries
<david.li...@prodigy.net> wrote, regarding requirements gathering
and validation:
>> David points out that XP shoves this responsibility onto the
>> customer's shoulders. This is quite true, and I don't think
>> it's a defect in the XP methodology.
>>
>
>Irrespective of whether it is a defect or not in the XP methodology.
>Shoving something onto the shoulders of you client or business
>partner is bad policy. This is especially so in a problem solving
>venture.
>
>Perhaps XP restricts itself to situations where there
>will be no problem solving. This I find highly unlikely, so
>I believe it to be a significant defect
Let me see if I understand. It is your position that the development
team should relieve the customer of determining what his requirements
are and whether they are valid? You wish to remove this responsibility
"from his shoulders"?
If t his is not the case, then I don't understand what you're saying
and request a further explanation.
If it is the case, then please explain how you reach agreement with
the customer about what will be done, without shoving acceptance of
the requirements back onto his shoulders, in essence shoving them down
his throat.
Thanks,
Peter L Jones
Thanks for the pointers. I've subscribed to
comp.software.extreme-programming now!
-- Peter
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
news:6F60B1047EB98116.D0FA864B...@lp.airnews.net...
"Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
news:k1e2i3t4h5r6a7y-98...@news1.rdc1.sfba.home.com...
Paul Sinnett
> somebody watching me and breathing down my neck.
Pair programming is not the same as programming with somebody
watching.
> Peer code review, fine; but why the pair stuff?
Because it has been shown, by experiment, to produce better
results. You're well known for asking for evidence. Given that
all the evidence in this case says that pair programming is
better than solo programming, are you going to ignore it?
Paul Sinnett
> write more JUnit tests).
What's stopping you?
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Sat, 24 Nov 2001 19:51:19 GMT, "David B Lightstone"
> <david.li...@prodigy.net> wrote:
>
> >
> >> >Having an expert does not manage a problem, it conceals the need to manage
> >> >the problem
> >>
> >> Do you know of a way to gather and validate requirements without a
> >> domain expert?
> >
> >The issue is not the knowledge provided by the expert, it is
> >it's consistency, and temporal change. Those are the things which
> >are to be managed
>
> What's unmanaged about the way XP does it?
I do not understand the question, are you claiming that
that those things are managed, or just engaging in a little
trolling for answers to things you know little about.?
David B Lightstone
"Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
That is the theory of the practice. What is the reality?
When you state reality and theory are consistent,
do be so kind as to substanciate your contention.
As for my acting like the customer, quite to the contrary.
I simply have learned to some of the dumb things that
customers will do.
For a few (very few) these dumb things I have taken action
to insulate myself from their foolishness. I think I have
indicated what these things are. Whether you have
comprehended that which I have indicated, I do not know,
and will never know.
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Sat, 24 Nov 2001 19:03:11 GMT, "David B Lightstone"
> <david.li...@prodigy.net> wrote, regarding requirements gathering
> and validation:
>
> >> David points out that XP shoves this responsibility onto the
> >> customer's shoulders. This is quite true, and I don't think
> >> it's a defect in the XP methodology.
> >>
> >
> >Irrespective of whether it is a defect or not in the XP methodology.
> >Shoving something onto the shoulders of you client or business
> >partner is bad policy. This is especially so in a problem solving
> >venture.
> >
> >Perhaps XP restricts itself to situations where there
> >will be no problem solving. This I find highly unlikely, so
> >I believe it to be a significant defect
>
I take it from your subsequest question that there is indeed a
problem solving situation present.
>
> Let me see if I understand. It is your position that the development
> team should relieve the customer of determining what his requirements
> are and whether they are valid? You wish to remove this responsibility
> "from his shoulders"?
>
> If t his is not the case, then I don't understand what you're saying
> and request a further explanation.
>
No, there is generally both uncertainty to resolve and a problem solving
effort to conduct. You can't determine the results without doing something
in cooperation with each other. The model - We will just implement it,
tell us what you want us to do in this situation - is not applicable. That
model appears to be the basis for XP.
> If it is the case, then please explain how you reach agreement with
> the customer about what will be done, without shoving acceptance of
> the requirements back onto his shoulders, in essence shoving them down
> his throat.
>
Nothing like asking a 6 Million dollar question. There is and can be
no answer for such a question. If there were we would have no need
for Lawyers, our Courts would be empty, and Peace would soon be
at hand.
Why on earth do you continue to ask that I tell you how things should
be done. There are no correct answers there are only identifications and
characterizations of tradeoffs. XP has taken a set of tradeoffs, I have
questions the wisdom of some of them. Each time a tradeoff
is addressed You keep asking - What is better? Doesn't that
tell you something about the assumption that you are making?
I suggest that you answer your own question. Please don't give
the trivial reply - Use XP
Asking you customer to attend a meeting and either accept or reject
implies the absense of uncertainty. Assume uncertainty is present
when formulating your reply.
David B Lightstone
"Robert C. Martin" <rmartin @ objectmentor . com> wrote in message
news:dlq00uc1lr26lvbtk...@4ax.com...
> On Fri, 23 Nov 2001 23:38:40 GMT, "David B Lightstone"
> <david.li...@prodigy.net> wrote:
>
> >> Requirements gathering practices and validating requirements are
> >> "outside of XP".
> >
> >But isn't this the root cause of the Software Development Crisis?
>
> It is true that one prominent cause of project failure is a failure of
> requirements gathering.
>
> It is not quite true that gathering and validationg requirements is
> outside of XP. It's also not quite false. XP does not provide any
> guidance or practices for elucidating, gaterhing, and elaborating
> requirements.
What about Product Configuration, is that also something
about which Xp has no guidance?
As Product Configuration changes how is the change managed?
David B Lightstone
>
> "David B Lightstone" <david.li...@prodigy.net> wrote in message
> news:P9SL7.926$Tb7.25...@newssvr16.news.prodigy.com...
> >
> > "John Roth" <john...@ameritech.net> wrote in message
> > news:tvvkjdd...@news.supernews.com...
> > >
> > > "David B Lightstone" <david.li...@prodigy.net> wrote in message
> > > news:DwML7.623$Wc2.10...@newssvr17.news.prodigy.com...
> > > >
> >
> > >
> > > David points out that XP shoves this responsibility onto the
> > > customer's shoulders. This is quite true, and I don't think
> > > it's a defect in the XP methodology.
> > >
> >
<snip>
> This is what I meant by 'scope' earlier. In a global analysis,
> it's quite true that shoving a problem onto someone else's turf
> may cause it to be unsolved, or solved incorrectly. However, we
> do need to understand separation of responsibility.
>
>
> Taking over someone else's responsibility because they are
> not doing it may get the job done in the short term, but it
> leads to confusion in the long term.
>
That all depends upon whether the responsibility transfer
is a unilateral decision or a negociated decision. That all
depends upon the extent and nature of the negociating
authority that is present
Responsibilities are idealizations. They never are seen in
their pure form, but they do make discussions more convient.
When uncertainty is present, and it rarely is absent prior to
product delivery and signoff, responsibilities ebb and flow.
It is a judgement call as to whether the ebb and flow is long
or short term. That call is a negociation at a much higher level
between the organizations
In a sense those decisions may pretty much mean that higher
management has decide that XP (in its true sense) will be
abandoned in favor of a locally modified variation on XP
(which the XP adherants may term a perversion)
<snip>
> >
> > I have never seen the clean boundary between Development
> > and Analysis that you seem to preceive.
<snip>
>
> The fuzzyness of the boundary is common in all endevours.
> Most programmers with any experiance feel that the analysts
> have messed up the requirements somewhere, and they are
> frequently (although not always) correct.
>
> My own domain, business systems
> (mainly financial, credit and insurance) has nothing that
> could not be done by a hoard of well trained and motivated
> clerks, so the customer shouldn't have a tremendous amount
> of difficulty creating requirements. Business analysts are
> useful, but not always necessary.
>
> Embedded real time is quite different in that there is no
> parallel manual process. I shudder to think of operating
> an oil refinery (of which there are several within a few miles
> of here) manually, let alone a nuclear power plant or a
> CAT scanner.
>
> In that domain, the requirements would seem to be
> something that are worked out with the engineers building
> the machinery to be controlled, and there doesn't seem to
> be a clean boundary.
>
In addition to safety systems, I am inclinded to believe
that XP is inappropriate for embedded systems.
The inappropriateness for embedded systems is based
upon the preceived inability of XP handle the problem solving activities
associated with uncertainty in the requirements.
>
> My other domain, operating systems, mostly seems to
> operate on requirements that have been synthesized out of
> thin air, which I suppose says something or other.
>
> The original XP project (CCC - Chrysler Compensation) was
> a payroll application; the client knew exactly what they wanted,
> and had little or no difficulty in stating it.
>
I generally don't follow Business case studies. Has the
reason for the success been carefully analysed, or is
it just being claimed as a success?
If a post project review was conducted was perchance
success attributable to No requirements to manage.?
James A. Robertson
>>The Extreme Programming (XP) methodology is a set of principles and
>>practices for developing software. It has been described as a
>>"high-discipline, low-overhead" methodology. XP has developers
>>programming in pairs, writing tests to verify all code, and continuously
>>refactoring code to improve the design. To quote Kent Beck: "XP is a
>>starting line. It asks the question, 'How little can we do and still
>>build great software?'"
>>
>>
>
> I don't like writing in pairs. It bothers me to code with
> somebody watching me and breathing down my neck.
> Only the most social of people like that, and they
> are probably in sales.
It's not 'being watched' - I've done it, and it works very well - it's a
matter of letting whoever has the best current idea drive, and the
letting the other person make suggestions.
>
> And, most female programmers are not the pick of
> the litter in the looks department, so pairing is
> not likely to result in something that would
> allow woody to fill us full of endorhpines to
> improve the experience.
Wow. Where did this come from?
>
> Instead, programmers are mostly fat, hairly,
> ugly trolls with bad breath and BO and funny
> voices. I should know, I'm one.
Wow.
Keith Ray
> What about Product Configuration, is that also something
> about which Xp has no guidance?
>
> As Product Configuration changes how is the change managed?
However it needs to be managed.
David B Lightstone
"Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
I will choose to interpret that to mean that it is outside
the scope of that which XP addresses. XP offers no
guidance what-so-ever.
H. S. Lahman
>>Peer code review, fine; but why the pair stuff?
>>
>
> Because it has been shown, by experiment, to produce better
> results. You're well known for asking for evidence. Given that
> all the evidence in this case says that pair programming is
> better than solo programming, are you going to ignore it?
I think the jury is still out on this. The only hard data that I know
of was in a recent PhD thesis from the UoUtah. In those experiments
pair programming did well except in the area of productivity; the pairs
took about 60% longer (total effort time) than singles.
However, that thesis did not address compensating factors in real
environments (e.g., the singles were true singles w/o peer reviews) so
the productivity results were inconclusive.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH
Ron Jeffries
<david.li...@prodigy.net> wrote:
>> >> >Having an expert does not manage a problem, it conceals the need to manage
>> >> >the problem
>> >>
>> >> Do you know of a way to gather and validate requirements without a
>> >> domain expert?
>> >
>> >The issue is not the knowledge provided by the expert, it is
>> >it's consistency, and temporal change. Those are the things which
>> >are to be managed
>>
>> What's unmanaged about the way XP does it?
>
>I do not understand the question, are you claiming that
>that those things are managed, or just engaging in a little
>trolling for answers to things you know little about.?
I believe you claimed that XP does not manage requirements gathering
and validation. I'm asking you to support the claim. If, of course,
you're not claiming that, then no need to support it.
I do know a little something about XP. See, for example,
http://www.amazon.com/exec/obidos/ASIN/0201708426/armatiesA .
Ron Jeffries
<david.li...@prodigy.net> wrote:
>> You keep acting like the Customer (whose job title may be Product
>> Manager, Project Manager, Planner, Designer, Requirements Analyst or
>> Problem Solver), is not part of the team.
>>
>> It is One Team.
>
>That is the theory of the practice. What is the reality?
All the XP projects I have been a part of have had a person in the
role of customer who had the authority and responsibility to decide
which features to do and which to defer.
I know of projects that are using some XP practices and not others,
including teams that do not have such a representative on the team.
I'm not sure why you asked. Why did you ask?
>When you state reality and theory are consistent,
>do be so kind as to substanciate your contention.
The poster was suggesting that you are speaking as if the customer is
not a team member, not that you are acting like a customer. The
customer _is_ a team member.
Ron Jeffries
<david.li...@prodigy.net> wrote:
>
>No, there is generally both uncertainty to resolve and a problem solving
>effort to conduct. You can't determine the results without doing something
>in cooperation with each other. The model - We will just implement it,
>tell us what you want us to do in this situation - is not applicable. That
>model appears to be the basis for XP.
You might find it useful to read some of the XP literature, if I may
use the term. "Books", if I may not use the term.
The model "we will just implement it, tell us what you want us to do
in this situation" is not a very good description of what we teach.
What we teach is far more cooperative than that, since we certainly
would agree with you that the process of figuring out what is to be
one needs to be a cooperative one.
It seems to me that there is always a process between the person with
the problem and the people doing the solution, and that the process is
always one of give and take, question and answer. "I want this. You
mean that? No, more like this other thing." This conversation
continues until the parties agree on what is going to be done.
XP follows exactly this process with the added characteristic that
every two weeks the project team delivers software doing what the
customer has so far asked for. This gives the customer feedback that
is more concrete than would be provided by a conversation or a
document.
One could argue that including running code in the conversation is
inefficient (although I think one would be mistaken). Efficient or
not, the process is highly cooperative, as you suggest that it should
be.
Does that aid your understanding?
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Sun, 25 Nov 2001 13:53:36 GMT, "David B Lightstone"
> <david.li...@prodigy.net> wrote:
>
> >> >The issue is not the knowledge provided by the expert, it is
> >> >it's consistency, and temporal change. Those are the things which
> >> >are to be managed
> >>
> >> What's unmanaged about the way XP does it?
> >
> >I do not understand the question, are you claiming that
> >that those things are managed, or just engaging in a little
> >trolling for answers to things you know little about.?
>
> I believe you claimed that XP does not manage requirements gathering
> and validation. I'm asking you to support the claim. If, of course,
> you're not claiming that, then no need to support it.
Your a big boy, as am I. Surely by now you know there are certain quesions for
which there can be no answer without an excessive amount of investigation.
I will simply say - Based upon the nature of information observed
I have long ago concluded that XP does not manage requirements
gathering and management. I do not wish to identify the specific chain
or reasoning. It is far more of a task than I desire to conduct at this time.
Instead I will suggest that you take the time and speak or correspond
with Robert Martin. He seems to have answered it.
You may if you wish disagree with him
"Robert C. Martin" <rmartin @ objectmentor . com> wrote in message
news:dlq00uc1lr26lvbtk...@4ax.com...
" It is not quite true that gathering and validationg requirements is
outside of XP. It's also not quite false. XP does not provide any
guidance or practices for elucidating, gaterhing, and elaborating
requirements. On the other hand, XP does suggest that the customer
and stakeholders be present every two weeks when the next iteration is
demonstrated. During those demonstrations, any mis-communication of
requirements is highly likely to stand out and get corrected.
I will interpret absense of guidence to be a marketing euphemism for
no
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
Quite. I know exactly where you stand. We each see the same
interaction problems, we each handle it differently. I will
leave it at that.
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Sun, 25 Nov 2001 14:18:38 GMT, "David B Lightstone"
> <david.li...@prodigy.net> wrote:
>
> >> You keep acting like the Customer (whose job title may be Product
> >> Manager, Project Manager, Planner, Designer, Requirements Analyst or
> >> Problem Solver), is not part of the team.
> >>
> >> It is One Team.
> >
> >That is the theory of the practice. What is the reality?
>
> All the XP projects I have been a part of have had a person in the
> role of customer who had the authority and responsibility to decide
> which features to do and which to defer.
>
> I know of projects that are using some XP practices and not others,
> including teams that do not have such a representative on the team.
> I'm not sure why you asked. Why did you ask?
The purpose of the question was to access how reality compares
with theory. You are fortunate to have had access to the customer
Pete McBreen
<4ScM7.1560$J82.26...@newssvr17.news.prodigy.com>...
>The purpose of the question was to access how reality compares
>with theory. You are fortunate to have had access to the customer
I'm really puzzled by your answer. On-site Customer is a game rule for
XP. By that I mean that if you want to do XP, you have to do everything
you can to make sure that the customer is a fully integral part of the
team.
So of course Ron is going to have access to the customer on his XP
projects, because if he did not, then he would either have to (A) stop
using XP or (B) figure out what had to be added to XP to compensate for
not being able to access the customer. If he chose B he would then have
to find out if it was just as effective as an On-site Customer, and if
not then he would still not be doing XP.
The game rule is that an XP team must do the most effective thing, and
since that involes access to the customer, why would you expect XP
practitioners to run projects without access to the customer?
Pete
p.s. I know it may sound strange, but from what I have seen of XP
projects it is very hard for a team to partially do the practices. It
seems to be a process that you have to follow more or less to the
letter. Yes, you can pick practices to apply inside other processes, but
everyone knows that is not the same as actually applying XP. Of course
this is totally opposite to some other processes where there is a big
gap between the espoused and actual process, but since Ron is one of teh
people involved in defining the process I guess it would be really
strange for him to say one thing and do another:-)
----
Pete McBreen, McBreen.Consulting , Cochrane, AB
email: petem...@acm.org http://www.mcbreen.ab.ca/
Author, "Software Craftsmanship The New Imperative"
Addison-Wesley (C) 2002
http://www.amazon.com/exec/obidos/ASIN/0201733862
Keith Ray
<k1e2i3t4h5r6a7y-68...@news1.rdc1.sfba.home.com>,
Keith Ray <k1e2i3t...@1m2a3c4.5c6o7m> wrote:
I will follow up by noting that I've heard that Rational Unified Process
has 8000 components, all of them optional.
XP has 13 non-optional core practices, and probably six or eight
recommended non-core (optional) practices (such as 15-minute daily
stand-up meeting), and whatever else the team might find that works with
the four values of Simplicity, Feedback, Communication, and Courage
(such as putting Story Cards on the wall, or the web, and marking each
of them complete when the Customer confirms that the acceptance tests
for each story are all passing.)
I don't know how much work (or make-work) you are implying by "Product
Configuration".
The idea in XP is that you do whatever is necessary to be able to run
your automated unit tests very frequently (multiple times per hour) and
your acceptance tests frequently (at least once per iteration, and
closer to daily), and the acceptance tests run end-to-end on a
configuration as much like the released version of the product as
possible. You also release the product at least once every iteration for
manual testing.
Whatever must be done frequently, should be automated, to avoid taking
up programmer's time, and to avoid mistakes. Thus automated unit tests,
and automated acceptance tests, and automated build processes.
Since XP "embraces change", the practices that "manage" change are done
repeatedly over the course of the project: Release Planning, and
Iteration Planning, both of which require Programmers and Customer to
work in cooperation with each other -- estimating, understanding,
prioritizing.
Peter Hansen
>
> In a sense those decisions may pretty much mean that higher
> management has decide that XP (in its true sense) will be
> abandoned in favor of a locally modified variation on XP
> (which the XP adherants may term a perversion)
Unlikely. See http://www.extremeprogramming.org/rules/fixit.html
for example, if you don't already know about XP's insistence
on adapting it for the circumstances..
> In addition to safety systems, I am inclinded to believe
> that XP is inappropriate for embedded systems.
>
> The inappropriateness for embedded systems is based
> upon the preceived inability of XP handle the problem solving activities
> associated with uncertainty in the requirements.
I see nothing about XP which is not consistent with its
use in developing embedded systems. Having spent most of
the last fifteen years working in this area, and having
actually *tried* to apply XP to it, I think my comments may
have some merit.
--
----------------------
Peter Hansen, P.Eng.
pe...@engcorp.com
Peter Hansen
>
> "Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote:
> > "David B Lightstone" <david.li...@prodigy.net> wrote:
> > [...]
> > > What about Product Configuration, is that also something
> > > about which Xp has no guidance?
> > >
> > > As Product Configuration changes how is the change managed?
> >
> > However it needs to be managed.
>
> I will choose to interpret that to mean that it is outside
> the scope of that which XP addresses. XP offers no
> guidance what-so-ever.
False, of course. You really need to read more about XP.
Or read about it at all. Or stop pretending that you
don't understand the points it is trying to make by
interpreting everything so narrowly. Stop trolling.
If nothing else, the guidance that XP provides in a situation
like the above is the same it provides in all situations:
do the simplest thing that could possibly work.
Some projects are so short that any formal effort expended
on Product Configuration would be considered a waste.
(I'm willing to go without agreeing on a precise definition
of this here.... remember my comment about not interpreting
things too narrowly?)
Considered by whom? By the customer of course. If the
customer does not want to invest in anything termed Product
Configuration, the development team has no business spending
the customer's resources on it.
Other projects require (let's assume) something called
Product Configuration. What guidance does XP give on
handling that? Do the simplest thing that could possibly
work. As in, it could be considered project-dependent.
Maybe the most effective thing will be to buy a solution
ready-made. Or do something else, something appropriate.
If you were to define a hypothetical project, and describe
what Product Configuration means to you and how it would
apply to that project, and we imagined that our hypothetical
customer actually insisted on having some, I suspect you
would get a lot of interesting suggestions in this group
about very effective, lightweight, and perhaps novel
approaches to the problem.
*That* is the guidance XP gives. Not something "canned"
and inflexible, inappropriate to new situations. If you
don't understand the point here (as opposed to just
disagreeing with it), you're a lost cause I'm afraid.
If you can neither understand nor agree with these things,
why do you spend so much time posting?
(Apologies for the continued cross-posting, as it seems
to be an XP discussion, but I don't subscribe to c.s-e
and can't judge whether it is inappropriate there.)
David B Lightstone
"Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
> In article
> <k1e2i3t4h5r6a7y-68...@news1.rdc1.sfba.home.com>,
> Keith Ray <k1e2i3t...@1m2a3c4.5c6o7m> wrote:
>
> > In article <5y7M7.1254$Rg.350...@newssvr16.news.prodigy.com>,
> > "David B Lightstone" <david.li...@prodigy.net> wrote:
> > [...]
> > > What about Product Configuration, is that also something
> > > about which Xp has no guidance?
> > >
> > > As Product Configuration changes how is the change managed?
> >
> > However it needs to be managed.
>
> I will follow up by noting that I've heard that Rational Unified Process
> has 8000 components, all of them optional.
The inssue is not Rational Uniied Practice, rather it is XP.
More importantly the issue is not the Product Configuration of XP
considerer as a Product, but rather the manner by which XP, the Product
being marketed, addresses configuration management of the Product
under development by means of the XP method
>
> XP has 13 non-optional core practices, and probably six or eight
> recommended non-core (optional) practices (such as 15-minute daily
> stand-up meeting), and whatever else the team might find that works with
> the four values of Simplicity, Feedback, Communication, and Courage
> (such as putting Story Cards on the wall, or the web, and marking each
> of them complete when the Customer confirms that the acceptance tests
> for each story are all passing.)
>
so there are at least 256 differnet versions of XP, on corresponding to the
presense of absense of each of the 8 recomended non-core (optional)
paractices.
Far to much variation to conduct meaningful statistics on what paractices
do or do not work.
>
> I don't know how much work (or make-work) you are implying by "Product
> Configuration".
See Software Configuration Management An Investment in Product Integrity
by E Bersoff, V Henderson, and S Siegel
<snip of advertisement>
Keith Ray
"David B Lightstone" <david.li...@prodigy.net> wrote:
[a lot of stuff, but ignoring
"I don't know how much work (or make-work) you are implying by
"Product Configuration". ]
> More importantly the issue is not the Product Configuration of XP
> considerer as a Product, but rather the manner by which XP, the Product
> being marketed, addresses configuration management of the Product
> under development by means of the XP method
I'm not marketing, I'm trying to answer questions. I can't tell you
about XP's stance on "Product Configuration" unless you describe what
you mean by those words.
> Far to much variation to conduct meaningful statistics on what paractices
> do or do not work.
We are people, not statistics. We see what practices work by actually
using them.
I've read books on "Software Configuration Management", but their
assumptions were too alien to correlate with XP and the ways I have seen
companies and people actually work.
What do YOU mean by "Software Configuration Management"?
@objectmentor.com Robert C. Martin
<david.li...@prodigy.net> wrote:
>What about Product Configuration, is that also something
>about which Xp has no guidance?
>
>As Product Configuration changes how is the change managed?
What do you mean by "Product Configuration"?
Ron Jeffries
<david.li...@prodigy.net> wrote:
>> I believe you claimed that XP does not manage requirements gathering
>> and validation. I'm asking you to support the claim. If, of course,
>> you're not claiming that, then no need to support it.
>
>Your a big boy, as am I. Surely by now you know there are certain quesions for
>which there can be no answer without an excessive amount of investigation.
By which I take it you mean: you'd rather not read a book to learn
what XP is. That's OK, but please recognize that until you study it,
you won't know quite as much about it.
>
>I will simply say - Based upon the nature of information observed
>I have long ago concluded that XP does not manage requirements
>gathering and management. I do not wish to identify the specific chain
>or reasoning. It is far more of a task than I desire to conduct at this time.
>Instead I will suggest that you take the time and speak or correspond
>with Robert Martin. He seems to have answered it.
I know Bob rather well, since among other things I co-teach the XP
Immersion with him ...
>
>You may if you wish disagree with him
I often do, in matters of detail. I note, however, that in this case
it seems to be you who is disagreeing with him, which is odd as you
also seem to be citing him as the authority:
>
>"Robert C. Martin" <rmartin @ objectmentor . com> wrote in message
>news:dlq00uc1lr26lvbtk...@4ax.com...
>
>" It is not quite true that gathering and validationg requirements is
>outside of XP. It's also not quite false. XP does not provide any
>guidance or practices for elucidating, gaterhing, and elaborating
>requirements. On the other hand, XP does suggest that the customer
>and stakeholders be present every two weeks when the next iteration is
>demonstrated. During those demonstrations, any mis-communication of
>requirements is highly likely to stand out and get corrected.
>
>I will interpret absense of guidence to be a marketing euphemism for
>no
That's odd. Here and in my own more detailed description of the
feedback cycle between "customer requests" and "programmer programs"
provides feedback for verification (customer tests) and validation
(customer sees running program every two weeks).
But I see you have made up your mind. I merely leave these materials
here in case others are reading the thread.
Regards,
H. S. Lahman
> I think the jury is still out on this. The only hard data that I know
> of was in a recent PhD thesis from the UoUtah. In those experiments
> pair programming did well except in the area of productivity; the pairs
> took about 60% longer (total effort time) than singles.
I got the number right but not the description. What the thesis
determined was that each pair member spent 55-60% of the effort hours of
the single. Since there are two pair memebrss, the combined pair team
spent 10-20% more hours. Sorry about that.
Universe
>
>"Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote in message
>news:k1e2i3t4h5r6a7y-17...@news1.rdc1.sfba.home.com...
>> In article
>> <k1e2i3t4h5r6a7y-68...@news1.rdc1.sfba.home.com>,
>> Keith Ray <k1e2i3t...@1m2a3c4.5c6o7m> wrote:
>>
>> > In article <5y7M7.1254$Rg.350...@newssvr16.news.prodigy.com>,
>> > "David B Lightstone" <david.li...@prodigy.net> wrote:
>> > [...]
>> > > What about Product Configuration, is that also something
>> > > about which Xp has no guidance?
>> > >
>> > > As Product Configuration changes how is the change managed?
>> >
>> > However it needs to be managed.
>>
>> I will follow up by noting that I've heard that Rational Unified Process
>> has 8000 components, all of them optional.
>
>The inssue is not Rational Uniied Practice, rather it is XP.
Especially since Rational Unified Process no longer exists.
There is a Unified Process that is an open standard under the Object
Management Group (OMG).
>> I will follow up by noting that I've heard that Rational Unified Process
>> has 8000 components, all of them optional.
8000 configuration mgt components? UP doesn't have 8k of anything.
Be nice to know what of you speak when trying to make a point.
Elliott
Leonard Fehskens
>>Maximize the opportunity for misunderstanding and changing
>>interpretation by establishing a word of mouth culture
>
> Because writing down what you don't quite mean in a form the reader
> can't quite understand is so much better? On the contrary, it's pretty
> well established that continuing conversation works better for
> reaching understanding and agreement than any written form of
> communication.
It seems to me that this is not an either/or situation. Conversation is
a great way of *achieving* shared understanding, and writing the result
down is a great way of *preserving* that understanding. It is possible to
have conversations about what is eventually written down to confirm that it
accurately captures what was agreed to.
len.
@objectmentor.com Robert C. Martin
<len.fe...@compaq.com> wrote:
>It seems to me that this is not an either/or situation. Conversation is
>a great way of *achieving* shared understanding, and writing the result
>down is a great way of *preserving* that understanding. It is possible to
>have conversations about what is eventually written down to confirm that it
>accurately captures what was agreed to.
Good. Now, how do we write something down in a way that confirms that
it is what we talked about.
Most of us have read enough legal documents to know that the problem
removing ambiguity tends to clutter and opacify a document. Documents
that are unambiguous tend also to be full of formalities, stilted
statements, and tedious details.
In XP we've decided that if we're going to write something down, it
might as well be in the most unambiguous and useful form possible -- a
test. We converse about the requirements until it's time to implement
them; and then the customers write acceptance tests that describe
those requirements; and the programmers write unit tests that describe
their solutions to those requirements.
Those tests *are* the documentation of the system. They are also so
unambiguous that they are executable by a computer. Acceptance tests
document the requirements. Unit tests document the design.
Gerold Keefer
> In XP we've decided that if we're going to write something down, it
> might as well be in the most unambiguous and useful form possible -- a
> test. We converse about the requirements until it's time to implement
> them; and then the customers write acceptance tests that describe
> those requirements; and the programmers write unit tests that describe
> their solutions to those requirements.
>
> Those tests *are* the documentation of the system. They are also so
> unambiguous that they are executable by a computer. Acceptance tests
> document the requirements. Unit tests document the design.
as i said it before:
"an acceptance test (case) is a mean to validate a system against it´s
requirements. if you do not explicitly state the requirment you will
inevitably loose crucial information and your set of test cases will very
likely eventually loose it´s sense, because it is a proof against the void."
regards,
gerold
@objectmentor.com Robert C. Martin
<vze2...@verizon.net> wrote:
>Responding to Lahman...
>
>
>> I think the jury is still out on this. The only hard data that I know
>> of was in a recent PhD thesis from the UoUtah. In those experiments
>> pair programming did well except in the area of productivity; the pairs
>> took about 60% longer (total effort time) than singles.
>
>
>I got the number right but not the description. What the thesis
>determined was that each pair member spent 55-60% of the effort hours of
>the single. Since there are two pair memebrss, the combined pair team
>spent 10-20% more hours. Sorry about that.
(for those interested, you can find the research papers in question at
www.pairprogramming.com)
You forgot to mention that the 5-10% deviation from 50% was not
statistically significant. In her talks on the subject, the author of
the paper, Laurie Williams, attributed the productivity loss to one
particularly slow pair in the study. (a couple of extroverts who
apparently spent more time talking than coding). All the other pairs
clustered closely around the 50% mark, meaning that no productivity
was lost at all.
The study also captures some other interesting statistics. For
example, the defect rate of the pairs was significantly less than the
singles, and the difference *was* statistically significant. Also the
enjoyment rate of the pairs was significantly higher than that of the
singles. Since the study did not measure the time necessary to repair
defects, one could infer that the pairs were actually *more*
productive than the singles, since they had significantly fewer
defects to repair.
Anecdotally, I can tell you that of the many teams we have coached in
XP, none of them have noted a productivity decline. None of the teams
are about to give up pairing.
Tom Plunket
> I got the number right but not the description. What the thesis
> determined was that each pair member spent 55-60% of the effort hours of
> the single. Since there are two pair memebrss, the combined pair team
> spent 10-20% more hours. Sorry about that.
As I recall, however, the pairs also passed far more of the
"acceptance tests." So that's the question- would you rather
software sooner, if it working properly is less important that
the date that you get it?
-tom!
--
Tom Plunket to...@fancy.org
PlayStation2/3D Studio geek
Change is inevitable. Progress is not.
Keith Ray
Universe <univ...@directvinternet.undocom> wrote:
> Especially since Rational Unified Process no longer exists.
You would think that they would mention that on
<http://www.rational.com/products/rup/index.jsp>
but apparently Rational still believes that it exists.
Leonard Fehskens
> Good. Now, how do we write something down in a way that confirms that
> it is what we talked about.
>
> Most of us have read enough legal documents to know that the problem
> removing ambiguity tends to clutter and opacify a document. Documents
> that are unambiguous tend also to be full of formalities, stilted
> statements, and tedious details.
I suspect this has to more to do with lawyering than the pursuit of
clarity. If I were to take this at face value, I'd have to dimiss
virtually all written works as worthless.
> In XP we've decided that if we're going to write something down, it
> might as well be in the most unambiguous and useful form possible -- a
> test. We converse about the requirements until it's time to implement
> them; and then the customers write acceptance tests that describe
> those requirements; and the programmers write unit tests that describe
> their solutions to those requirements.
>
> Those tests *are* the documentation of the system. They are also so
> unambiguous that they are executable by a computer. Acceptance tests
> document the requirements. Unit tests document the design.
Perfectly illustrating my point. You don't reconstruct unit or acceptance
tests from remembered conversations every time you need them. You write
them down.
len.
David B Lightstone
"Leonard Fehskens" <len.fe...@compaq.com> wrote in message
news:Xns91658A267DBC...@155.186.176.59...
I happen to agree with what is being said here, one must document agreements
in an effort to avoid misunderstandings. I consider that to be a managerial
strategy
I am now going to play devils advocate. This is not to say that I agree or
disagree
Is it possible that the feedback loops (the daily meetings, the various periodic
reviews etc) are sufficiently tight so as to make the need for the documention
irrelevant vis a vis the produced code, unit tests and acceptance test?
My opinions is that this is probably true on toy problems. I think it may also
be true
for classical problems (ie well studied) such as compliers and databases, (but
not
operating systems)
> len.
David B Lightstone
"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
> On Sun, 25 Nov 2001 20:34:09 GMT, "David B Lightstone"
> <david.li...@prodigy.net> wrote:
>
> >> I believe you claimed that XP does not manage requirements gathering
> >> and validation. I'm asking you to support the claim. If, of course,
> >> you're not claiming that, then no need to support it.
> >
> >
> >I will simply say - Based upon the nature of information observed
> >I have long ago concluded that XP does not manage requirements
> >gathering and management. I do not wish to identify the specific chain
> >or reasoning. It is far more of a task than I desire to conduct at this time.
> >Instead I will suggest that you take the time and speak or correspond
> >with Robert Martin. He seems to have answered it.
>
> I know Bob rather well, since among other things I co-teach the XP
> Immersion with him ...
> >
> >You may if you wish disagree with him
>
> I often do, in matters of detail. I note, however, that in this case
> it seems to be you who is disagreeing with him, which is odd as you
> also seem to be citing him as the authority:
>
If I am disagreeing with Mr Martin it is only in the meaning for
his statement.
Assuming that you do not disagree with Mr Martin, and the nature of you reply
does not lead me to believe that you and he disgree on the specific issue,
I suspect that you and I each preceive the statement to mean different
things.
I do not know how best to state this without being skating close to the
edge of insulting. It is an analogy which is the basis for my decision,
not an evaluation of either XP or it adherents.
As for suggesting that you contact him
I concluded that you had a professional association with Mr Martin.
You confirm the speculation. I observed his opinion, determined
that he was far more well informed then either you or I (don't ask
how) about the characteristic in question, and wondered why you
might have choosen to ignore his writting.
As for citing him as an authority
When discussing astrology, it is often best to defer to the works of
an astrologer. That does not mean that you believe in astrology.
That does not mean that you are refuting the beliefs of those who
believe in astrology. It just means that they are better able to
articulate the beliefs and policies of astrology
<snip>
David B Lightstone
"Peter Hansen" <pe...@engcorp.com> wrote in message
news:3C017408...@engcorp.com...
> David B Lightstone wrote:
> >
> > "Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote:
> > > "David B Lightstone" <david.li...@prodigy.net> wrote:
> > > [...]
> > > > What about Product Configuration, is that also something
> > > > about which Xp has no guidance?
> > > >
> > > > As Product Configuration changes how is the change managed?
> > >
> > > However it needs to be managed.
> >
>
> If nothing else, the guidance that XP provides in a situation
> like the above is the same it provides in all situations:
> do the simplest thing that could possibly work.
>
Without doubt given 2 or more choices it is outstanding "guidance"
to advise upon selection of the simpler of the two.
The generation of the choices, well that is a different question.
Leonard Fehskens
news:3ryM7.2605$9d4.40...@newssvr17.news.prodigy.com:
> Is it possible that the feedback loops (the daily meetings, the various
> periodic reviews etc) are sufficiently tight so as to make the need
> for the documention irrelevant vis a vis the produced code, unit tests
> and acceptance test?
Absolutely. As I replied elsewhere, the code, unit tests, and acceptance
tests *are* "written down" documentation. They are not reconstructed from
remembered conversations every time they are needed. As Bob Martin has
already noted, they are unambiguous. What is implicit in XP, and is just
as important as their precision, is their completeness.
len.
David B Lightstone
I guess I better make certain the question and answer are understoud.
Clearly performance of unit test or acceptance test necessitates that
the test be written down. When an automatic test execution machine
is availble it would be nice if the expression media were suitable
for execution on the machine. It that sense they most definitely are
not remembered by mortal human beings
In my life I have observed that the effort (time specifically) needed
to accomplish an implementation is often far greater than the amout
of time that will be spent in writting down something as documentation
(ie I am not talking about meeting notes here)
So I rephrase the question for purposes of clarifying what I have ment
by tight enought feedback.
Do you mean that the meeting notes are adequate as directions for
implementing the code, unit test and acceptance test?
>
> len.
>
>
Ron Jeffries
<david.li...@prodigy.net> wrote:
>
>As for suggesting that you contact him
>I concluded that you had a professional association with Mr Martin.
>You confirm the speculation. I observed his opinion, determined
>that he was far more well informed then either you or I (don't ask
>how) about the characteristic in question, and wondered why you
>might have choosen to ignore his writting.
Bob wrote Extreme Programming in Practice (with James Newkirk). I
wrote Extreme Programming Installed (with Ann Anderson and Chet
Hendrickson).
We rarely disagree. I don't think we disagree this time. If we do,
he's wrong. ;->
Universe
> David B Lightstone wrote:
> >
> > "Keith Ray" <k1e2i3t...@1m2a3c4.5c6o7m> wrote:
>> > "David B Lightstone" <david.li...@prodigy.net> wrote:
>> > > [...]
> > > > What about Product Configuration, is that also something
> > > > about which Xp has no guidance?
> > > >
> > > > As Product Configuration changes how is the change managed?
> > > However it needs to be managed.
> >
<snip>
>
> If nothing else, the guidance that XP provides in a situation
> like the above is the same it provides in all situations:
> do the simplest thing that could possibly work.
Now that, I'm that is real guidance on the part of XP.
> c:
Elliott
Peter Hansen
> > like the above is the same it provides in all situations:
> > do the simplest thing that could possibly work.
>
> Now that, I'm that is real guidance on the part of XP.
I think I understand what you mean (syntax error: hard to
parse) but I'm not sure that you understood what *I* meant. :)
In the world of software methodologies, some people
like "agile" (lightweight) ones while others seem
to like "comprehensive" (heavyweight) ones. Those
of us who like agile methods would tend to say that
in some areas, you don't *want* a lot of guidance.
Or the guidance you do get should be very easy to
follow. If you have to read fifty pages and buy
a tool and learn a new paradigm to do something,
there's a good chance you won't really end up
doing it, or you'll do it only half-heartedly.
If it's worth doing, but you burden yourself or
your team so much with processes that you or they
can't function, you won't actually do it anyway.
XP would give you the guidance (and the confidence)
to say "screw that!" and dump the heavyweight,
under-performing process and lead you towards
something more effective in your particular context.
No other development philosophy has tried so hard
to keep people focused on what matters. This is
the guidance I find valuable in XP. You may deride
it, but it's working for me and my team. As Ron
likes to say, it's working for a lot of groups.
Sounds like it may be on to something, guidance
or non-guidance ...
Ron Jeffries
wrote:
>In the world of software methodologies, some people
>like "agile" (lightweight) ones while others seem
>to like "comprehensive" (heavyweight) ones. Those
>of us who like agile methods would tend to say that
>in some areas, you don't *want* a lot of guidance.
>Or the guidance you do get should be very easy to
>follow. If you have to read fifty pages and buy
>a tool and learn a new paradigm to do something,
>there's a good chance you won't really end up
>doing it, or you'll do it only half-heartedly.
I'd just add this: the agile methods are about "individuals and
interactions over processes and tools".
We really do trust that if you put skilled people together, in the
presence of lots of feedback and conversation, they will use their
skills appropriately to the situation.
Skills are important. The skill that is most worth having is the skill
to draw from one's bag of tricks, the trick appropriate to the
situation. That's something that no guideline, checklist, or manual
can ever provide.
The rule "do the simplest thing that could possibly work" reminds us
to apply our tricks wisely, as follows:
1. Don't bother to do things that are so simple they obviously could
NOT work.
2. From what's left, tend to choose the simpler things first. They
often work and they save you time for the hard stuff that remains.
(The above sentence is reminiscent of something Paul McReady said
in his OOPSLA keynote a few years back. Anyone got his exact quote
handy?)
Regards,
Leonard Fehskens
> Do you mean that the meeting notes are adequate as directions for
> implementing the code, unit test and acceptance test?
I believe that the consensus of the XP community is "yes", but there
are underlying assumptions that have to be valid. For example, the
scope is a story and its task(s), not an entire project, and the
conversation included all the stakeholders.
XP's focus is on delivering high quality (correct, simple, comprehensible,
adaptable) code, quickly. Its virtue is the clarity and singlemindedness
of that focus. If you need more than high quality code, quickly, you may
need something in addition to (not necessarily something else instead of)
XP. If, for example, you need to share knowledge outside the scope of the
project team, you may need other forms of documentation that are less
precise and more abstract than the code, unit tests and acceptance tests.
As always, your mileage may vary...
len.
John A. Byerly
> On Tue, 27 Nov 2001 00:16:23 -0500, Peter Hansen <pe...@engcorp.com>
> wrote:
>
> I'd just add this: the agile methods are about "individuals and
> interactions over processes and tools".
>
> We really do trust that if you put skilled people together, in the
> presence of lots of feedback and conversation, they will use their
> skills appropriately to the situation.
Except that sports teams have proved that this doesn't work (many times,
actually). A team of stars is assembled, and much to everyone's surprise,
they get stomped by a well-managed team of no-names.
Sorry, you can't throw away process and hope that the skilled people will
figure it out for themselves.
> Skills are important. The skill that is most worth having is the skill
> to draw from one's bag of tricks, the trick appropriate to the
> situation. That's something that no guideline, checklist, or manual
> can ever provide.
And if more than one trick is appropriate?
There is no problem with guidelines. There is a problem with people who
treat guidelines as rules. Use a guideline as a guideline and you are much
better off than if you had no guideline at all.
> The rule "do the simplest thing that could possibly work" reminds us
> to apply our tricks wisely, as follows:
>
> 1. Don't bother to do things that are so simple they obviously could
> NOT work.
>
> 2. From what's left, tend to choose the simpler things first. They
> often work and they save you time for the hard stuff that remains.
The problem is, I have seen solutions rejected in 1) that should not have
been, and solutions pursued in 2) that should not have been. In every case,
a little more thought about the problem would have saved much time by
resulting in a more directed approach.
JAB
--
--------------------------------------------------------
John A. Byerly
Engineered Software Solutions, Ltd.
http://www.ess-quality.com
John A. Byerly
> In the world of software methodologies, some people
> like "agile" (lightweight) ones while others seem
> to like "comprehensive" (heavyweight) ones. Those
> of us who like agile methods would tend to say that
> in some areas, you don't *want* a lot of guidance.
> Or the guidance you do get should be very easy to
> follow. If you have to read fifty pages and buy
> a tool and learn a new paradigm to do something,
> there's a good chance you won't really end up
> doing it, or you'll do it only half-heartedly.
If I had to read 50 pages, and buy a tool, and learn a new paradigm, I
_will_ end up doing it. It's called investment. I have read 1000s of
pages, bought many tools, and continue to learn new paradigms. At what
point should I stop? Before or after I read about and learn the XP
paradigm?