Deep within the 'Irony' thread was a
question as to what 'software development
process' specifically dealt with the
instance 'where management requirements
and customer requirements aren't aligned.'

The quick answer was 'any methodology
that gets requirements sign-off', which
generated a spate of 'well, what if....'
objections.

It's not sign-off per se that addresses
requirements misalignment, but the activity
preceeding sign-off, requirements analysis.

The project manager (and team) review the
requirements for certain attributes. If they
find requirements out of alignment with one another,
then they are re-negotiated, re-worked until
alignment is achieved. There won't be sign-off
until the requirements are clean, and there
certainly won't be a project if they remain
out of alignment.

There was a "What if management changes mid-stream?"
objection.

Well, in a classically managed project; you'd
have documented business goals, measures, estimated
costs and a written strategy (and requirements)
to achieve the goals. In short, enough written
description for the new management to decide
whether they agree or disagree with the project.
It's their prerogative to maintain, cancel or
alter the project.

Another objection was "what if the requirements
are what the customer asked for, but not what
the customer wants?"

Frankly, if you have not captured what the customer
wants, in business terms, then you've done a terrible
job of gathering and/or documenting the requirements.
The practioner fell down, not the methodology.

There are lots of tools and techniques for gathering
and understanding requirements. Learn them, get good
at them, and use them.

FWIW, I agree with the person who suggested that the
root business requirements really change very little.
That matches my experience as well.

Finally, the sentiment "...customers seldom know
what they really want..." is probably the most
disrespectful and condescending notion I've heard
come out of a discipline that holds "Open and Honest
Communication" as a core value.

The customer always knows exactly what they want
from a business perspective. If you can't figure it out,
your requirements gathering skills need work.

Scott Kinney
Project Manager
Amateur Barbarian

"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:DvednZ53mY4OAxfd4p2dnA@comcast.com...
> Deep within the 'Irony' thread was a
> question as to what 'software development
> process' specifically dealt with the
> instance 'where management requirements
> and customer requirements aren't aligned.'

I haven't been following the thread, so this
is the first I've seen of this discussion.

> The quick answer was 'any methodology
> that gets requirements sign-off', which
> generated a spate of 'well, what if....'
> objections.

> It's not sign-off per se that addresses
> requirements misalignment, but the activity
> preceeding sign-off, requirements analysis.

Exactly. One of the things I find isn't emphasized
by the XP literature out there is that the standard
requirements analysis is split into two distinct
activities. The first activity does "just enough"
analysis to pull the project together, create
the story cards, get them estimated and lay
out a tentative release plan.

The second activity takes each story card
and fleshes it out into the Automated Acceptance
Tests. This activity is either the first activity in
implementing the story, or takes place on the
iteration prior to the planned implementation.

> The project manager (and team) review the
> requirements for certain attributes. If they
> find requirements out of alignment with one another,
> then they are re-negotiated, re-worked until
> alignment is achieved. There won't be sign-off
> until the requirements are clean, and there
> certainly won't be a project if they remain
> out of alignment.

I think the process is somewhat different, but
the goal is the same. If different stakeholders'
requirements are not in alignment, you can't
get "the customer speaks with one voice."

> There was a "What if management changes mid-stream?"
> objection.

That's actually what happened to C3, with rather
disasterous results from all the stories I've heard.

> Well, in a classically managed project; you'd
> have documented business goals, measures, estimated
> costs and a written strategy (and requirements)
> to achieve the goals. In short, enough written
> description for the new management to decide
> whether they agree or disagree with the project.
> It's their prerogative to maintain, cancel or
> alter the project.

That's primarily a customer side responsibility,
but even in XP, the project manager should have
the complete list of stories, the estimates and the
release plan for the next release. All of those are,
of course, not only subject to change, but will
change. That is not, however, an excuse for not
having a complete picture at any given time.

> Another objection was "what if the requirements
> are what the customer asked for, but not what
> the customer wants?"

> Frankly, if you have not captured what the customer
> wants, in business terms, then you've done a terrible
> job of gathering and/or documenting the requirements.
> The practioner fell down, not the methodology.

Agreed. Unfortunately, this happens a lot.

> There are lots of tools and techniques for gathering
> and understanding requirements. Learn them, get good
> at them, and use them.

Many of those tools and techniques come out
of the "we have to have all the requirements nailed
down up front because changing any detail is going
to be horribly expensive" school of thought. As I
said above, there's a certain amount of requirements
analysis that has to be done up front or you don't
have a project, but the rest not only can be, but
should be deferred until the work product is
actually needed.

> FWIW, I agree with the person who suggested that the
> root business requirements really change very little.
> That matches my experience as well.

Well, yes. Most application domains are not going
to change over the course of a project, and if they
do, the company is going to have other concerns than
business automation while it adapts.

> Finally, the sentiment "...customers seldom know
> what they really want..." is probably the most
> disrespectful and condescending notion I've heard
> come out of a discipline that holds "Open and Honest
> Communication" as a core value.
>
> The customer always knows exactly what they want
> from a business perspective. If you can't figure it out,
> your requirements gathering skills need work.

Well, here I'm going to both agree and disagree with
you. The customer does know what they want from
a business perspective, but that doesn't mean they
know exactly what they want the system to do in
the detail needed to implement it. Some do, some
don't, and the degree of fog varies all over the lot.
As the old saying goes, the devil is in the details.

John Roth

> Scott Kinney
> Project Manager
> Amateur Barbarian

Scott Kinney wrote:

> Deep within the 'Irony' thread was a
> question as to what 'software development
> process' specifically dealt with the
> instance 'where management requirements
> and customer requirements aren't aligned.'

Yes, I believe that I asked this question.

> The quick answer was 'any methodology
> that gets requirements sign-off', which
> generated a spate of 'well, what if....'
> objections.

Yes, and all of these objections were relevant to the context of the 
project that was being referred to as an example.

> It's not sign-off per se that addresses
> requirements misalignment, but the activity
> preceeding sign-off, requirements analysis.

If you wish to perform "requirements analysis", that's fine, but IMHO it 
does not address all of the "what if"s that were mentioned, particularly 
when a manager is lying to higher levels of management (who do not have 
the time to be involved in "requirements analysis").

> The project manager (and team) review the
> requirements for certain attributes. If they
> find requirements out of alignment with one another,
> then they are re-negotiated, re-worked until
> alignment is achieved. There won't be sign-off
> until the requirements are clean, and there
> certainly won't be a project if they remain
> out of alignment.

You are still not considering the fact that this "misalignment" may be 
occurring higher up within the organization. The CEO of a company, or 
the   Senior Vice President, or Vice President, or ..., for example, are 
not expected to attend every meeting during "requirements analysis".

> There was a "What if management changes mid-stream?"
> objection.
> 
> Well, in a classically managed project; you'd
> have documented business goals, measures, estimated
> costs and a written strategy (and requirements)
> to achieve the goals. In short, enough written
> description for the new management to decide
> whether they agree or disagree with the project.
> It's their prerogative to maintain, cancel or
> alter the project.

Yes, and they chose to cancel. Where's the beef?

> Another objection was "what if the requirements
> are what the customer asked for, but not what
> the customer wants?"
> 
> Frankly, if you have not captured what the customer
> wants, in business terms, then you've done a terrible
> job of gathering and/or documenting the requirements.

Rudeness objection.

I prefer working with humans rather than robots, and sometimes humans 
make mistakes, even customers (and even me). I prefer to work with the 
customer and try to correct mistakes as early as possible, whether they 
are the customer's or mine (which of course is a very rare event :), or 
even someone else's on the team.

The customer team contains the domain experts. If they are wrong about 
what *they think* that they want, I prefer to try to adopt myself to 
this change in understanding on *their* part. IMHO, this is not even a 
mistake, but actually an expected event, see below.

> The practioner fell down, not the methodology.

Not at all. If the customer team indicates that what was delivered is 
exactly what the customer team asked for, then what was delivered is 
what the customer team *thought* they wanted at the start of the 
project. They are indicating that the development team did the correct 
job that they were asked to do. The developers came through, why would 
you indicate otherwise?

The customer team is indicating that their understanding was off to some 
degree earlier in the project. This happens all the time. IMHO, this is 
human nature. It's almost along the lines of "the grass is greener" or 
"appearances can be deceiving". Often things seem to be more attractive 
for some purpose than they really are until we get to experience them 
for ourselves.

You are completely overlooking the possibility that the customer team 
might actually learn something during the course of a project, as they 
gain experience with what is being created. The fact that a software 
development project needs to be undertaken highly suggests that 
something exactly like it does not already exist, so the customer team 
is going to be lacking some relevant experience to at least some degree. 
This is despite the fact that they are the real domain experts.

So, almost every software development project has a uniqueness aspect to 
it. When a project is somewhat unique, the customer has to try to 
anticipate what is going to be delivered. Customers are often not nearly 
as skilled at anticipating what the result of Use Case analysis will be. 
Furthermore, they may construct a model in their own mind that seems to 
be what they want. Until they actually have a chance to work with the 
resulting product, there is a high likelihood that the result will not 
be *exactly* what the customer wants or needs.

> There are lots of tools and techniques for gathering
> and understanding requirements. Learn them, get good
> at them, and use them.

We're not talking about gathering requirements. I can gather 
requirements for months (been there done that) and do "requirements 
analysis" just fine. I just no longer *prefer* to do "requirements 
analysis" as a required lengthy step at the beginning of every project.

We're talking about the customer not being able to anticipate how useful 
what they *think* they want is actually going to be until they actually 
work with it. The greater the complexity of the system, and the more 
unique the project, the higher the likelihood that there will be some 
disparity between what they think they want at the beginning of the 
project and what they will realize that they really want or need at the 
end of the project. The only way to completely address this issue is to 
embrace the fact that the customer team will want to make changes 
throughout the course of the project.

That is probably one of the reasons why Change Orders are introduced in 
plan-driven approaches.

> FWIW, I agree with the person who suggested that the
> root business requirements really change very little.
> That matches my experience as well.

So, what would be the reason for Change Orders then? You indicate that 
the business requirements change very little and that you expect to have 
captured 100% of what the customer wants. Why would an organization ever 
need to go through a Change Order? In my experience, the more complex 
the project, the more likely Change Orders will occur in a plan-driven 
approach.

Further, I think that you misunderstood the point. I think the point was 
that the likelihood of the customer learning during a project is nearly 
guaranteed due to human nature. The same may not be true of changes due 
to the actual business changing.

There are businesses that have been around long enough that a core need 
they are looking to fill may not be changing much anymore. It is likely 
still changing but perhaps slowly enough that it might not impact the 
delivered vs wanted or needed issue much on a particular project.

> Finally, the sentiment "...customers seldom know
> what they really want..." is probably the most
> disrespectful and condescending notion I've heard
> come out of a discipline that holds "Open and Honest
> Communication" as a core value.

IMHO, it's more honest and less condescending than requiring people to 
be infallible.

> The customer always knows exactly what they want

IMHO, this view is very simplistic. This requires that customers be 
beyond human fallibility. Particularly with increasing complexity. Most 
non-technical people (business domain experts) cannot look at a complex 
design, with complex Use Cases and confidently say that the result will 
address what they actually need with 100% certainty. They may sign off, 
indicating that it *seems* like what they want, and that it is 
definitely in alignment with what they are asking for. But, at the end 
of the project, they will most likely have learned something, and would 
prefer that some changes be made.

I have seen 2 distinct approaches to dealing with this disparity between 
"what the customer asks for" and "what the customer really wants":
1) Some believe that /the customers are all idiots/.
2) Some believe that the customer doesn't "always knows exactly what 
they want" at the start of a project.

I prefer the second option, although I had trouble preserving the quote 
and working out all of the grammar.

> from a business perspective. If you can't figure it out,
> your requirements gathering skills need work.

Rudeness objection.

I have worked with teams that have successfully delivered projects with 
plan driven approaches with extensive upfront requirements gathering. 
I've done this at many levels, including as Project Manager and as head 
of a line of software at a company. These projects were considered 
successful by both the development team, the customer team, and 
management. Unfortunately, while some projects made it through rollout, 
more than one or two were shelved at the completion of development and 
testing. More than once, the stated reasons were that the business had 
changed too much or that the customer team had misjudged some of the 
requirements, when this feedback was even collected at all. I no longer 
prefer this approach because I have personally seen the benefits of 
"embrace change".

I prefer to work on what the customer team *know that they need* rather 
than what everyone thinks *might be needed*. I prefer to work on things 
in the priority that the customer team wants these things done. And, 
lastly, I prefer to gather feedback from the customer to make sure that 
what is being delivered is actually what the customer team wants and 
needs, not what they thought they wanted when they agreed to the 
requirements at the start of a project.

I prefer to focus on the fact that "Software development is people". If 
we were talking about hardware, then maybe robots would be desirable. 
Software development, however, is supposed to be able to adapt to changes.

If you don't want to work this way, that's completely 100% OK with me. 
I'm not asking you to change how you do things. But, I will defend what 
works for me, and what I think has worked for others.

> Scott Kinney
> Project Manager
> Amateur Barbarian

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

"John Roth" <newsgroups@jhrothjr.com> wrote in message
news:108m7b8t2icbpab@news.supernews.com...
>
> Exactly. One of the things I find isn't emphasized
> by the XP literature out there is that the standard
> requirements analysis is split into two distinct
> activities. The first activity does "just enough"
> analysis to pull the project together, create
> the story cards, get them estimated and lay
> out a tentative release plan.
>
> The second activity takes each story card
> and fleshes it out into the Automated Acceptance
> Tests. This activity is either the first activity in
> implementing the story, or takes place on the
> iteration prior to the planned implementation.
>
> > The project manager (and team) review the
> > requirements for certain attributes. If they
> > find requirements out of alignment with one another,
> > then they are re-negotiated, re-worked until
> > alignment is achieved. There won't be sign-off
> > until the requirements are clean, and there
> > certainly won't be a project if they remain
> > out of alignment.
>
> I think the process is somewhat different, but
> the goal is the same. If different stakeholders'
> requirements are not in alignment, you can't
> get "the customer speaks with one voice."
>

The part that seems to be missing from XP is the
review of  'the forest' in addition to the review of 'the trees'.
Mis-alignment is as often the result of conflicts between
requirements as it is flawed requirements themselves.

>
>>
> > Another objection was "what if the requirements
> > are what the customer asked for, but not what
> > the customer wants?"
>
> > Frankly, if you have not captured what the customer
> > wants, in business terms, then you've done a terrible
> > job of gathering and/or documenting the requirements.
> > The practioner fell down, not the methodology.
>
> Agreed. Unfortunately, this happens a lot.
>
> > There are lots of tools and techniques for gathering
> > and understanding requirements. Learn them, get good
> > at them, and use them.
>
> Many of those tools and techniques come out
> of the "we have to have all the requirements nailed
> down up front because changing any detail is going
> to be horribly expensive" school of thought.

Two quibbles:
1. Are you suggesting that you won't use effective tools
because you don't like a methodology that uses them?

2. Changing requirements, or even design details, is cheaper
on paper than it is in code, and production code at that.
That's  part of the value of doing those things up front.

> > Finally, the sentiment "...customers seldom know
> > what they really want..." is probably the most
> > disrespectful and condescending notion I've heard
> > come out of a discipline that holds "Open and Honest
> > Communication" as a core value.
> >
> > The customer always knows exactly what they want
> > from a business perspective. If you can't figure it out,
> > your requirements gathering skills need work.
>
> Well, here I'm going to both agree and disagree with
> you. The customer does know what they want from
> a business perspective, but that doesn't mean they
> know exactly what they want the system to do in
> the detail needed to implement it.

Requirements are 'what' and design is 'how'. Again,
in classical project management, design gets worked, reviewed
and agreed to when it's cheap and on paper.

Changes will certainly occur, and the project structure has to
have a mechanism that reflects the effect that changes will have on
the project as a whole, and then, for accepting or rejecting them.

"Jason Nocks" <nocksj@sourcextreme.com> wrote in > > requirements
misalignment, but the activity
>
> If you wish to perform "requirements analysis", that's fine, but IMHO it
> does not address all of the "what if"s that were mentioned, particularly
> when a manager is lying to higher levels of management (who do not have
> the time to be involved in "requirements analysis").
>

Let's leave the word 'lying' aside for the moment.

Managing communications, and playing politics are part of the job
of the project manager. The PM has to have or cultivate a
senior management champion (usually it's the project sponsor, but
it's better to have more than one champion. A gang of senior/executive
VPs is always nice to have on your side.) The PM has to provide
the message and the ammunition. If for some reason the only
voice being heard is your critic's, then you've not plotted, planned,
communicated or prepped your senior representative appropriately.

Now, on to lying. Maybe they're lying, maybe they just didn't understand
the information your team provided and interpreted it badly. They're both
addressable, but can be messy.

[editorial break] If you're managing a project that has any real impact or
benefit, you'll have critics and enemies. It's a given. Plan for it. [end
editorial break]

>
> You are still not considering the fact that this "misalignment" may be
> occurring higher up within the organization. The CEO of a company, or
> the   Senior Vice President, or Vice President, or ..., for example, are
> not expected to attend every meeting during "requirements analysis".
>

See previous response. It's the project manager's job to manage those
communications and get that message out correctly at that level.

> > There was a "What if management changes mid-stream?"
> > objection.
> >
> > Another objection was "what if the requirements
> > are what the customer asked for, but not what
> > the customer wants?"
> >
> > Frankly, if you have not captured what the customer
> > wants, in business terms, then you've done a terrible
> > job of gathering and/or documenting the requirements.
>
> Rudeness objection.
Obliquity objection. What are you talking about?

> That is probably one of the reasons why Change Orders are introduced in
> plan-driven approaches.
>
For the reasons you gave (and I snipped for bandwidth) I'd think Change
Orders
occur in every approach.

>
> So, what would be the reason for Change Orders then? You indicate that
> the business requirements change very little and that you expect to have
> captured 100% of what the customer wants. Why would an organization ever
> need to go through a Change Order? In my experience, the more complex
> the project, the more likely Change Orders will occur in a plan-driven
> approach.
>
In a previous response, I draw a distinction between business requirements
("what" statements) changing much less frequently than design ("how"
statements).

>
> > Finally, the sentiment "...customers seldom know
> > what they really want..." is probably the most
> > disrespectful and condescending notion I've heard
> > come out of a discipline that holds "Open and Honest
> > Communication" as a core value.
>
> IMHO, it's more honest and less condescending than requiring people to
> be infallible.

I'm not requiring infallibility, just reasonable degrees of skill and
professionalism.

>
> > The customer always knows exactly what they want
>
> IMHO, this view is very simplistic. This requires that customers be
> beyond human fallibility. Particularly with increasing complexity. Most
> non-technical people (business domain experts) cannot look at a complex
> design, with complex Use Cases and confidently say that the result will
> address what they actually need with 100% certainty. They may sign off,
> indicating that it *seems* like what they want, and that it is
> definitely in alignment with what they are asking for. But, at the end
> of the project, they will most likely have learned something, and would
> prefer that some changes be made.
>
> I have seen 2 distinct approaches to dealing with this disparity between
> "what the customer asks for" and "what the customer really wants":
> 1) Some believe that /the customers are all idiots/.
> 2) Some believe that the customer doesn't "always knows exactly what
> they want" at the start of a project.
>
> I prefer the second option, although I had trouble preserving the quote
> and working out all of the grammar.
>
> > from a business perspective. If you can't figure it out,
> > your requirements gathering skills need work.
>
> Rudeness objection.
Objection overruled.

"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:AuednQDOL8DIRRbd4p2dnA@comcast.com...
>
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
> news:108m7b8t2icbpab@news.supernews.com...
> >
> > Exactly. One of the things I find isn't emphasized
> > by the XP literature out there is that the standard
> > requirements analysis is split into two distinct
> > activities. The first activity does "just enough"
> > analysis to pull the project together, create
> > the story cards, get them estimated and lay
> > out a tentative release plan.
> >
> > The second activity takes each story card
> > and fleshes it out into the Automated Acceptance
> > Tests. This activity is either the first activity in
> > implementing the story, or takes place on the
> > iteration prior to the planned implementation.
> >
> > > The project manager (and team) review the
> > > requirements for certain attributes. If they
> > > find requirements out of alignment with one another,
> > > then they are re-negotiated, re-worked until
> > > alignment is achieved. There won't be sign-off
> > > until the requirements are clean, and there
> > > certainly won't be a project if they remain
> > > out of alignment.
> >
> > I think the process is somewhat different, but
> > the goal is the same. If different stakeholders'
> > requirements are not in alignment, you can't
> > get "the customer speaks with one voice."
> >
>
> The part that seems to be missing from XP is the
> review of  'the forest' in addition to the review of 'the trees'.
> Mis-alignment is as often the result of conflicts between
> requirements as it is flawed requirements themselves.

You're usually not going to get to the level of detail
that will reveal inconsistencies with XP.

>
> >
> >>
> > > Another objection was "what if the requirements
> > > are what the customer asked for, but not what
> > > the customer wants?"
> >
> > > Frankly, if you have not captured what the customer
> > > wants, in business terms, then you've done a terrible
> > > job of gathering and/or documenting the requirements.
> > > The practioner fell down, not the methodology.
> >
> > Agreed. Unfortunately, this happens a lot.
> >
> > > There are lots of tools and techniques for gathering
> > > and understanding requirements. Learn them, get good
> > > at them, and use them.
> >
> > Many of those tools and techniques come out
> > of the "we have to have all the requirements nailed
> > down up front because changing any detail is going
> > to be horribly expensive" school of thought.
>
> Two quibbles:
> 1. Are you suggesting that you won't use effective tools
> because you don't like a methodology that uses them?

There is a difference between "effective" and "cost
effective." Many of the tools that come out of the
plan driven environment are effective, but they are
not cost effective in an agile environment.

> 2. Changing requirements, or even design details, is cheaper
> on paper than it is in code, and production code at that.
> That's  part of the value of doing those things up front.

Now that's where we're going to disagree. Strongly.
The basic fact is that the longer the time between
the original research and the implementation, the
more likely it is that changes will obsolete the original work.

The devil is in the details, and it's the details that
don't get right unless they're tested in the real world
by real people using the real implementation. The more
work that's put into getting the details right, the more
cost that is at risk of being obsoleted by the mere
passage of time and events over which the requriements
team has no knowledge.

> > > Finally, the sentiment "...customers seldom know
> > > what they really want..." is probably the most
> > > disrespectful and condescending notion I've heard
> > > come out of a discipline that holds "Open and Honest
> > > Communication" as a core value.
> > >
> > > The customer always knows exactly what they want
> > > from a business perspective. If you can't figure it out,
> > > your requirements gathering skills need work.
> >
> > Well, here I'm going to both agree and disagree with
> > you. The customer does know what they want from
> > a business perspective, but that doesn't mean they
> > know exactly what they want the system to do in
> > the detail needed to implement it.
>
> Requirements are 'what' and design is 'how'. Again,
> in classical project management, design gets worked, reviewed
> and agreed to when it's cheap and on paper.

And in XP, design is proved by being reduced to code
immediately. The time lag between design and code is
minimal.

The point of disagreement is expense. Classical development
is expensive because it is very wasteful. XP is significantly
cheaper because it eliminates most of the sources of waste.

> Changes will certainly occur, and the project structure has to
> have a mechanism that reflects the effect that changes will have on
> the project as a whole, and then, for accepting or rejecting them.

Of course.

John Roth
>
>
>

On Sun, 25 Apr 2004 11:23:05 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>The part that seems to be missing from XP is the
>review of  'the forest' in addition to the review of 'the trees'.
>Mis-alignment is as often the result of conflicts between
>requirements as it is flawed requirements themselves.

How does the XP "Release Plan" practice affect this concern, in your
mind?

>Two quibbles:
>1. Are you suggesting that you won't use effective tools
>because you don't like a methodology that uses them?

I would think that the OP was saying that since they do not use a
methodology that requires the tools, they are of less value in such a
case.
>
>2. Changing requirements, or even design details, is cheaper
>on paper than it is in code, and production code at that.
>That's  part of the value of doing those things up front.

Yes. But part of the cost is that the importance and the understanding
of the requirements is at least partly conditioned by things that can
only be learned from the implementation.

Similarly, changing design details without feedback from the code is
quite error-prone beyond a certain high level. We can't select
features without understanding their individual cost, and quite often,
we aren't even sure what we want until we see it coming into being.

Another part of the cost is that waiting longer to ship value reduces
return on investment.

The result of these observations -- I would call them "truths" -- is
that one needs always to find a balance between enough analysis and
design to keep the cost of change low, and enough development to get
the ROI high and to learn the things that can best be learned through
the implementation.

Agile methods in general, and XP in particular, observe that with
today's tools and practices, the balance favors moving to
implementation much sooner than folks normally anticipate it before
experimenting with the power of simple design supported by tests, and
refactoring.

Regards,

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:v0ao80tsp89vekocpjk2eh38nsa4q4p4ib@4ax.com...
> On Sun, 25 Apr 2004 11:23:05 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
> >The part that seems to be missing from XP is the
> >review of  'the forest' in addition to the review of 'the trees'.
> >Mis-alignment is as often the result of conflicts between
> >requirements as it is flawed requirements themselves.
>
> How does the XP "Release Plan" practice affect this concern, in your
> mind?
>

Not at all. It seems much more concerned with scheduling the
work on individual stories. I don't see anything that reviews all
the stories as making sense together. Nothing that I've seen
would prevent you from simply scheduling conflicting work.

> >Two quibbles:
> >1. Are you suggesting that you won't use effective tools
> >because you don't like a methodology that uses them?
>
> I would think that the OP was saying that since they do not use a
> methodology that requires the tools, they are of less value in such a
> case.
> >
So interviews, use cases, prototypes, storyboarding, brainstorming
sessions, review of existing documents, and so on, are of little value
in XP?

> >2. Changing requirements, or even design details, is cheaper
> >on paper than it is in code, and production code at that.
> >That's  part of the value of doing those things up front.
>
> Yes. But part of the cost is that the importance and the understanding
> of the requirements is at least partly conditioned by things that can
> only be learned from the implementation.

But those are a sub-set, and I suspect, not a majority. In XP, when
a customer declares after delivery, "It's not what I wanted", what happens?

Does it create a new story, that will be re-prioritized with all the
existing stories, do you simply work on it until it *is* what they wanted?

>
> Similarly, changing design details without feedback from the code is
> quite error-prone beyond a certain high level.

>We can't select  features without understanding their individual cost, and
quite often,
> we aren't even sure what we want until we see it coming into being.
>


> Another part of the cost is that waiting longer to ship value reduces
> return on investment.
>

Not convinced, and what kind of time horizon are you ascribing to
plan-driven development anyway?

Also, where user training are required, or integration with a larger
application set is required, the products of development *can't* go
into production any sooner than they can for plan driven deliverables,
so there's no incremental benefit.



> The result of these observations -- I would call them "truths" -- is
> that one needs always to find a balance between enough analysis and
> design to keep the cost of change low, and enough development to get
> the ROI high and to learn the things that can best be learned through
> the implementation.
>
> Agile methods in general, and XP in particular, observe that with
> today's tools and practices, the balance favors moving to
> implementation much sooner than folks normally anticipate it before
> experimenting with the power of simple design supported by tests, and
> refactoring.
>
> Regards,
>
> -- 
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.

>> Scott Kinney wrote:
>>> Frankly, if you have not captured what the customer wants, in 
>>> business terms, then you've done a terrible job of gathering 
>>> and/or documenting the requirements.

> Jason Nocks wrote:
>> Rudeness objection.

Scott Kinney wrote:
> Obliquity objection. What are you talking about?

I think it's a reference to:
http://c2.com/cgi/wiki?RudenessObjection

Ironically, the use here more closely resembles the description than
whatever slight it was supposed to highlight:

  "the kind of rudeness that uses one's superior knowledge of Wiki
   concepts and content to imply that a newcomer is barely literate or
   intelligent."

But perhaps not as close as me pointing this out :-).

As for what is so objectionable about what you wrote: your guess is as
good as mine.

On Sun, 25 Apr 2004 19:24:18 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
>news:v0ao80tsp89vekocpjk2eh38nsa4q4p4ib@4ax.com...
>> On Sun, 25 Apr 2004 11:23:05 -0400, "Scott Kinney"
>> <sakinney@ix.netcom.com> wrote:
>>
>> >The part that seems to be missing from XP is the
>> >review of  'the forest' in addition to the review of 'the trees'.
>> >Mis-alignment is as often the result of conflicts between
>> >requirements as it is flawed requirements themselves.
>>
>> How does the XP "Release Plan" practice affect this concern, in your
>> mind?
>>
>
>Not at all. It seems much more concerned with scheduling the
>work on individual stories. I don't see anything that reviews all
>the stories as making sense together. Nothing that I've seen
>would prevent you from simply scheduling conflicting work.

Nothing except people coming together to consider all the stories and
their estimates.

If two stories actually conflict, then the estimate for one would be
infinite given the other. But no matter.

What happens is that all the people are sitting around the table
talking about all the stories at once. Unless they are all really
dull, they wind up considering how it all makes sense.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Sun, 25 Apr 2004 19:24:18 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>> >Two quibbles:
>> >1. Are you suggesting that you won't use effective tools
>> >because you don't like a methodology that uses them?
>>
>> I would think that the OP was saying that since they do not use a
>> methodology that requires the tools, they are of less value in such a
>> case.
>> >
>So interviews, use cases, prototypes, storyboarding, brainstorming
>sessions, review of existing documents, and so on, are of little value
>in XP?

Did I say that? I don't recall doing so. However:

First of all, I would expect that an XP team would use any practices
that they knew if they thought they would be useful. XP isn't "do only
these things", it is "do these things". 

Given that ...

Formal interviews are probably of lower value when we have someone who
understands the needs with us all the time;

Use cases might be of lower value when we have someone who understands
the needs with us all the time, and when we have one or more automated
acceptance tests for every requirement;

Prototypes are of lower value to the extent that we have the ability
to build real, running software cost effectively.

I've seen storyboarding used on many XP projects, at least if the term
means what I think it means. What do you mean by the term?

Brainstorming sessions are common on XP projects, as they would be in
most any sensible team situation.

Naturally if there were existing documents a team would review them.

I would think it clear that doing things in different ways changes the
value of other things that one might do. Does that not seem true to
you as well?

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Scott Kinney wrote:
> Finally, the sentiment "...customers seldom know what they really 
> want..." is probably the most disrespectful and condescending notion 
> I've heard come out of a discipline that holds "Open and Honest 
> Communication" as a core value.

The idea that people seldom know what they really want has been verified
by experiment.

In, The Paradox of Choice, Barry Schwartz describes an experiment where
two groups of college students were asked to choose between a variety of
snacks during the break of three seminars (one a week for three weeks).

The first group were asked to pick their snacks for all three weeks in
advance and tended to pick a variety of snacks. The second group were
allowed to pick each week and tended to pick the same thing each week.

A similar experiment was carried out with shoppers asked to shop for a
day versus several days. The results were the same.

As I mentioned in the thread "The 'peak-end' rule", our memory of
previous experience as faulty as our prediction of future experience.

Schwartz summarises these experiments like this:

  "So it seems that neither our predictions about how we will feel after
   an experience nor our memories of how we did feel during the
   experience are very accurate reflections of how we actually do feel
   while the experience is occurring. And yet it is memories of the past
   and expectations for the future that govern our choices."

And that seems to match the sentiment: "customers seldom know what they
really want" quite well. However, this view is not a product of XP. Most
requirements gathering techniques go to great lengths to address this issue.

On Sat, 24 Apr 2004 13:05:48 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>Finally, the sentiment "...customers seldom know
>what they really want..." is probably the most
>disrespectful and condescending notion I've heard
>come out of a discipline that holds "Open and Honest
>Communication" as a core value.

On the contrary. The customers are being asked to imagine a thing
which does not exist -- a software program. They are being asked to
describe it in quite some detail, and they lack, at the beginning of
this effort, any knowledge of the cost of the individual features.

"Would you like to have a Ferrari?" "Yes!"

"They cost $250,000." "Oh. Never mind."

There's no disrespect or condesension in the observation that
customers seldom know what they really want, merely observation.
That's why we prefer to work closely with them, to give them cost
estimates on all the features they imagine, and to show them the
software as it grows.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Scott Kinney wrote:

> Now, on to lying. Maybe they're lying, maybe they just didn't
> understand the information your team provided and interpreted it
> badly. They're both addressable, but can be messy.

If I remember correctly, Ron reported the responsible manager stating
something along the lines of "I can't possibly say them *that*."

> See previous response. It's the project manager's job to manage those
> communications and get that message out correctly at that level.

Yes. And if the manager refuses to do it, no process, wether including
"sign-off" or not, will help, so it seems to me.

Take care, Ilja

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:tuuo80hnqsor9vkh0452b4c98si93ak5f4@4ax.com...
> On Sun, 25 Apr 2004 19:24:18 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> Formal interviews are probably of lower value when we have someone who
> understands the needs with us all the time;
>
> ......snippage........
> I would think it clear that doing things in different ways changes the
> value of other things that one might do. Does that not seem true to
> you as well?


'Interviewing', to me, is a collection of skills to elicit information;
skills like asking open-ended questions (even knowing which sorts
of attributes to 'unravel'), testing understanding, being able to recreate
key arguments and concerns,building rapport,
mirroring, and many others. I may do this in words, I may use pictures,
I may mimic processes on 3x5 cards, and so on.

What I hear and read in XP literature, if I may paraphrase, is;
"We don't need that level of skill/practice because we have the
people in the room."

Have I misinterpreted, are there other expectations of the XP
practitioner (specific skills and attitudes) that are assumed, or left
undescribed?

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:v0ao80tsp89vekocpjk2eh38nsa4q4p4ib@4ax.com...
> On Sun, 25 Apr 2004 11:23:05 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
> >2. Changing requirements, or even design details, is cheaper
> >on paper than it is in code, and production code at that.
> >That's  part of the value of doing those things up front.
>
> Yes. But part of the cost is that the importance and the understanding
> of the requirements is at least partly conditioned by things that can
> only be learned from the implementation.
>
> Similarly, changing design details without feedback from the code is
> quite error-prone beyond a certain high level. We can't select
> features without understanding their individual cost, and quite often,
> we aren't even sure what we want until we see it coming into being.
>
> Another part of the cost is that waiting longer to ship value reduces
> return on investment.
>
I meant to ask this earlier; when you use the term 'return on investment'
do you mean it literally (an actual model of costs, returns, value over time
return on separate features of the project, etc.) or more figuratively?

"Ilja Preu�" <preuss@disy.net> wrote in message
news:c6itsr$vk8$1@stu1id2.ip.tesion.net...
> Scott Kinney wrote:
>
> > Now, on to lying. Maybe they're lying, maybe they just didn't
> > understand the information your team provided and interpreted it
> > badly. They're both addressable, but can be messy.
>
> If I remember correctly, Ron reported the responsible manager stating
> something along the lines of "I can't possibly say them *that*."
>
> > See previous response. It's the project manager's job to manage those
> > communications and get that message out correctly at that level.
>
> Yes. And if the manager refuses to do it, no process, wether including
> "sign-off" or not, will help, so it seems to me.

Agreed, it's more a matter of the skills, practices, even the aggressiveness
of the project manager, than it is one of process or methodology.

I don't know if there were other lines of communications to senior
management, a back door. I don't know why it wasn't appropriate to
work with the manager to find another way to deliver the critical message.

"Paul Sinnett" <paul.sinnett@btinternet.com> wrote in message
news:408c9592$1@news.totallyobjects.com...
> Scott Kinney wrote:
> > Finally, the sentiment "...customers seldom know what they really
> > want..." is probably the most disrespectful and condescending notion
> > I've heard come out of a discipline that holds "Open and Honest
> > Communication" as a core value.
>
> The idea that people seldom know what they really want has been verified
> by experiment.
>
> ...snippage about 'proving that customers don't know what they want'

> And that seems to match the sentiment: "customers seldom know what they
> really want" quite well. However, this view is not a product of XP. Most
> requirements gathering techniques go to great lengths to address this
issue.

If we are thinking of the same requirements gathering techniques, they do
not
come from a base of 'the customer doesn't know what they want', they come
from
a base of 'the project team doesn't know what the customer wants.'

My objection to the attitude is:

1. I don't believe that it's true. The customer knows their business, they
know
it way better than I do, and they know their business needs better than I do
(at least at the beginning.)
2. The attitude has no payoff in the requirements gathering process, it
gives
me no advantage, and it poisons my ability to build rapport with them.

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:cbpp80503la7h4dcdvkp1keoqcq98qb7jk@4ax.com...
> On Sat, 24 Apr 2004 13:05:48 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
> >Finally, the sentiment "...customers seldom know
> >what they really want..." is probably the most
> >disrespectful and condescending notion I've heard
> >come out of a discipline that holds "Open and Honest
> >Communication" as a core value.
>
> On the contrary. The customers are being asked to imagine a thing
> which does not exist -- a software program. They are being asked to
> describe it in quite some detail, and they lack, at the beginning of
> this effort, any knowledge of the cost of the individual features.
>

Aha! he said...we're still talking about 2 separate things.

The customer is the expert in the business requirements:
the information they need to have, decisions that need to be
made, actions that need to be taken under what circumstances,
when they need to take place, who else needs them, and so on.
They absolutely know these things and I (as a project manager)
need to learn them.

Once I've got a fair grip on those business requirements, I may
turn to the technical experts and ask for designs that satisfy
those requirements.

With a fair grip on that, I bring the business customer back in
and walk through the design, showing why or how I think the design
meets their business needs. They get to disagree, add detail, and so on.

In other words, I let the business people be expert on the business
questions, and the technical people be expert in the technical questions.

Business requirements and system design are separate endeavors. Heck,
I even hold back from assuming that a systems change is needed until
it's shown that simpler process changes can satisfy the requirements.

Paul Sinnett wrote:

> And that seems to match the sentiment: "customers seldom know what they
> really want" quite well. However, this view is not a product of XP. Most
> requirements gathering techniques go to great lengths to address this 
> issue.

Exactly. I just was noting my preference for a much shorter, to the 
point approach.

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Scott Kinney wrote:

> "Jason Nocks" <nocksj@sourcextreme.com> wrote in > > requirements
> misalignment, but the activity
> 
>>If you wish to perform "requirements analysis", that's fine, but IMHO it
>>does not address all of the "what if"s that were mentioned, particularly
>>when a manager is lying to higher levels of management (who do not have
>>the time to be involved in "requirements analysis").
> 
> Let's leave the word 'lying' aside for the moment.

Let's not. It wasn't my word. It was Ron's. I wasn't on the C3 project 
and it doesn't sound like you were either.

>>>There was a "What if management changes mid-stream?"
>>>objection.
>>>
>>>Another objection was "what if the requirements
>>>are what the customer asked for, but not what
>>>the customer wants?"
>>>
>>>Frankly, if you have not captured what the customer
>>>wants, in business terms, then you've done a terrible
>>>job of gathering and/or documenting the requirements.
>>
>>Rudeness objection.
> 
> Obliquity objection. What are you talking about?

I was stating that your statement seemed a bit offensive, rude, and 
uncalled for to me. What don't you understand about that? You don't have 
to agree with it. It's just my opinion.

>>That is probably one of the reasons why Change Orders are introduced in
>>plan-driven approaches.
> 
> For the reasons you gave (and I snipped for bandwidth) I'd think Change
> Orders
> occur in every approach.

Right, except XP makes change a more integral part of the process rather 
than treating it as an exception. Since as you stated, changes "occur in 
every approach".

So, if you admit that Change Orders are occuring, then what is the 
reason for those changes? I see three: customers gaining a better 
understanding of what they desire or need, programmers gaining a better 
understanding of what is really desired or needed, and business changes. 
The first two are basically the same thing, the shared knowledge of the 
team at the start of the project did not completely represent in detail 
what was actually needed or desired. That was my main point.

If these changes happen on every project, then how can you claim that 
the result of "requirements analysis" is 100% of what the customer 
acutally needs or wants. If so, then you would never need a change 
order. The fact that you almost always need a change order means that 
"requirements analysis" does not result in capturing 100% of what the 
customer actually needs or wants. Again, this was my point.

>>Rudeness objection.
> 
> Objection overruled.

Not even remotely humorous. You might try to actually understand someone 
else's reasons for taking offense. Perhaps your perspective is not the 
only valid one here.

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Scott Kinney wrote:

> Two quibbles:
> 1. Are you suggesting that you won't use effective tools
> because you don't like a methodology that uses them?

What tools are you referring to? I would probably not object to tools 
when they make a job simpler and easier. I think the main objection is 
when the tools are nearly *required* by a process that has been put in 
place.

> 2. Changing requirements, or even design details, is cheaper
> on paper than it is in code, and production code at that.
> That's  part of the value of doing those things up front.

Well, literally that may be true, except for one small detail. If you 
change it on the paper itself, then you have to change it again in the 
electronic copy, assuming that you do actually use electronic documents.

Now, if you mean changing a design document is cheaper than changing 
code, I would ask you what evidence you have to this statement?

Why should changing text in one location (design document) be cheaper 
than changing text in another (source code)?

In fact, the opposite seems to be true. Changing the design document 
*also* requires changing the source code.

This may be one of the reasons why design documents become out-of-date 
as the schedule gets tighter and tighter in many instances of 
plan-driven projects. This is just my personal observation.

I think that what you are talking about is making *correct* changes. If 
I have automated tests, then it is easier for me to make *correct* 
changes without breaking other code.

>>>Finally, the sentiment "...customers seldom know
>>>what they really want..." is probably the most
>>>disrespectful and condescending notion I've heard
>>>come out of a discipline that holds "Open and Honest
>>>Communication" as a core value.
>>>
>>>The customer always knows exactly what they want
>>>from a business perspective. If you can't figure it out,
>>>your requirements gathering skills need work.
>>
>>Well, here I'm going to both agree and disagree with
>>you. The customer does know what they want from
>>a business perspective, but that doesn't mean they
>>know exactly what they want the system to do in
>>the detail needed to implement it.

> Requirements are 'what' and design is 'how'. Again,
> in classical project management, design gets worked, reviewed
> and agreed to when it's cheap and on paper.

First, why would a non-technical person want to review a technical 
design document?

Second, document changes are significantly cheaper than implementation 
changes when you are talking about hardware. What evidence do you have 
to support this claim when discussing software?

As for storing requirements in one central location that the customer 
can review to make sure the requirements are captured in detail as 
desired, acceptance tests are probably a much better place than a design 
document.

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:ce76a$408d17ef$cff54506$2574@dcanet.allthenewsgroups.com...
> Scott Kinney wrote:
>
> > "Jason Nocks" <nocksj@sourcextreme.com> wrote in > > requirements
> > misalignment, but the activity
> >
> >>If you wish to perform "requirements analysis", that's fine, but IMHO it
> >>does not address all of the "what if"s that were mentioned, particularly
> >>when a manager is lying to higher levels of management (who do not have
> >>the time to be involved in "requirements analysis").
> >
> > Let's leave the word 'lying' aside for the moment.
>
> Let's not. It wasn't my word. It was Ron's. I wasn't on the C3 project
> and it doesn't sound like you were either.
>
That's my point. To call something lying is requires knowledge neither
you nor I possess. Also, calling it lying is irrelevant to the
communications
planning/skills or approach required to address it.

>
> >>That is probably one of the reasons why Change Orders are introduced in
> >>plan-driven approaches.
> >
> > For the reasons you gave (and I snipped for bandwidth) I'd think Change
> > Orders
> > occur in every approach.
>
> Right, except XP makes change a more integral part of the process rather
> than treating it as an exception. Since as you stated, changes "occur in
> every approach".
>
> So, if you admit that Change Orders are occuring, then what is the
> reason for those changes? I see three: customers gaining a better
> understanding of what they desire or need, programmers gaining a better
> understanding of what is really desired or needed, and business changes.
> The first two are basically the same thing, the shared knowledge of the
> team at the start of the project did not completely represent in detail
> what was actually needed or desired. That was my main point.
>

This is a good breakdown, but I disagree that your first two points are
'basically the same'. Yes, they both derive from 'learning more', but
learning more about 'business needs' is different from learning more about
'technical approach'.

Before getting deeper into your rant about "100% completeness" let me
explain the process of project initiation.

To get approval, money, resources etc for a project I, as a project manager
need to make this sort of case:

Here is the business goal my customer wishes to achieve:
Here is a description of what (requirements) my customer needs to
do/have/be to achieve those goals.
Here is a description of how (design) we will support these goals.
Here is a description of our approach for delivering the system/process...
Here is an estimate of the time, people, money, other resources needed.
Skipping for the moment statement of Risk Assessment, Risk Management
Here is our approach for managing changes to scope, requirements, design,
delivery, resources, schedule or budget,

Assuming the TPB think that's a good deal we go forward.

Change management process is an
integral part of a plan-driven process. Changes will occur,
for all the reasons you describe and others not forseen. They
*are* exceptions, and they must be evaluated for their effect
on the scope, requirements, delivery, schedule etc.

Not every change needs to be accepted, not every change
is worth its other effects on the project.

My work on requirements gathering, requirements analysis, design
and estimates *up front* has to be good enough to secure project
funding and resources. If I don't do these things, then I'm not helping
my customer. Going in with a half-assed set of requirements and estimates
just because it's faster won't help my customer if it gets me turned down
or sent back to the drawing board.

Now, I've explained my process. If you would, please explain how
change management is done in XP?

Scott Kinney wrote:

> What I hear and read in XP literature, if I may paraphrase, is;
> "We don't need that level of skill/practice because we have the
> people in the room."

Where do you see that?

My expectation of other developers on an XP project goes up a few 
notches. I expect everyone to be more disciplined, to have higher 
standards of quality, etc.

> Have I misinterpreted, are there other expectations of the XP
> practitioner (specific skills and attitudes) that are assumed, or left
> undescribed?

Have you read the Agile Manifesto?

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:3bc9b$408d1e23$cff54506$2726@dcanet.allthenewsgroups.com...
> Scott Kinney wrote:
>
>
> > 2. Changing requirements, or even design details, is cheaper
> > on paper than it is in code, and production code at that.
> > That's  part of the value of doing those things up front.
>
> Well, literally that may be true, except for one small detail. If you
> change it on the paper itself, then you have to change it again in the
> electronic copy, assuming that you do actually use electronic documents.
>
> Now, if you mean changing a design document is cheaper than changing
> code, I would ask you what evidence you have to this statement?
>
> Why should changing text in one location (design document) be cheaper
> than changing text in another (source code)?

"Code" as it seems to be consistently used in this and other threads on
the newsgroup means ; tested, working, delivered code.

To my simple mind, that implies efforts to change design, change source
code, test, correct and port to production. Unless labor is free, changing
code costs more than changing design.

>
> In fact, the opposite seems to be true. Changing the design document
> *also* requires changing the source code

Why does changing the design automatically trigger coding those changes?
>

> > Requirements are 'what' and design is 'how'. Again,
> > in classical project management, design gets worked, reviewed
> > and agreed to when it's cheap and on paper.
>
> First, why would a non-technical person want to review a technical
> design document?

We have to demonstrate to the customer that what we've designed
actually meets their requirements. A design walkthrough that
demonstrates that the 'Acceptance Test' will be met does this
pretty well, and certainly helps us distinguish between design problems
and translation problems when the design is coded.

>
> Second, document changes are significantly cheaper than implementation
> changes when you are talking about hardware. What evidence do you have
> to support this claim when discussing software?
>
The fact that programming effort costs money. Do I need more evidence?
Is labor free?

Scott Kinney wrote:

> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:ce76a$408d17ef$cff54506$2574@dcanet.allthenewsgroups.com...
> 
>>Scott Kinney wrote:
>>
>>>"Jason Nocks" <nocksj@sourcextreme.com> wrote in > > requirements
>>>misalignment, but the activity
>>>
>>>>If you wish to perform "requirements analysis", that's fine, but IMHO it
>>>>does not address all of the "what if"s that were mentioned, particularly
>>>>when a manager is lying to higher levels of management (who do not have
>>>>the time to be involved in "requirements analysis").
>>>
>>>Let's leave the word 'lying' aside for the moment.
>>
>>Let's not. It wasn't my word. It was Ron's. I wasn't on the C3 project
>>and it doesn't sound like you were either.
> 
> That's my point. To call something lying is requires knowledge neither
> you nor I possess. Also, calling it lying is irrelevant to the
> communications
> planning/skills or approach required to address it.

No, your point seems to be to try to call it something else. I want to 
use the word that was used by the person who *was* there.

>>Right, except XP makes change a more integral part of the process rather
>>than treating it as an exception. Since as you stated, changes "occur in
>>every approach".
>>
>>So, if you admit that Change Orders are occuring, then what is the
>>reason for those changes? I see three: customers gaining a better
>>understanding of what they desire or need, programmers gaining a better
>>understanding of what is really desired or needed, and business changes.
>>The first two are basically the same thing, the shared knowledge of the
>>team at the start of the project did not completely represent in detail
>>what was actually needed or desired. That was my main point.
> 
> This is a good breakdown, but I disagree that your first two points are
> 'basically the same'. Yes, they both derive from 'learning more', but
> learning more about 'business needs' is different from learning more about
> 'technical approach'.

I'm only currently discussing changes in the context of 
requirements/User Stories. I am not in the habit of discussing technical 
design details with non-technical customers.

> Before getting deeper into your rant about "100% completeness" let me
> explain the process of project initiation.

<snip>
Thanks for your list of steps in "project initiation". It sounds very 
much like what I recollect from having done quite a number of 
plan-driven projects in the past.

> Change management process is an
> integral part of a plan-driven process. Changes will occur,
> for all the reasons you describe and others not forseen. They
> *are* exceptions, and they must be evaluated for their effect
> on the scope, requirements, delivery, schedule etc.

They are only exceptions if you treat them that way. I don't (I used to 
when I used a plan-driven approach). Again, you don't have to agree 
here. We *do* define things differently, because we are taking different 
approaches.

> Not every change needs to be accepted, not every change
> is worth its other effects on the project.

The change is only accepted if the customer indicates that a new User 
Story is a higher priority than other stories for a particular 
iteration. Who else would be indicating acceptance of these changes?

> My work on requirements gathering, requirements analysis, design
> and estimates *up front* has to be good enough to secure project
> funding and resources. If I don't do these things, then I'm not helping
> my customer. Going in with a half-assed set of requirements and estimates
> just because it's faster won't help my customer if it gets me turned down
> or sent back to the drawing board.

Again, rudeness objection. Please refrain from off-putting language. 
Thank you. If you still can't understand, let me make it clear. 
"Half-assed" is quite rude language. The general concept you are trying 
to convey is also very down-putting and could easily be interpreted as 
offensive.

Nobody is trying to do a less than adequate job just to deliver the end 
results faster. That is called Cowboy Coding. That is not what XP is.

You do not have to understand an approach that is different from yours. 
But, I'll kindly ask you not to use offensive remarks if you don't agree 
with an XP approach in a forum intended for those interested in XP.

I try not to spend a lot of time discussing the offensiveness of these 
types of remarks, and simply respond "rudeness objection". I sincerely 
hope that my reasoning for doing this is now abundantly clear.

> Now, I've explained my process. If you would, please explain how
> change management is done in XP?

If you read Kent Beck's "XP Explained", the sub-title is called "Embrace 
Change". We really do treat change as an expected occurance, rather than 
as an exception. So there is not a specific "Change Management" process.

Basically, user requirements are represented as User Stories. New 
requirements are new User Stories. Every new User Story is a change from 
what is already implemented. New User Stories are allowed prior to the 
start of any iteration. There's nothing all that special about it.

Did you have some questions? Is there something that's not clear here?

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<cbpp80503la7h4dcdvkp1keoqcq98qb7jk@4ax.com>...

> On the contrary. The customers are being asked to imagine a thing
> which does not exist -- a software program. They are being asked to
> describe it in quite some detail, and they lack, at the beginning of
> this effort, any knowledge of the cost of the individual features.

Why are we asking customers to imagine what a software product could
be like? Shouldn't we be asking: What are the business goals? What are
the business tasks that need to be completed?

Task Descriptions as Functional Requirements
http://www.itu.dk/people/slauesen/Papers/IEEEtasks.pdf


> "Would you like to have a Ferrari?" "Yes!" 
> "They cost $250,000." "Oh. Never mind."
> 
> There's no disrespect or condesension in the observation that
> customers seldom know what they really want, merely observation.

We're offered a gift, and then it turns out that it's not a gift. 

Does that show that we don't know what we really want, or merely that
we're capable of distinguishing between two quite different things:
the gift of a Ferrari versus purchasing a Ferrari.


> That's why we prefer to work closely with them, to give them cost
> estimates on all the features they imagine, and to show them the
> software as it grows.

Scott Kinney wrote:

> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:3bc9b$408d1e23$cff54506$2726@dcanet.allthenewsgroups.com...
> 
>>Scott Kinney wrote:
>>
>>>2. Changing requirements, or even design details, is cheaper
>>>on paper than it is in code, and production code at that.
>>>That's  part of the value of doing those things up front.
>>
<snip>
>>Why should changing text in one location (design document) be cheaper
>>than changing text in another (source code)?
> 
> "Code" as it seems to be consistently used in this and other threads on
> the newsgroup means ; tested, working, delivered code.

> To my simple mind, that implies efforts to change design, change source
> code, test, correct and port to production. Unless labor is free, changing
> code costs more than changing design.

So, changes to a design document don't involve thinking about the design?

As I said in my post, if I'm going to change something *in addition to* 
the code, the first thing I'm going to change is going to be tests, not 
design documents.

In fact, if I am compelled to produce design documentation, I would 
generally use something like doxygen. That way, the design documentation 
is more likely to stay in sync.

You have still failed to indicate how changes to a design document are 
cheaper than changes to code, as I've stated that both are simply text.

>>In fact, the opposite seems to be true. Changing the design document
>>*also* requires changing the source code
> 
> Why does changing the design automatically trigger coding those changes?

If I'm not going to change the code, then why would I bother with those 
changes to the design? My customers don't generally pay for a design 
document. They are paying for a working product. Design is part of the 
process that /I/ use to try to get there in the most effective way I can.

Now, if you are talking about the order, and timing, etc. Sure, I'm not 
going to make a series of changes to the Acceptance Tests, the Unit 
Tests, and the code all at the same time. I'm going to change the 
Acceptance Tests first.

If you don't have Acceptance Tests, Unit Tests, etc. then maybe you 
would be concerned that changing the code would potentially break 
existing code. I would certainly agree with that.

>>>Requirements are 'what' and design is 'how'. Again,
>>>in classical project management, design gets worked, reviewed
>>>and agreed to when it's cheap and on paper.
>>
>>First, why would a non-technical person want to review a technical
>>design document?
> 
> We have to demonstrate to the customer that what we've designed
> actually meets their requirements. A design walkthrough that
> demonstrates that the 'Acceptance Test' will be met does this
> pretty well, and certainly helps us distinguish between design problems
> and translation problems when the design is coded.

I would agree that Acceptance Tests indicate whether or not we are 
meeting the customers requirements.

However, the technical design documentation does not seem to help a 
non-technical customer in this regard at all. The technical design 
documentation is purely for the technical members of a team. Am I 
missing something?

>>Second, document changes are significantly cheaper than implementation
>>changes when you are talking about hardware. What evidence do you have
>>to support this claim when discussing software?
> 
> The fact that programming effort costs money. Do I need more evidence?
> Is labor free?

Are the technical design documents not written by programmers? Is their 
time all of a sudden free when they are writing documentation instead of 
code? Is there some reason that their cost would go down because they 
are writing different types of text (text about the code rather than the 
code itself)?

Yes, you do need more evidence to support your claim.

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Paul Sinnett <paul.sinnett@btinternet.com> wrote in message news:<408c9592$1@news.totallyobjects.com>...

> Scott Kinney wrote:
> > Finally, the sentiment "...customers seldom know what they really 
> > want..." is probably the most disrespectful and condescending notion 
> > I've heard come out of a discipline that holds "Open and Honest 
> > Communication" as a core value.
> 
> The idea that people seldom know what they really want has been verified
> by experiment.
> 
> In, The Paradox of Choice, Barry Schwartz describes an experiment where
> two groups of college students were asked to choose between a variety of
> snacks during the break of three seminars (one a week for three weeks).

This is about "preferences".
What the students really want is not to be hungry.

"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:f0656$408d315e$cff54506$3193@dcanet.allthenewsgroups.com...
> Scott Kinney wrote:
>
> > "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> > news:3bc9b$408d1e23$cff54506$2726@dcanet.allthenewsgroups.com...
> >
> >>Scott Kinney wrote:
> >>
> >>>2. Changing requirements, or even design details, is cheaper
> >>>on paper than it is in code, and production code at that.
> >>>That's  part of the value of doing those things up front.
> >>
> <snip>
> >>Why should changing text in one location (design document) be cheaper
> >>than changing text in another (source code)?
> >
> > "Code" as it seems to be consistently used in this and other threads on
> > the newsgroup means ; tested, working, delivered code.
>
> > To my simple mind, that implies efforts to change design, change source
> > code, test, correct and port to production. Unless labor is free,
changing
> > code costs more than changing design.
>
> So, changes to a design document don't involve thinking about the design?
>
> You have still failed to indicate how changes to a design document are
> cheaper than changes to code, as I've stated that both are simply text.
>
> >>Second, document changes are significantly cheaper than implementation
> >>changes when you are talking about hardware. What evidence do you have
> >>to support this claim when discussing software?
> >
> > The fact that programming effort costs money. Do I need more evidence?
> > Is labor free?
>
> Are the technical design documents not written by programmers? Is their
> time all of a sudden free when they are writing documentation instead of
> code? Is there some reason that their cost would go down because they
> are writing different types of text (text about the code rather than the
> code itself)?
>
> Yes, you do need more evidence to support your claim.

Only because you have not responded to my question.

So, I'll repeat in a different way....

*****Change to Design Only*****
expense: time spent thinking about design change
expense: time spent changing the design document
perhaps
expense: time spent testing design

*****Change to Code******
expense: time spent thinking about design change
expense: time spent changing the design document
expense: time spent testing design
expense: time spent translating design to source code
expense: time spent going from source code to executable code
expense: time spent testing
expense: time spent porting to production


Which of these entails more expense?

Isaac Gouy wrote:

> Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<cbpp80503la7h4dcdvkp1keoqcq98qb7jk@4ax.com>...
> 
>>On the contrary. The customers are being asked to imagine a thing
>>which does not exist -- a software program. They are being asked to
>>describe it in quite some detail, and they lack, at the beginning of
>>this effort, any knowledge of the cost of the individual features.
> 
> Why are we asking customers to imagine what a software product could
> be like? Shouldn't we be asking: What are the business goals? What are
> the business tasks that need to be completed?

My understanding was that we were talking about the *details* of the 
requirements. Not just the User Story level, but what would be 
incorporated into automated Acceptance Tests.

So, yes, we would be asking based on a given input what would be the 
desired output. Much less ambiguous than requiring the customer to 
imagine what they might get. The recommendation is to follow that up 
with actual working, tested software in a short iteration and a short 
release so the customer can acutally see what they are getting *instead 
of* imagining.

> Task Descriptions as Functional Requirements
> http://www.itu.dk/people/slauesen/Papers/IEEEtasks.pdf
> 
>>"Would you like to have a Ferrari?" "Yes!" 
>>"They cost $250,000." "Oh. Never mind."
>>
>>There's no disrespect or condesension in the observation that
>>customers seldom know what they really want, merely observation.
> 
> We're offered a gift, and then it turns out that it's not a gift. 

No, the customer wants a pony. See http://c2.com/cgi/wiki?IwantaPony

Customer: I want everything, and I want it now, no make that yesterday, 
and I want it for free.

> Does that show that we don't know what we really want, or merely that
> we're capable of distinguishing between two quite different things:
> the gift of a Ferrari versus purchasing a Ferrari.

No, it shows that they really need and can afford things (Ford) that are 
not what they *think* that they want (Ferrari).

The issue is that there is some software engine that excels in areas 
desired (Ferrari performance), but does have the cost of the most 
expensive software engine (the entire Ferrari). To carry the analogy 
even further, the customer does not wish to buy a car based on concept 
diagrams and models displayed at trade shows. They'd much prefer a test 
drive.

>>That's why we prefer to work closely with them, to give them cost
>>estimates on all the features they imagine, and to show them the
>>software as it grows.

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Scott Kinney wrote:

> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:f0656$408d315e$cff54506$3193@dcanet.allthenewsgroups.com...
> 
>>Scott Kinney wrote:
>>
>>
>>>"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
>>>news:3bc9b$408d1e23$cff54506$2726@dcanet.allthenewsgroups.com...
>>>
>>>
>>>>Scott Kinney wrote:
>>>>
>>>>
>>>>>2. Changing requirements, or even design details, is cheaper
>>>>>on paper than it is in code, and production code at that.
>>>>>That's  part of the value of doing those things up front.
>>>>
>><snip>
>>
>>>>Why should changing text in one location (design document) be cheaper
>>>>than changing text in another (source code)?
>>>
>>>"Code" as it seems to be consistently used in this and other threads on
>>>the newsgroup means ; tested, working, delivered code.
>>
>>>To my simple mind, that implies efforts to change design, change source
>>>code, test, correct and port to production. Unless labor is free,
> 
> changing
> 
>>>code costs more than changing design.
>>
>>So, changes to a design document don't involve thinking about the design?
>>
>>You have still failed to indicate how changes to a design document are
>>cheaper than changes to code, as I've stated that both are simply text.
>>
>>
>>>>Second, document changes are significantly cheaper than implementation
>>>>changes when you are talking about hardware. What evidence do you have
>>>>to support this claim when discussing software?
>>>
>>>The fact that programming effort costs money. Do I need more evidence?
>>>Is labor free?
>>
>>Are the technical design documents not written by programmers? Is their
>>time all of a sudden free when they are writing documentation instead of
>>code? Is there some reason that their cost would go down because they
>>are writing different types of text (text about the code rather than the
>>code itself)?
>>
>>Yes, you do need more evidence to support your claim.
> 
> Only because you have not responded to my question.

I apologize. Which question was that?

> So, I'll repeat in a different way....
> 
> *****Change to Design Only*****
> expense: time spent thinking about design change
> expense: time spent changing the design document
> perhaps
> expense: time spent testing design
> 
> *****Change to Code******
> expense: time spent thinking about design change
> expense: time spent changing the design document
> expense: time spent testing design
> expense: time spent translating design to source code
> expense: time spent going from source code to executable code
> expense: time spent testing
> expense: time spent porting to production
> 
> Which of these entails more expense?

This is not the question that I was asking. I had asked, "Why should 
changing text in one location (design document) be cheaper than changing 
text in another (source code)?"

You have included many other activities. I'm not clear what criteria you 
are using to get to your definitions. I certainly don't agree with your 
definitions at all.

Based on your definitions, then yes you have redefined what "change to 
code" means to include enough expenses to be clearly more expensive.

Is there some reference you can cite where all of these steps are 
defined as the simplest way to make a "Change to Code"? Also, I am 
curious why "Change to Design Only" does not also then include time 
spent changing the Test Plan, time spent changing the Gantt Charts, time 
spent adjusting the schedule, etc. Are these not also impacted?

You're definition of "change to code" is curiously lacking the actual 
step of changing the source code. You have redefined "change to code" to 
mean changing design documentation, plus some included model of the 
system, generating the code, etc. Perhaps the tools and process you are 
describing is not the most efficient approach. This is what I am 
acutally asking you to consider.

So, when I asked "Why should changing text in one location (design 
document) be cheaper than changing text in another (source code)", I am 
not asking "Why should changing text in one location (design document) 
be cheaper than changing text in many locations (design document plus 
source code, plus ...)"? I can see why you might be puzzled based on 
your definition of "Change to Code". Again, I'm not sure why you feel 
that your definition of "Change to Code" is obvious. It is certainly not 
the definition I would have chosen.

The closest I can come to your definition of "Change to Code" is to add 
a User Story, then add or change an Acceptance Test, then add or change 
a Unit/Programmer Test, then actually change the source code. However, I 
will freely admit that this is not cheaper than just changing the source 
code (nor am I proposing that one *just change the source code*). I do 
all of these steps because the Unit/Programmer Tests seem to provide 
more value than simply just changing the source code itself.

I would never state, however, that the steps I am listing are cheaper 
than just changing the source code. This seemed to be what you were 
stating (changing design documentation is cheaper than changing source 
code). I've heard this before, and am more and more puzzled as to why 
someone would believe this. I did not realize that changing source code 
meant something other than changing source code, or have I missed something?

Have we cleared this up?

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

"Jason Nocks" <nocksj@sourcextreme.com> wrote in message
news:de9ba$408d436c$cff54506$3740@dcanet.allthenewsgroups.com...
>> Have we cleared this up?

Yes, I've become convinced that you are constitutionally
incapable of answering the question.

On Mon, 26 Apr 2004 08:52:24 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>'Interviewing', to me, is a collection of skills to elicit information;
>skills like asking open-ended questions (even knowing which sorts
>of attributes to 'unravel'), testing understanding, being able to recreate
>key arguments and concerns,building rapport,
>mirroring, and many others. I may do this in words, I may use pictures,
>I may mimic processes on 3x5 cards, and so on.

Yes ...
>
>What I hear and read in XP literature, if I may paraphrase, is;
>"We don't need that level of skill/practice because we have the
>people in the room."

Please tell us just what you have read that says such a thing. It's
just not the case.
>
>Have I misinterpreted, are there other expectations of the XP
>practitioner (specific skills and attitudes) that are assumed, or left
>undescribed?

XP is described by a dozen practices which, if done, ensure that the
team has enough information to keep the project on track. It is
expected that the team will use all its skills, not just those dozen,
every day, as appropriate.

No one has ever said "do just these dozen".

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Mon, 26 Apr 2004 08:55:07 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
>news:v0ao80tsp89vekocpjk2eh38nsa4q4p4ib@4ax.com...
>> On Sun, 25 Apr 2004 11:23:05 -0400, "Scott Kinney"
>> <sakinney@ix.netcom.com> wrote:
>> >2. Changing requirements, or even design details, is cheaper
>> >on paper than it is in code, and production code at that.
>> >That's  part of the value of doing those things up front.
>>
>> Yes. But part of the cost is that the importance and the understanding
>> of the requirements is at least partly conditioned by things that can
>> only be learned from the implementation.
>>
>> Similarly, changing design details without feedback from the code is
>> quite error-prone beyond a certain high level. We can't select
>> features without understanding their individual cost, and quite often,
>> we aren't even sure what we want until we see it coming into being.
>>
>> Another part of the cost is that waiting longer to ship value reduces
>> return on investment.
>>
>I meant to ask this earlier; when you use the term 'return on investment'
>do you mean it literally (an actual model of costs, returns, value over time
>return on separate features of the project, etc.) or more figuratively?

I mean it both literally and figuratively.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Mon, 26 Apr 2004 11:07:22 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>> Why should changing text in one location (design document) be cheaper
>> than changing text in another (source code)?
>
>"Code" as it seems to be consistently used in this and other threads on
>the newsgroup means ; tested, working, delivered code.
>
>To my simple mind, that implies efforts to change design, change source
>code, test, correct and port to production. Unless labor is free, changing
>code costs more than changing design.

What good is a change to the design if you don't change the code?

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Mon, 26 Apr 2004 11:07:22 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>> Second, document changes are significantly cheaper than implementation
>> changes when you are talking about hardware. What evidence do you have
>> to support this claim when discussing software?
>>
>The fact that programming effort costs money. Do I need more evidence?
>Is labor free?

Surely producing a document plus code costs more than producing just
code.

Surely producing only code produces a program, and producing only a
document does not.

Therefore a balance between when one documents (as late as possible)
and when one programs (as early as possible) often makes sense. It
depends on the relative cost of coding and documenting (where
documenting may be less costly), on the relative value of the two
(where coding is surely more valuable in the end), and on the
observation that even if we document, we cannot avoid the cost of
writing the code, but that we can sometimes avoid the cost of writing
the document.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Mon, 26 Apr 2004 12:12:39 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>Only because you have not responded to my question.
>
>So, I'll repeat in a different way....
>
>*****Change to Design Only*****
>expense: time spent thinking about design change
>expense: time spent changing the design document
>perhaps
>expense: time spent testing design
>
>*****Change to Code******
>expense: time spent thinking about design change
>expense: time spent changing the design document
>expense: time spent testing design
>expense: time spent translating design to source code
>expense: time spent going from source code to executable code
>expense: time spent testing
>expense: time spent porting to production
>
>
>Which of these entails more expense?

Which one produces a program?

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Mon, 26 Apr 2004 09:22:17 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>> On the contrary. The customers are being asked to imagine a thing
>> which does not exist -- a software program. They are being asked to
>> describe it in quite some detail, and they lack, at the beginning of
>> this effort, any knowledge of the cost of the individual features.
>>
>
>Aha! he said...we're still talking about 2 separate things.
>
>The customer is the expert in the business requirements:
>the information they need to have, decisions that need to be
>made, actions that need to be taken under what circumstances,
>when they need to take place, who else needs them, and so on.
>They absolutely know these things and I (as a project manager)
>need to learn them.
>
>Once I've got a fair grip on those business requirements, I may
>turn to the technical experts and ask for designs that satisfy
>those requirements.
>
>With a fair grip on that, I bring the business customer back in
>and walk through the design, showing why or how I think the design
>meets their business needs. They get to disagree, add detail, and so on.
>
>In other words, I let the business people be expert on the business
>questions, and the technical people be expert in the technical questions.
>
>Business requirements and system design are separate endeavors. Heck,
>I even hold back from assuming that a systems change is needed until
>it's shown that simpler process changes can satisfy the requirements.

The //Customer// in Extreme Programming is a //role// whose
responsibilities include knowing what is needed and breaking that down
into feature requests (stories), each of which can be implemented and
tested inside one iteration.

This //role// is often staffed with real end users, with inhouse
experts such as marketing people, with business analysts, and with
domain-experienced testers.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Paul:

> The idea that people seldom know what they really want has been verified
> by experiment.

I tend to doubt that philosophical questions can be verified by 
experiment. A tip-off that the question you are describing is a 
philosphical one is the appearance of the word "really".

I'm certain that many experiments have been done, and more are being 
done, on how well people's expectations of their own behaviours match 
the reality of these behaviours.

But think back to the sub-thread which concluded with Isaac and me 
agreeing that "there's no point in being precise if we don't know what 
we are talking about". The question "do customers know what they really 
want" is one of these questions where we don't know what we are talking 
about.

A while ago, I posted some thoughts toward getting clear on what we are 
talking about:
  http://bossavit.com/thoughts/archives/000687.html

Laurent
http://bossavit.com/thoughts/

Scott:

> In other words, I let the business people be expert on the business
> questions, and the technical people be expert in the technical questions.

Excellent advice.

Laurent
http://bossavit.com/thoughts/

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:d7uq80hvlahpifkg08am41pgfl7dmsgquf@4ax.com...
> >> Another part of the cost is that waiting longer to ship value reduces
> >> return on investment.
> >>
> >I meant to ask this earlier; when you use the term 'return on investment'
> >do you mean it literally (an actual model of costs, returns, value over
time
> >return on separate features of the project, etc.) or more figuratively?
>
> I mean it both literally and figuratively.

Please tell me how you model this as a literal calculation; factors,
assumptions,
time horizons, costs, etc.

I set up two projects, 12 features to deliver, equal amounts of
effort to deliver, and delivering 1 per month doesn't seem to provide
(numerically anyway) a greater return on investment than delivering
3 per quarter, say, or 6 every 6 months.

What goes into your calculation?

Isaac:

> Why are we asking customers to imagine what a software product could
> be like? Shouldn't we be asking: What are the business goals? What are
> the business tasks that need to be completed?

Those are two *very* different questions - I'm concerned that asking 
them in close succession, you might be suggesting that they are two 
sides of one coin. Tasks support goals - there's a logical order there.

As to the "why" question, the problem is that while goals can often be 
articulated in vague, general terms at the outset of a project, to reach 
a goal requires restating it in precise (that word again) terms. A goal 
must also be positive, achievable, observable, and somewhat flexible.

Very often, you can only meet these standards after doing one or more of 
the following (and that's a partial list):
- breaking the goal down into sub-goals
- seeing a partial solution in action
- discovering unwanted side-effects of attaining the goal
- discarding the original goal for a revised version

Goal-setting often proceeds in parallel with solution-exploring. This is 
why part of specifying what we want from a software product involves 
imagining what the product will be like.

Laurent
http://bossavit.com/thoughts/

Jason Nocks <nocksj@sourcextreme.com> wrote in message news:<cb067$408d3bc7$cff54506$3521@dcanet.allthenewsgroups.com>...
 
> > Why are we asking customers to imagine what a software product could
> > be like? Shouldn't we be asking: What are the business goals? What are
> > the business tasks that need to be completed?
> 
> My understanding was that we were talking about the *details* of the 
> requirements. 

The OP was talking about business goals and tasks: "The customer
always knows exactly what they want from a business perspective."


> >>"Would you like to have a Ferrari?" "Yes!" 
> >>"They cost $250,000." "Oh. Never mind."
> >>
> >>There's no disrespect or condesension in the observation that
> >>customers seldom know what they really want, merely observation.
> > 
> > We're offered a gift, and then it turns out that it's not a gift. 
> 
> No, the customer wants a pony. See http://c2.com/cgi/wiki?IwantaPony

The customer was offered a Ferrari.


> > Does that show that we don't know what we really want, or merely that
> > we're capable of distinguishing between two quite different things:
> > the gift of a Ferrari versus purchasing a Ferrari.
> 
> No, it shows that they really need and can afford things (Ford) that are 
> not what they *think* that they want (Ferrari).

What confusion! 
The customer said they would like to have a Ferrari - there's no
reason to doubt that. They don't wish to pay you $250,000 for a
Ferrari. That says nothing about what they really need or what they
can afford.

> Paul:
>> The idea that people seldom know what they really want has been 
>> verified by experiment.

Laurent Bossavit wrote:
> I tend to doubt that philosophical questions can be verified by 
> experiment. A tip-off that the question you are describing is a 
> philosphical one is the appearance of the word "really".

This phrasing was not mine - I was paraphrasing Scott. I took it to mean
what a customer might imagine they would want versus what they do want
when given the choice. That difference is what the experiments
demonstrate. It's not an attempt to answer any philosophical question as
far as I am aware.

> I'm certain that many experiments have been done, and more are being 
> done, on how well people's expectations of their own behaviours match
> the reality of these behaviours.

They have. A dozen or more are described in the book. Which is, after
all, what the book is about.

Another example is the research that demonstrates patients commonly
prefer to have others make decisions for them. 65% of people surveyed
said that, if they had cancer, they would want to choose their own
treatment. But, in fact, only 12% of people who have cancer want to make
that choice.

> But think back to the sub-thread which concluded with Isaac and me 
> agreeing that "there's no point in being precise if we don't know 
> what we are talking about". The question "do customers know what they
> really want" is one of these questions where we don't know what we 
> are talking about.

I don't understand the point you are making.

> A while ago, I posted some thoughts toward getting clear on what we 
> are talking about: http://bossavit.com/thoughts/archives/000687.html
> 
> Laurent http://bossavit.com/thoughts/

Yes, these experiences are similar to my own. I don't see that they
contradict any of the experimental evidence.

On Mon, 26 Apr 2004 08:52:24 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>What I hear and read in XP literature, if I may paraphrase, is;
>"We don't need that level of skill/practice because we have the
>people in the room."

There's no denying that it would be good if some of the people in the
room had those skills.



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

Scott Kinney wrote:
> If we are thinking of the same requirements gathering techniques, 
> they do not come from a base of 'the customer doesn't know what they
> want', they come from a base of 'the project team doesn't know what
> the customer wants.'

These are not either / or positions. If all we had to do was ask the
customer to write the requirements, requirements gathering would be
trivial. But it is not that simple. That is why methods were designed to
address the problem.

> My objection to the attitude is:
> 
> 1. I don't believe that it's true. The customer knows their business,
>    they know it way better than I do, and they know their business 
>    needs better than I do (at least at the beginning.)
> 
> 2. The attitude has no payoff in the requirements gathering process, 
>    it gives me no advantage, and it poisons my ability to build 
 >    rapport with them.

This is a different issue. We are mixing need with want - they are
commonly confused and a major contributor to the problem of requirements
misalignment. The standard distinction is as follows:

  "Need and want. Need implies an objective judgement, want a subjective,
   a distinction often blurred by loose use of want. A child may need
   punishment but is unlikely to want it. 'Never was legislation more
   needed; never was it less wanted,' said Lloyd George of his National
   Health Insurance Act." -- Fowler's Modern English Usage

The customer is indeed the expert when it comes to their business needs.
No argument there from me, XP, or any requirements gathering method I
know of.

> Laurent Bossavit wrote:
>> A while ago, I posted some thoughts toward getting clear on what we 
>> are talking about: http://bossavit.com/thoughts/archives/000687.html
>>
>> Laurent http://bossavit.com/thoughts/

Paul Sinnett wrote:
> Yes, these experiences are similar to my own. I don't see that they
> contradict any of the experimental evidence.

You do appear to confuse need with want here though:

   ... I believed in "customers don't know what they want". I knew better
   than my customers what they needed.

As I pointed out to Scott, it's not my position that customer's are a 
bad source for what they need, only that they are a bad source for what 
they want.

On Mon, 26 Apr 2004 17:37:36 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>
>"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
>news:d7uq80hvlahpifkg08am41pgfl7dmsgquf@4ax.com...
>> >> Another part of the cost is that waiting longer to ship value reduces
>> >> return on investment.
>> >>
>> >I meant to ask this earlier; when you use the term 'return on investment'
>> >do you mean it literally (an actual model of costs, returns, value over
>time
>> >return on separate features of the project, etc.) or more figuratively?
>>
>> I mean it both literally and figuratively.
>
>Please tell me how you model this as a literal calculation; factors,
>assumptions,
>time horizons, costs, etc.
>
>I set up two projects, 12 features to deliver, equal amounts of
>effort to deliver, and delivering 1 per month doesn't seem to provide
>(numerically anyway) a greater return on investment than delivering
>3 per quarter, say, or 6 every 6 months.
>
>What goes into your calculation?

Suppose we have 12 features, each worth $1000 per month in revenue
after deployment. If we deploy 6 every six months, our revenue looks
like this:

month    revenue
1           0
2           0
3           0
4           0
5           0
6           0
7           6000
8           6000
9           6000
10         6000
11         6000
12         6000
13         12000
total       48000 in 13 months

If we deploy 1 feature every month, revenue looks like this:
1           0
2           1000
3           2000
4           3000
5           4000
6           5000
7           6000
8           7000
9           8000
10         9000
11         10000
12         11000
13	12000
total       78000 in 13 months

The same reasoning holds, less numerically, for any kind of value,
tangible or intangible, that the program may provide. Value sooner
increases ROI.

Questions?

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On 26 Apr 2004 15:40:09 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Jason Nocks <nocksj@sourcextreme.com> wrote in message news:<cb067$408d3bc7$cff54506$3521@dcanet.allthenewsgroups.com>...
> 
>> > Why are we asking customers to imagine what a software product could
>> > be like? Shouldn't we be asking: What are the business goals? What are
>> > the business tasks that need to be completed?
>> 
>> My understanding was that we were talking about the *details* of the 
>> requirements. 
>
>The OP was talking about business goals and tasks: "The customer
>always knows exactly what they want from a business perspective."

I'd not fully agree with this. What one wants is conditioned by what
it will cost to get it, and made less than certain by one's limited
ability to imagine things. 

I think that the customer generally has a decent idea what they want,
and that guided by information about cost and by seeing what has been
wrought, they come to a better understanding of what should be done.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Mon, 26 Apr 2004 17:37:36 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>
>"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
>news:d7uq80hvlahpifkg08am41pgfl7dmsgquf@4ax.com...
>> >> Another part of the cost is that waiting longer to ship value reduces
>> >> return on investment.
>> >>
>> >I meant to ask this earlier; when you use the term 'return on investment'
>> >do you mean it literally (an actual model of costs, returns, value over
>time
>> >return on separate features of the project, etc.) or more figuratively?
>>
>> I mean it both literally and figuratively.
>
>Please tell me how you model this as a literal calculation; factors,
>assumptions,
>time horizons, costs, etc.
>
>I set up two projects, 12 features to deliver, equal amounts of
>effort to deliver, and delivering 1 per month doesn't seem to provide
>(numerically anyway) a greater return on investment than delivering
>3 per quarter, say, or 6 every 6 months.

Ron can answer this better than I can.  However, I'll just say this.
You make more money by putting a dollar a day in the bank, than by
putting 365 dollars in the bank every January 1st.  This is especially
true if the interest rate is very high, (which it better be if the
project is really worth doing).





-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

On Mon, 26 Apr 2004 09:09:01 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>If we are thinking of the same requirements gathering techniques, they do
>not
>come from a base of 'the customer doesn't know what they want', they come
>from
>a base of 'the project team doesn't know what the customer wants.'
>
>My objection to the attitude is:
>
>1. I don't believe that it's true. The customer knows their business, they
>know
>it way better than I do, and they know their business needs better than I do
>(at least at the beginning.)

They even know them better at the end.  The problem is they don't know
what kind of system will best address those needs.

>2. The attitude has no payoff in the requirements gathering process, it
>gives
>me no advantage, and it poisons my ability to build rapport with them.

On the contrary, it give you a starting place.  You can assess their
needs, and recommend a potential solution in terms of a few system
requirements.  That recommendation is a hypothesis -- a guess that
those system behaviors will have value.  Once you have a hypothesis,
the next thing to do is to test it.  In this case, we test it by
building a simple system that has those behaviors and letting the
customer touch, feel, and (better yet) use it. 

The result of this experiment will show that you were right about some
things and wrong about others.  We make a new hypothesis and run the
experiment again.  The more often we can run it, the faster we
converge on what the customer *really* wants.


>

-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

On 26 Apr 2004 09:06:10 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Paul Sinnett <paul.sinnett@btinternet.com> wrote in message news:<408c9592$1@news.totallyobjects.com>...
>
>> Scott Kinney wrote:
>> > Finally, the sentiment "...customers seldom know what they really 
>> > want..." is probably the most disrespectful and condescending notion 
>> > I've heard come out of a discipline that holds "Open and Honest 
>> > Communication" as a core value.
>> 
>> The idea that people seldom know what they really want has been verified
>> by experiment.
>> 
>> In, The Paradox of Choice, Barry Schwartz describes an experiment where
>> two groups of college students were asked to choose between a variety of
>> snacks during the break of three seminars (one a week for three weeks).
>
>This is about "preferences".
>What the students really want is not to be hungry.

That need could be adequately addressed with cans of Alpo. Cheap,
nutritious, and utterly unacceptable.  Indeed, this is what many
customers get at the end of the day.  A system that addresses the
need, and is unacceptable.

Larman's recent book: "Agile and Iterative Development: A managers
Guide" is loaded with data on this, and many other issues.

-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

On Mon, 26 Apr 2004 09:22:17 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>With a fair grip on that, I bring the business customer back in
>and walk through the design, showing why or how I think the design
>meets their business needs. They get to disagree, add detail, and so on.

Which is a nice way to get buy-in for a hypothesis.  The next thing to
do is test that hypothesis by building a simple system that exhibits
the behaviors you described.

-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

Scott Kinney wrote:
> "Jason Nocks" <nocksj@sourcextreme.com> wrote in message
> news:de9ba$408d436c$cff54506$3740@dcanet.allthenewsgroups.com...

<was snipped>
 >>> I apologize. Which question was that?
</was snipped>

>>>Have we cleared this up?
> 
> Yes, I've become convinced that you are constitutionally
> incapable of answering the question.

Let me repeat:
"I apologize. Which question was that?" -me

I can't answer the question if I don't know what the question is.

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Laurent Bossavit <laurent@dontspambossavit.com> wrote in message news:<MPG.1af7a1c492488a90989766@news.noos.fr>...

> > Why are we asking customers to imagine what a software product could
> > be like? Shouldn't we be asking: What are the business goals? What are
> > the business tasks that need to be completed?
> 
> Those are two *very* different questions - I'm concerned that asking 
> them in close succession, you might be suggesting that they are two 
> sides of one coin. Tasks support goals - there's a logical order there.

We could take Table 1 in Lauesen's paper as an example.
 
> As to the "why" question, the problem is that while goals can often be 
> articulated in vague, general terms at the outset of a project, to reach 
> a goal requires restating it in precise (that word again) terms. A goal 
> must also be positive, achievable, observable, and somewhat flexible.

And goals can often be articulated in precise terms at the outset of a
project.

> Very often, you can only meet these standards after doing one or more of 
> the following (and that's a partial list):
> - breaking the goal down into sub-goals
> - seeing a partial solution in action
> - discovering unwanted side-effects of attaining the goal
> - discarding the original goal for a revised version

Seems like we've skipped into talking about particular solutions
rather than goals.


> Goal-setting often proceeds in parallel with solution-exploring. This is 
> why part of specifying what we want from a software product involves 
> imagining what the product will be like.

Yes "part of specifiying what we want" - but now we are talking about
particular aspects of the solution, rather than the changes we will
achieve in the business.

"solving someone's problem with code involves listening to that
person"
To listen well (or read well) it seems we must put our own
understanding to one side, so we can hear what the other says.

"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:3obr8055hbjei14t3e0ldcgu1i9thahcb0@4ax.com...
> On Mon, 26 Apr 2004 17:37:36 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
> >
> >"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> >news:d7uq80hvlahpifkg08am41pgfl7dmsgquf@4ax.com...
> >> >> Another part of the cost is that waiting longer to ship value
reduces
> >> >> return on investment.
> >> >>
> >> >I meant to ask this earlier; when you use the term 'return on
investment'
> >> >do you mean it literally (an actual model of costs, returns, value
over
> >time
> >> >return on separate features of the project, etc.) or more
figuratively?
> >>
> >> I mean it both literally and figuratively.
> >
> >Please tell me how you model this as a literal calculation; factors,
> >assumptions,
> >time horizons, costs, etc.
> >
> >I set up two projects, 12 features to deliver, equal amounts of
> >effort to deliver, and delivering 1 per month doesn't seem to provide
> >(numerically anyway) a greater return on investment than delivering
> >3 per quarter, say, or 6 every 6 months.
> >
> >What goes into your calculation?
>
> Suppose we have 12 features, each worth $1000 per month in revenue
> after deployment. If we deploy 6 every six months, our revenue looks
> like this:
>
> month    revenue
> 1           0
> 2           0
> 3           0
> 4           0
> 5           0
> 6           0
> 7           6000
> 8           6000
> 9           6000
> 10         6000
> 11         6000
> 12         6000
> 13         12000
> total       48000 in 13 months
>
> If we deploy 1 feature every month, revenue looks like this:
> 1           0
> 2           1000
> 3           2000
> 4           3000
> 5           4000
> 6           5000
> 7           6000
> 8           7000
> 9           8000
> 10         9000
> 11         10000
> 12         11000
> 13 12000
> total       78000 in 13 months
>
> The same reasoning holds, less numerically, for any kind of value,
> tangible or intangible, that the program may provide. Value sooner
> increases ROI.
>
> Questions?
>

The simplifying assumption you made that each feature has a non-zero
return was one place where I was having formulation difficulties.

While a project as a whole has a return, it's not clear that all of
its component features do. Further, under the planning game, those
with the highest perceived return are done first, and lesser returns
later. That said, assuming uniform returns are the simplest assumption.

Another difficulty was the presence of end-users on the project
team for its duration. The additional cost for their time should include
an opportunity cost for their lost revenue while participating.

Finally, the cost of refactoring at the conclusion of the project
increases the cost.

How do you take these into account?

Scott Kinney wrote:
> "Ronald E Jeffries" <ronjeffries@acm.org> wrote in message

>> Suppose we have 12 features, each worth $1000 per month in revenue
>> after deployment. If we deploy 6 every six months, our revenue looks
>> like this:
>>
>> month    revenue
>> 1           0
>> 2           0
>> 3           0
>> 4           0
>> 5           0
>> 6           0
>> 7           6000
>> 8           6000
>> 9           6000
>> 10         6000
>> 11         6000
>> 12         6000
>> 13         12000
>> total       48000 in 13 months
>>
>> If we deploy 1 feature every month, revenue looks like this:
>> 1           0
>> 2           1000
>> 3           2000
>> 4           3000
>> 5           4000
>> 6           5000
>> 7           6000
>> 8           7000
>> 9           8000
>> 10         9000
>> 11         10000
>> 12         11000
>> 13 12000
>> total       78000 in 13 months
>>
>> The same reasoning holds, less numerically, for any kind of value,
>> tangible or intangible, that the program may provide. Value sooner
>> increases ROI.
>>
>> Questions?
>>
>
> The simplifying assumption you made that each feature has a non-zero
> return was one place where I was having formulation difficulties.

If a feature as a non-positive value, why would you implement it?

> Further, under the planning game, those
> with the highest perceived return are done first, and lesser returns
> later. That said, assuming uniform returns are the simplest
> assumption.

Yes - with non-uniform returns (doing the most valuable features first), the
monthly deployment gives even better return on investment.

> Another difficulty was the presence of end-users on the project
> team for its duration. The additional cost for their time should
> include an opportunity cost for their lost revenue while
> participating.

What does this have to do with Frequent Releases?

> Finally, the cost of refactoring at the conclusion of the project
> increases the cost.

I guess you mean refactoring during the project - refactoring at the end
wouldn't make much sense.

And it's far from obvious to me that design by refactoring is more costly
than upfront design.

Take care, Ilja

"Ilja Preu�" <preuss@disy.net> wrote in message
news:c6ldv4$2eq$1@stu1id2.ip.tesion.net...
> Scott Kinney wrote:
> > "Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
>
> >> Suppose we have 12 features, each worth $1000 per month in revenue
> >> after deployment. If we deploy 6 every six months, our revenue looks
> >> like this:
> >>
> >> month    revenue
> >> 1           0
> >> 2           0
> >> 3           0
> >> 4           0
> >> 5           0
> >> 6           0
> >> 7           6000
> >> 8           6000
> >> 9           6000
> >> 10         6000
> >> 11         6000
> >> 12         6000
> >> 13         12000
> >> total       48000 in 13 months
> >>
> >> If we deploy 1 feature every month, revenue looks like this:
> >> 1           0
> >> 2           1000
> >> 3           2000
> >> 4           3000
> >> 5           4000
> >> 6           5000
> >> 7           6000
> >> 8           7000
> >> 9           8000
> >> 10         9000
> >> 11         10000
> >> 12         11000
> >> 13 12000
> >> total       78000 in 13 months
> >>
> >> The same reasoning holds, less numerically, for any kind of value,
> >> tangible or intangible, that the program may provide. Value sooner
> >> increases ROI.
> >>
> >> Questions?
> >>
> >
> > The simplifying assumption you made that each feature has a non-zero
> > return was one place where I was having formulation difficulties.
>
> If a feature as a non-positive value, why would you implement it?

A feature  with no economic return may be required in order to support
another
feature with a higher return.

>
> > Further, under the planning game, those
> > with the highest perceived return are done first, and lesser returns
> > later. That said, assuming uniform returns are the simplest
> > assumption.
>
> Yes - with non-uniform returns (doing the most valuable features first),
the
> monthly deployment gives even better return on investment.
>
Maybe, that's what I'm trying to work out.


> > Another difficulty was the presence of end-users on the project
> > team for its duration. The additional cost for their time should
> > include an opportunity cost for their lost revenue while
> > participating.
>
> What does this have to do with Frequent Releases?

It doesn't have anything to do with Frequent Releases per se, but
their presence (and lost revenue caused by their participation)
on an XP team increases the cost, the "I" in ROI.

>
> > Finally, the cost of refactoring at the conclusion of the project
> > increases the cost.
>
> I guess you mean refactoring during the project - refactoring at the end
> wouldn't make much sense.
>
OK, the cost of refactoring. It also increases the cost of the project and
reduces the ROI.

"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:6uer80tc30lagq12nkprt2rsj5bom6v0u2@4ax.com...
> On Mon, 26 Apr 2004 17:37:36 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
> >
> >"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> >news:d7uq80hvlahpifkg08am41pgfl7dmsgquf@4ax.com...
> >> >> Another part of the cost is that waiting longer to ship value
reduces
> >> >> return on investment.
> >> >>
> >> >I meant to ask this earlier; when you use the term 'return on
investment'
> >> >do you mean it literally (an actual model of costs, returns, value
over
> >time
> >> >return on separate features of the project, etc.) or more
figuratively?
> >>
> >> I mean it both literally and figuratively.
> >
> >Please tell me how you model this as a literal calculation; factors,
> >assumptions,
> >time horizons, costs, etc.
> >
> >I set up two projects, 12 features to deliver, equal amounts of
> >effort to deliver, and delivering 1 per month doesn't seem to provide
> >(numerically anyway) a greater return on investment than delivering
> >3 per quarter, say, or 6 every 6 months.
>
> Ron can answer this better than I can.  However, I'll just say this.
> You make more money by putting a dollar a day in the bank, than by
> putting 365 dollars in the bank every January 1st.  This is especially
> true if the interest rate is very high, (which it better be if the
> project is really worth doing).
>

That's true only if the cost of capital were equal in both cases. If, on the
other hand you borrowed the $1 per day in order to put it in the bank,
your return is obviously reduced.

In article <qOadnWC7gr3coBPd4p2dnA@comcast.com>,
    Scott Kinney <sakinney@ix.netcom.com> wrote:

: "Ilja Preu�" <preuss@disy.net> wrote in message
: news:c6ldv4$2eq$1@stu1id2.ip.tesion.net...
:
: > If a feature as a non-positive value, why would you implement it?
: 
: A feature with no economic return may be required in order to support
: another feature with a higher return.

Um, your statement is absurd (i.e., self-contradictory).  If a feature
is necessary to support another profitable feature, then the former
must also be profitable.

: [...]

Greg
-- 
Amazon.com status as a dot-com questioned:
    http://www.dailyreckoning.com/jokes.cfm?jokeid=348

"Greg Bacon" <gbacon@hiwaay.net> wrote in message
news:108ss0lo8n5kh07@corp.supernews.com...
> In article <qOadnWC7gr3coBPd4p2dnA@comcast.com>,
>     Scott Kinney <sakinney@ix.netcom.com> wrote:
>
> : "Ilja Preu�" <preuss@disy.net> wrote in message
> : news:c6ldv4$2eq$1@stu1id2.ip.tesion.net...
> :
> : > If a feature as a non-positive value, why would you implement it?
> :
> : A feature with no economic return may be required in order to support
> : another feature with a higher return.
>
> Um, your statement is absurd (i.e., self-contradictory).  If a feature
> is necessary to support another profitable feature, then the former
> must also be profitable.
>
An infrastructure feature, say a particular level of security, is not, of
itself
profitable (does not generate revenue, does not reduce costs, in fact *is*
an
item of cost.), it's a 'sunk cost', but it may be necessary to support
another
feature that is profitable.

This distinction is an artifact of breaking a project with many features
that has a positive return overall, into many features. Some will have
positive returns some will not.

Scott Kinney wrote:

> An infrastructure feature, say a particular level of security, is
> not, of itself
> profitable (does not generate revenue, does not reduce costs, in fact
> *is* an item of cost.), it's a 'sunk cost', but it may be necessary to
support
> another feature that is profitable.

How do you determine which one of the features has the value and which does
not?

For example, say someone wants to pay for putting things into our database,
but only with a particular level of security. We already have implemented
the input feature, which didn't generate any revenue (because they won't use
it). Now implementing the security will generate the revenue.

> This distinction is an artifact of breaking a project with many
> features that has a positive return overall, into many features. Some
> will have positive returns some will not.

Well, perhaps the art is to break a project into features so that every
feature *does* have a positive value. Perhaps, infrastructure isn't a
feature at all...

Take care, Ilja

Scott Kinney wrote:
> "Ilja Preu�" <preuss@disy.net> wrote in message

>>> Finally, the cost of refactoring at the conclusion of the project
>>> increases the cost.
>>
>> I guess you mean refactoring during the project - refactoring at the
>> end wouldn't make much sense.
>>
> OK, the cost of refactoring. It also increases the cost of the
> project and reduces the ROI.

As I said, I am far from convinced that refactoring increases the cost of
the project - quite the contrary.

Take care, Ilja

"Ilja Preu�" <preuss@disy.net> wrote in message
news:c6lvs7$71l$1@stu1id2.ip.tesion.net...
> Scott Kinney wrote:
> > "Ilja Preu�" <preuss@disy.net> wrote in message
>
> >>> Finally, the cost of refactoring at the conclusion of the project
> >>> increases the cost.
> >>
> >> I guess you mean refactoring during the project - refactoring at the
> >> end wouldn't make much sense.
> >>
> > OK, the cost of refactoring. It also increases the cost of the
> > project and reduces the ROI.
>
> As I said, I am far from convinced that refactoring increases the cost of
> the project - quite the contrary.
>
Actually what you said was that you were not convinced that
the cost of refactoring was greater than that of upfront design. Which
no one asserted, so.....

Help me understand why refactoring decreases the cost of the project.

It is additional work, the cost of labor is greater than zero, .so...

> "Ilja Preu�" <preuss@disy.net> wrote in message
> news:c6ldv4$2eq$1@stu1id2.ip.tesion.net...
> > Scott Kinney wrote:
> > > "Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> > >> Questions?
> > >>
> > >
> > > The simplifying assumption you made that each feature has a non-zero
> > > return was one place where I was having formulation difficulties.
> >
> > If a feature as a non-positive value, why would you implement it?


"Scott Kinney" <sakinney@ix.netcom.com> wrote...
> A feature  with no economic return may be required in order to
> support another feature with a higher return.

In XP, we don't do that.  Whatever features have the highest return on
investment for the customer, we do first.

What ever "infrastructure" may eventually be needed, we implement
incrementally, as it is needed.


>>> Another difficulty was the presence of end-users on the project
>>> team for its duration. The additional cost for their time should
>>> include an opportunity cost for their lost revenue while
>>> participating.

>> What does this have to do with Frequent Releases?

> It doesn't have anything to do with Frequent Releases per se, but
> their presence (and lost revenue caused by their participation)
> on an XP team increases the cost, the "I" in ROI.

Increased customer participation has a cost.  But it also provides
benefits; let's not forget that.

The customers could, for example, save the entire amount of this cost
by refusing to participate in the project at all; but then the
resulting system would probably be of little benefit to them.  ;->


>>> Finally, the cost of refactoring at the conclusion of the project
>>> increases the cost.

>> I guess you mean refactoring during the project - refactoring at
the end
>> wouldn't make much sense.

> OK, the cost of refactoring. It also increases the cost of the project and
> reduces the ROI.

Refactoring, overall, reduces costs.

"Ilja Preu�" <preuss@disy.net> wrote in message
news:c6lvfg$67d$1@stu1id2.ip.tesion.net...
> Scott Kinney wrote:
>
> > An infrastructure feature, say a particular level of security, is
> > not, of itself
> > profitable (does not generate revenue, does not reduce costs, in fact
> > *is* an item of cost.), it's a 'sunk cost', but it may be necessary to
> support
> > another feature that is profitable.
>
> How do you determine which one of the features has the value and which
does
> not?
>
By performing an economic, or cost benefit estimate of the features.
Before you blow a gasket, keep this in the context of calculating a
return on investment for the project.

You can make a simplifying assumption that  all features represent
an equal share of incremental revenue and project expense. Or, you
can do the estimate in detail. If you do it in detail, you'll find some
features
cost less than others, some make more revenue than others, hence different
rates of return per feature.

My contention from a problem modeling perspective is that, depending on how
the work is divided, some of it will have very, very low, or even zero rate
of
return on investment.


>
> > This distinction is an artifact of breaking a project with many
> > features that has a positive return overall, into many features. Some
> > will have positive returns some will not.
>
> Well, perhaps the art is to break a project into features so that every
> feature *does* have a positive value. Perhaps, infrastructure isn't a
> feature at all...
>

Perhaps it isn't, perhaps it is. If a frog had wings he wouldn't bump his
ass quite so much...

"Jeff Grigg" <jgrigg@mo.net> wrote in message
news:c794c0fd.0404270810.26ef9f2@posting.google.com...
> > "Ilja Preu�" <preuss@disy.net> wrote in message
> > news:c6ldv4$2eq$1@stu1id2.ip.tesion.net...
> > > Scott Kinney wrote:
> > > > "Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> > > >> Questions?
> > > >>
> > > >
> > > > The simplifying assumption you made that each feature has a non-zero
> > > > return was one place where I was having formulation difficulties.
> > >
> > > If a feature as a non-positive value, why would you implement it?
>
>
> "Scott Kinney" <sakinney@ix.netcom.com> wrote...
> > A feature  with no economic return may be required in order to
> > support another feature with a higher return.
>
> In XP, we don't do that.  Whatever features have the highest return on
> investment for the customer, we do first.
>
> What ever "infrastructure" may eventually be needed, we implement
> incrementally, as it is needed.
>
Agreed, and that iteration will have a higher cost, and lower return.


>
> >>> Another difficulty was the presence of end-users on the project
> >>> team for its duration. The additional cost for their time should
> >>> include an opportunity cost for their lost revenue while
> >>> participating.
>
> >> What does this have to do with Frequent Releases?
>
> > It doesn't have anything to do with Frequent Releases per se, but
> > their presence (and lost revenue caused by their participation)
> > on an XP team increases the cost, the "I" in ROI.
>
> Increased customer participation has a cost.  But it also provides
> benefits; let's not forget that.
>
No one is forgetting it. I was just saying that in calculating the
return on investment for the project the participating customer would
have both a direct cost and an opportunity cost (the revenue lost
during their participation.)

> >>> Finally, the cost of refactoring at the conclusion of the project
> >>> increases the cost.
>
> > OK, the cost of refactoring. It also increases the cost of the project
and
> > reduces the ROI.
>
> Refactoring, overall, reduces costs.

But it costs money to do it, does it not?

Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<fjfr80hthuvqkcj8j2dorktkt7hmikae5a@4ax.com>...

> >> In, The Paradox of Choice, Barry Schwartz describes an experiment where
> >> two groups of college students were asked to choose between a variety of
> >> snacks during the break of three seminars (one a week for three weeks).
> >
> >This is about "preferences".
> >What the students really want is not to be hungry.
> 
> That need could be adequately addressed with cans of Alpo. Cheap,
> nutritious, and utterly unacceptable.  

The issue here is that the 'goals' of the students in taking a snack
during their break are unexamined.
- Am I just hungry?
- Am I trying to fit-in a clique?
....
The actions needed to fulfill the 'goal' are contingent on
circumstances
- Did I have lunch? 
- Is everyone in the clique having Alpo?
....
That doesn't mean the goal changed.


> Indeed, this is what many customers get at the end of the day.  A system
> that addresses the need, and is unacceptable.

One gross generalization deservers another :-)

What many customers get at the end of the day is a system that doesn't
address the need but can be 'skinned'.

In article <A4qdneKl8Ij47xPdRVn-gQ@comcast.com>,
    Scott Kinney <sakinney@ix.netcom.com> wrote:

: "Greg Bacon" <gbacon@hiwaay.net> wrote in message
: news:108ss0lo8n5kh07@corp.supernews.com...
:
: > Um, your statement is absurd (i.e., self-contradictory).  If a
: > feature is necessary to support another profitable feature, then the
: > former must also be profitable.
:
: An infrastructure feature, say a particular level of security, is not,
: of itself profitable (does not generate revenue, does not reduce
: costs, in fact *is* an item of cost.),

*Nothing* is of itself profitable: you must first have a buyer for what
you're selling, and the buyer must be willing to pay more, at least at
the margin, than it cost you to produce.

Say a company develops web services for banks that allow customers to
check their balances, transfer between accounts, view cleared checks,
etc.  No matter how snazzy the features, without security, very nearly
all banks would decline to purchase, and those unsophisticated enough
to buy would create opportunities for their competitors: "Our online
banking is secure, unlike other banks that don't value your privacy!"

Without security, this product's value is extremely low, so your claim
does not pan out.

:                                        it's a 'sunk cost', but it may
: be necessary to support another feature that is profitable.

You're abusing terminology.  A sunk cost is a particular choice made in
the past.  No one can reclaim an opportunity expended in the past, so
the cost is sunk.  Especially in the case of a bad choice, the person
responsible often won't treat the decision as a sunk cost and flails to
make the choice appear wise.

In the context of this discussion, a well-known, sometimes haunting
sunk cost is The Design Document.  When the inevitable flaws surface,
psychological barriers are in the way, especially late in the game:

  - "Yes, that would be a nicer way to do it, but it conflicts
    with The Design Document."

  - "This aspect of The Design Document has very serious problems,
    but the fix means updating The Design Document and seven
    formal reviews."

: This distinction is an artifact of breaking a project with many
: features that has a positive return overall, into many features. Some
: will have positive returns some will not.

The fundamental problem is the use of the broken-by-design tool known
as econometrics, i.e., attempting to mathematize value, which is by
nature subjective and immeasurable.

For example, real estate appraisal is not a matter of counting all the
bricks and 2x4s and sheets of drywall and gallons of paint but instead
an educated guess at what a buyer would likely pay for a house given
recent sales of comparable houses.  Also, cosmetic fixups often boost
disproportionately the purchase price, i.e., $1,000 of time and
materials might result in a $5,000 cost bump.

To someone who wants a fireplace, though, even a very beautiful house
with no fireplace begins at a disadvantage.

People who work in direct-response ads have a similar emphasis on the
whole.  I once read the following in a book that emphasized testing
in marketing (and regret that I don't have the attribution):

    Look at an ad of the Mead Cycle Company -- a typical
    mail-order ad. These have been running for many years. The
    ads are unchanging. Mr. Mead told the writer that not for
    $10,000 would he change a single word in his ads. For many
    years, he compared one ad with the other. And the ads you
    see today are the final results of all those experiments.
    Note the picture he uses, the headlines, the economy of
    space, the small type. Those ads are as near perfect for
    their purpose as an ad can be.

So, yes, it's silly to try to individually value the components of some
whole.  We learn from economics, however, that a person can compare his
preferences, e.g., given twenty bucks, he'd rather go buy a book than
buy a meal out.  This is at the core of Release Planning: the customer
prioritizes features given estimates of cost.

Actually -- and I don't know whether it was intentional -- the practices
and values of XP dovetail nicely with principles of sound economics.

Greg
-- 
Laws that forbid the carrying of arms ... make things worse for the assaulted
and better for the assailants; they serve rather to encourage than to prevent
homicides, for an unarmed man may be attacked with greater confidence than an
armed man.        -- Thomas Jefferson

In article <svidnW4kj9JiGxPdRVn-vA@comcast.com>,
    Scott Kinney <sakinney@ix.netcom.com> wrote:

: [...]
:
: My contention from a problem modeling perspective is that, depending
: on how the work is divided, some of it will have very, very low, or
: even zero rate of return on investment.

The security example you offered didn't exhibit this quality.  Can you
provide an example of a zero-return feature?

: [...]

Greg
-- 
The problem with the social-contract model is that it is a myth. If it were
true that the people agree to be ruled, the state would be essentially a
voluntary organization and everyone would clearly see its benefit.  It
would not have to be armed to the teeth.        -- Lew Rockwell

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<o8cr80hpm6mkk4taa0dpc64fj2f02dkk92@4ax.com>...

> >The OP was talking about business goals and tasks: "The customer
> >always knows exactly what they want from a business perspective."
> 
> I'd not fully agree with this. 

I'm not sure that I do either, but let's start from the position where
you partially agree with the statement.

> What one wants is conditioned by what it will cost to get it, and made less
> than certain by one's limited ability to imagine things. 

Maybe we could rephrase Laurent's comment - Do we know what we're
talking about yet?

Problem: cut costs
Solution: simplify payroll

   Problem: simplify payroll
   Solution: create a new payroll system to replace four different
systems,
             outsource payroll, change business processes, ...

The quality of solution is conditioned by cost, and limited by what we
can imagine (although we can imagine all manner of impossibilities).


> I think that the customer generally has a decent idea what they want,
So "decent idea" instead of "exactly" - we can probably all agree on
that.

> and that guided by information about cost and by seeing what has been
> wrought, they come to a better understanding of what should be done.

"what should be done" to achieve their 'business goals'.

In article <25udnWYzo-4aGBPdRVn-jw@comcast.com>,
    Scott Kinney <sakinney@ix.netcom.com> wrote:

: [...]
:
: [Refactoring] is additional work, the cost of labor is greater than
: zero, .so...

Additional relative to what?

Greg
-- 
Bigamy is having one wife too many.  Monogamy is the same.
    -- Oscar Wilde

"Greg Bacon" <gbacon@hiwaay.net> wrote in message
news:108t3qens049u30@corp.supernews.com...
> In article <25udnWYzo-4aGBPdRVn-jw@comcast.com>,
>     Scott Kinney <sakinney@ix.netcom.com> wrote:
>
> : [...]
> :
> : [Refactoring] is additional work, the cost of labor is greater than
> : zero, .so...
>
> Additional relative to what?
>
Additional relative to work performed to implement the feature.

Paul Sinnett <paul.sinnett@btinternet.com> wrote in message news:<408da748@news.totallyobjects.com>...

> You do appear to confuse need with want here though
There are usages which take want and need to be synonyms.

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<ejuq801adg6erju1nq4tbobkk5hpvknauf@4ax.com>...

Is there a //role// project manager?

"Greg Bacon" <gbacon@hiwaay.net> wrote in message
news:108t3fkm0vees7d@corp.supernews.com...
> In article <A4qdneKl8Ij47xPdRVn-gQ@comcast.com>,
>     Scott Kinney <sakinney@ix.netcom.com> wrote:
>
> : "Greg Bacon" <gbacon@hiwaay.net> wrote in message
> : news:108ss0lo8n5kh07@corp.supernews.com...
> :
> : > Um, your statement is absurd (i.e., self-contradictory).  If a
> : > feature is necessary to support another profitable feature, then the
> : > former must also be profitable.
> :
> : An infrastructure feature, say a particular level of security, is not,
> : of itself profitable (does not generate revenue, does not reduce
> : costs, in fact *is* an item of cost.),
>
> : This distinction is an artifact of breaking a project with many
> : features that has a positive return overall, into many features. Some
> : will have positive returns some will not.
>
> The fundamental problem is the use of the broken-by-design tool known
> as econometrics, i.e., attempting to mathematize value, which is by
> nature subjective and immeasurable.
>
> For example, real estate appraisal is not a matter of counting all the
> bricks and 2x4s and sheets of drywall and gallons of paint but instead
> an educated guess at what a buyer would likely pay for a house given
> recent sales of comparable houses.  Also, cosmetic fixups often boost
> disproportionately the purchase price, i.e., $1,000 of time and
> materials might result in a $5,000 cost bump.

But people still manage to estimate the return on construction costs
as one of their guides in deciding whether to build. Amazing. How do
they do that?

It was asserted earlier in the thread that the XP methodology had a
higher return on investment than plan-driven approaches. I asked if this
was a literal or figurative statement. I was assured it was literally true.

I  couldn't make the calculation work out, and asked for more information
on the model, assumptions and structure used to prove it was 'literally
true'.

The broad range of responses in the thread indicates to me that no one
actually knows if it's literally true, or rather actually has a model that
demonstrates it. So it seems to be more of a wish or belief that it has
a higher return on investment.

"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0404270904.23630146@posting.google.com...
> Ronald E Jeffries <ronjeffries@acm.org> wrote in message
news:<ejuq801adg6erju1nq4tbobkk5hpvknauf@4ax.com>...
>
> Is there a //role// project manager?

I'd like to hear what others have to say about it, but I'm
guessing that it's not a role, since XP isn't a project management
methodology.

> > Scott Kinney wrote:
> > > A feature  with no economic return may be required in order to
> > > support another feature with a higher return.
> >
> > In XP, we don't do that.  Whatever features have the highest return on
> > investment for the customer, we do first.
> >
> > What ever "infrastructure" may eventually be needed, we implement
> > incrementally, as it is needed.
> >
> Agreed, and that iteration will have a higher cost, and lower return.

Yes, but (in our experience) not as high as with a "traditional"
methodology.

Suppose you collect big-requirements-up-front, then create the best design
for all of them.

When a new requirement comes in - one just different enough to require new
design elements, but not different enough to require a new app - that design
may resist the change.

Suppose instead you iterate the design. It's now not the "best" for the
current feature set. And it's not even the "best" for testing.

The trade-off went in a different direction. The test rig around that code
is now the "best" to get that code into its current state, thru multiple
refactorings.

This represents an inversion of many of the values that project leaders have
bonded with. Sorry.

> > Refactoring, overall, reduces costs.
>
> But it costs money to do it, does it not?

No, because you have to do it anyway. You hear "rework" when we say
"refactoring". Because we refactor all the time, doing it after a major
course correction is as easy as after a minor one, due to practice.

Now sort features by business value order, and inject your major course
correction.

If you indeed added the highest value features first, then this course
correction must perforce apply to lower priority features. The odds that an
unimportant feature cause redesign in an important feature are low, but
pretend it happens anyway. We still want the best new design.

Because the more important features are already implemented, their tests
will keep them stable during the change. And their implementation will
reveal how best to fit in the new features. They will support and reinforce
the older features, adding to their business value.

-- 
  Phlip
    http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces

"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:_Oxjc.12896$UZ7.4977@newssvr31.news.prodigy.com...
> > > Scott Kinney wrote:
> > > > A feature  with no economic return may be required in order to
> > > > support another feature with a higher return.
> > >
> > > In XP, we don't do that.  Whatever features have the highest return on
> > > investment for the customer, we do first.
> > >
> > > What ever "infrastructure" may eventually be needed, we implement
> > > incrementally, as it is needed.
> > >
> > Agreed, and that iteration will have a higher cost, and lower return.
>
> Yes, but (in our experience) not as high as with a "traditional"
> methodology.
>
> Suppose you collect big-requirements-up-front, then create the best design
> for all of them.
>
> When a new requirement comes in - one just different enough to require new
> design elements, but not different enough to require a new app - that
design
> may resist the change.
>
Suppose the new requirement is consistent with the design. Suppose instead
that
the new requirement would push the budget or schedule beyond an acceptable
limit.
The new requirement is out of scope for the project, and the project
proceeds
merrily along.
Or, suppose that the new requirement doesn't 'pay' for the increase in cost
or time
with a sufficiently enhanced benefit. It too might be out of scope, and
again we
proceed with great alacrity.

On the refactoring point:

I appreciate that it is part of the standard workflow, in fact all the
various
bits of XP lore I've read, it's given as an important part of the process.
To count
the cost of the XP project, (part of the "I" in ROI), I'm just counting $
paid out.
Someone did the refactoring, someone got paid for the effort. If you always
re-factor,
then you always get paid for it. It's part of the cost.

"Scott Kinney" <sakinney@ix.netcom.com> wrote in 
news:PdmdnQ5sN8ukDBPdRVn-sw@comcast.com:

> 
> "Greg Bacon" <gbacon@hiwaay.net> wrote in message
> news:108t3qens049u30@corp.supernews.com...
>> In article <25udnWYzo-4aGBPdRVn-jw@comcast.com>,
>>     Scott Kinney <sakinney@ix.netcom.com> wrote:
>>
>> : [...]
>> :
>> : [Refactoring] is additional work, the cost of labor is greater than
>> : zero, .so...
>>
>> Additional relative to what?
>>
> Additional relative to work performed to implement the feature.
> 
> 

But it is part of the work performed to implement the feature. And future 
features.

Labor Needed to implement feature with refactoring:
Gather Basic Requirments.
Modify Current Code/Design to allow addition of feature(Refactoring).
Code to implement feature To spec.
Modify Code/design to Expected Quality Level(Refactoring).


Labor Needed to implement feature without refactoring:
Gather Perfect requirements.Otherwise Req change may force design change. 
Produce Perfect Design.
Code Feature.


OK, Perfection is not required but as these items become more removed 
from that ideal, the likelyhood of refactoring/redesign increases.

Refactoring is nothing more than the step between "Make it Work" and 
"Make it Right" 

I guess it might be extra work if you assume a near perfect initial 
design. All methods spec'ed and assigned to a class. Never a wrong turn. 
Then the difference is the difference between the cost of producing that 
masterwork and the cost of changing your code as you move along based on 
some lesser design plan.

Do you never try to improve on an initial design in small steps?

Otis

Scott Kinney wrote:

> Suppose the new requirement is consistent with the design. Suppose instead
> that the new requirement would push the budget or schedule beyond an
> acceptable limit.
> The new requirement is out of scope for the project, and the project
> proceeds merrily along.
> Or, suppose that the new requirement doesn't 'pay' for the increase in
cost
> or time with a sufficiently enhanced benefit. It too might be out of
scope, and
> again we proceed with great alacrity.

Then ... so what? I don't see how you think XP helps or hinders this
out-of-band activity.

> On the refactoring point:
>
> I appreciate that it is part of the standard workflow, in fact all the
> various bits of XP lore I've read, it's given as an important part of the
> process.

One block of XP lore, coming up...

A process becomes Agile when the rate that feedback collects information
about the current position exceeds the rate that developers change that
position.

At night, a car's headlights should illuminate things farther away than the
driver's reaction time and safe turning radius.

To lower the cost of change (and reduce that reaction time) Agile projects
automatically test everything relevant to a module after the fewest possible
edits; say 10 at the most. Only perform the kinds of edits that immediately
return the project to a useful state.

To lower the odds of re-working a module (and to boost those headlights),
frequently release working versions to end-users. But don't release bugs.
Relentless testing trades long hours running a debugger for short minutes
writing tests.

When tests drive development and make changes safe, the search for the set
of features that maximizes end-users' productivity becomes a simple
hill-climbing algorithm, where you take the steepest slope from your current
point, until you are king of the mountain.

To prevent long bug hunts, XP recommends Test-Driven Development, which
works by treating each new code ability as a minor bug, and by writing a
test to capture that bug before killing it. The supporting practices are
Merciless Refactoring, to paint yourself into corners and then cut new
doors; Simple Design, to prevent wasted engineering efforts; Pair
Programming, to continuously review each change, and Continuous Integration,
so issues caused by conflicting code changes get noticed instantly not late.

To avoid delays before releasing, XP teams don't just release often, they
Release Frequently, typically every two weeks, rain or shine. Teams that Sit
Together know a release's status subconsciously. Frequent Releases permit
the business side to request features that boost end-user productivity early
and often.

To avoid rework, XP teams boost end-user productivity early and often. A
hill-climbing algorithm only works on mountains without any secondary peaks,
but there it finds the shortest path up. The search for the maximum
productivity boost is such a search, as long as a product's features can
continuously deform. Merciless Refactoring and Test-Driven Development cover
this need.

Notice the fixes for those risks overlap. That's the point: The XP Practices
are all "best practices" when used alone - in moderation. Put together, they
moderate and reinforce each other, permitting extreme use without overhead.
Questions about practices have answers in other practices. Putting all
engineers in one room also helps prevent long bug hunts.

> To count  the cost of the XP project, (part of the "I" in ROI), I'm just
> counting $ paid out. Someone did the refactoring, someone got paid
> for the effort. If you always re-factor,
> then you always get paid for it. It's part of the cost.

But nobody got paid (or wasted time) to "design", because we scratched that
and added refactoring. To lower its cost, do it early and often.

-- 
  Phlip
    http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces

"Otis Bricker" <obricker@my-dejanews.com> wrote in message
news:Xns94D899DC2D9FAobrickermydejanewsco@216.196.97.136...
> "Scott Kinney" <sakinney@ix.netcom.com> wrote in
> news:PdmdnQ5sN8ukDBPdRVn-sw@comcast.com:
>
> >
> > "Greg Bacon" <gbacon@hiwaay.net> wrote in message
> > news:108t3qens049u30@corp.supernews.com...
> >> In article <25udnWYzo-4aGBPdRVn-jw@comcast.com>,
> >>     Scott Kinney <sakinney@ix.netcom.com> wrote:
> >>
> >> : [...]
> >> :
> >> : [Refactoring] is additional work, the cost of labor is greater than
> >> : zero, .so...
> >>
> >> Additional relative to what?
> >>
> > Additional relative to work performed to implement the feature.
> >
> >
>
> But it is part of the work performed to implement the feature. And future
> features.
>
> Labor Needed to implement feature with refactoring:
> Gather Basic Requirments.
> Modify Current Code/Design to allow addition of feature(Refactoring).
> Code to implement feature To spec.
> Modify Code/design to Expected Quality Level(Refactoring).
>
Thank you. At last a response that actually addresses my question!
And makes sense at the same time.

"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:Knyjc.12913$xl.4260@newssvr31.news.prodigy.com...
> Scott Kinney wrote:
>
> > Suppose the new requirement is consistent with the design. Suppose
instead
> > that the new requirement would push the budget or schedule beyond an
> > acceptable limit.
> > The new requirement is out of scope for the project, and the project
> > proceeds merrily along.
> > Or, suppose that the new requirement doesn't 'pay' for the increase in
> cost
> > or time with a sufficiently enhanced benefit. It too might be out of
> scope, and
> > again we proceed with great alacrity.
>
> Then ... so what? I don't see how you think XP helps or hinders this
> out-of-band activity.
>
It doesn't. You told a story where a new requirement resulted in
horrible disaster for a plan-driven approach. I told one where it didn't.

>
> To avoid delays before releasing, XP teams don't just release often, they
> Release Frequently, typically every two weeks, rain or shine. Teams that
Sit
> Together know a release's status subconsciously. Frequent Releases permit
> the business side to request features that boost end-user productivity
early
> and often.
>
Gosh, and I thought only plan-driven methodologies had an 80-hour
deliverable rule. Sorry, that was  a little snide.

Among long-time martial arts enthusiasts there's an inside joke: whenever a
style trumpets "We have this completely amazing technique!", other styles
respond "We have the same thing we just call it something different." I see
a lot
of that in these discussions.

> "Robert C. Martin" <unclebob@objectmentor.com> wrote...
>> Ron can answer this better than I can.  However, I'll just say
this.
>> You make more money by putting a dollar a day in the bank, than by
>> putting 365 dollars in the bank every January 1st.  This is
especially
>> true if the interest rate is very high, (which it better be if the
>> project is really worth doing).

"Scott Kinney" <sakinney@ix.netcom.com> wrote...
> That's true only if the cost of capital were equal in both cases. If, on the
> other hand you borrowed the $1 per day in order to put it in the bank,
> your return is obviously reduced.

Analogies can be confusing, and lead so easily to misunderstandings.

What we're talking about is...

Given that you have $1 a day to invest, which gives you the greater
return:

#1: Putting each dollar into your bed post, accumulating them until
the end of the year, and then putting $365 into an account that earns
interest.

- or -

#2: Putting each dollar into the interest earning account, daily.

So the cost of borrowing a dollar a day is irrelevant:  We're assuming
that you will have a dollar a day and put it somewhere.  So if you're
borrowing the dollars, you'll pay the same amount to borrow them,
regardless of where you invest them.

In article <qaCdnboZIZXKCxPdRVn-hg@comcast.com>,
    Scott Kinney <sakinney@ix.netcom.com> wrote:

: But people still manage to estimate the return on construction costs
: as one of their guides in deciding whether to build. Amazing. How do
: they do that?

What makes you believe that estimating a construction job is analagous
to estimating a software project?

: [...]
: The broad range of responses in the thread indicates to me that no one
: actually knows if it's literally true, or rather actually has a model
: that demonstrates it. So it seems to be more of a wish or belief that
: it has a higher return on investment.

You make such a big deal about models, but where are your models for
"plan-driven approaches"?  What's more important, in what ways do and
don't your models match actual practice?

The incongruities between the models ("Platonic forms" would be a more
accurate characterization) and actual practice for "plan-driven
approaches" reveal them, as with all econometric models, to be
unrealistic oversimplifications.  The idea of abrogating risk because
we've taken pains to write The Plan is a nice fantasy and makes for a
pleasant fa�ade to present to management, but not much more.

Careful not to construe my words as saying "plan-based approaches"
cannot work.  To make a blanket prescription is to beg to be proven
wrong over and over.  Different approaches work differently for
different people, but the Much-Vaunted Models make the bad assumption
-- to name only one -- that software people are more or less
indistinguishable in terms of contribution.

Greg
-- 
People often forget that every problem they solve is a special case of
some recursively unsolvable problem!
    -- Knuth

In article <PdmdnQ5sN8ukDBPdRVn-sw@comcast.com>,
    Scott Kinney <sakinney@ix.netcom.com> wrote:

: "Greg Bacon" <gbacon@hiwaay.net> wrote in message
: news:108t3qens049u30@corp.supernews.com...
:
: > Additional relative to what?
:
: Additional relative to work performed to implement the feature.

What makes you believe refactoring is actually additional work,
measured in, say, man-hours?

Greg
-- 
Compared to what the stock was worth in 1997, Enron employees lost an
average of about $20,000 per employee in the largest company failure in
U.S. history.  I've lost more money on Social Security in that time, and
no one's weeping for me.          -- Ann Coulter

In article <f_WdnfQFNdEBKxPdRVn-sQ@comcast.com>,
    Scott Kinney <sakinney@ix.netcom.com> wrote:

: "Phlip" <phlip_cpp@yahoo.com> wrote in message
: news:Knyjc.12913$xl.4260@newssvr31.news.prodigy.com...
:
: > Then ... so what? I don't see how you think XP helps or hinders this
: > out-of-band activity.
:
: It doesn't. You told a story where a new requirement resulted in
: horrible disaster for a plan-driven approach. I told one where it
: didn't.

Yes, these scenarios have different impacts, but what are their relative
frequencies?

: [...]
: Among long-time martial arts enthusiasts there's an inside joke:
: whenever a style trumpets "We have this completely amazing technique!",
: other styles respond "We have the same thing we just call it something
: different." I see a lot of that in these discussions.

Said another way: "There's nothing new under the sun."

Can you provide some examples?  I haven't found another set of practices
that matches XP's heavy emphasis on feedback and visibility.

Greg
-- 
The great enemy of clear language is insincerity.  When there is a gap between
one's real and one's declared aims, one turns as it were instinctively to long
words and exhausted idioms, like a cuttlefish squirting out ink.
    -- George Orwell

> "Greg Bacon" <gbacon@hiwaay.net> wrote...
>> [...]  If a feature is necessary to support another profitable
>> feature, then the former must also be profitable.

"Scott Kinney" <sakinney@ix.netcom.com> wrote...
> An infrastructure feature, say a particular level of security,
> is not, of itself profitable (does not generate revenue, does
> not reduce costs, in fact *is* an item of cost.), it's a 'sunk
> cost', but it may be necessary to support another feature that
> is profitable.

It may be that we agree, but we're just not describing things in the
same terminology or looking at things in exactly the same way.

As I see it, if the business people ask for something, then it should
have some business value, else why are the business people asking for
it?  If the business people are asking for security *because they want
it*, then it has business value to them.  On the other hand, if the
business people are asking for security because someone else told them
they had to have it, and would not be allowed to use or release the
system without it, then I can see how they wouldn't view security as
providing them any particular business value.  If the requirement is
rational, however, someone must think that security provides value. 
(I'll grant that the government and regulating agencies don't always
do the most rational things all the time.  ;-)

"But I *HAVE TO HAVE security*!!!" says the customer, "Therefore you
have to put it into the system!", they say.  "Well," says I, "what if
you put the computer in a locked room?  Would you have security then?"
  ;->   There's more than one way to have security.


On a more "infrastructure"-type vein:
If the first story is "Write a generic XML SOAP web services
framework, because we plan for all inter-server communication in this
system to use it.", then I'd reject it as a valid user story:  Having
the framework doesn't provide business value.  Later, should we need
inter-server communication, we'll figure out some direct and simple
way to do it.  If at some point we find XML and/or SOAP and/or web
services useful or valuable to the business, then we'll implement
them.  This is what we're thinking about in terms of "infrastructure"
stories.

"Jeff Grigg" <jgrigg@mo.net> wrote in message
news:c794c0fd.0404271304.947bdfc@posting.google.com...
> > "Robert C. Martin" <unclebob@objectmentor.com> wrote...
> >> Ron can answer this better than I can.  However, I'll just say
> this.
> >> You make more money by putting a dollar a day in the bank, than by
> >> putting 365 dollars in the bank every January 1st.  This is
> especially
> >> true if the interest rate is very high, (which it better be if the
> >> project is really worth doing).
>
> "Scott Kinney" <sakinney@ix.netcom.com> wrote...
> > That's true only if the cost of capital were equal in both cases. If, on
the
> > other hand you borrowed the $1 per day in order to put it in the bank,
> > your return is obviously reduced.
>
> Analogies can be confusing, and lead so easily to misunderstandings.
>
> What we're talking about is...

Actually, that wasn't what we were talking about. Bob was using the
analogy to support Ron's revenue stream of $1000 per month in project
'return'
being worth more than quarterly payments, or biannual payments or annual
payments.

>
> Given that you have $1 a day to invest, which gives you the greater
> return:
>
> #1: Putting each dollar into your bed post, accumulating them until
> the end of the year, and then putting $365 into an account that earns
> interest.
>
> - or -
>
> #2: Putting each dollar into the interest earning account, daily.
>
> So the cost of borrowing a dollar a day is irrelevant:  We're assuming
> that you will have a dollar a day and put it somewhere.  So if you're
> borrowing the dollars, you'll pay the same amount to borrow them,
> regardless of where you invest them.

Isaac Gouy wrote:
> There are usages which take want and need to be synonyms.

Yes. That is unfortunate.

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<2auq80hiee29rusd1hjthga3vb79q5qquc@4ax.com>...

> Surely producing a document plus code costs more than producing just
> code.

That statement is so weighed-down with unstated assumptions that it's
no more than rhetoric.

> Surely producing only code produces a program, and producing only a
> document does not.

And... that could mean we realized the whole project was stupid and
never started coding?


> Therefore a balance between when one documents (as late as possible)
> and when one programs (as early as possible) often makes sense.

Seemed like the OP was talking about using working documents to create
designs, seems like we've now started talking about documentation for
a design we have created.

> It depends on the relative cost of coding and documenting (where
> documenting may be less costly), on the relative value of the two
> (where coding is surely more valuable in the end), and on the
> observation that even if we document, we cannot avoid the cost of
> writing the code, but that we can sometimes avoid the cost of writing
> the document.

If we 'document' (that is if we work out a design with documents) we
may avoid the cost of writing code - we may prune that part of the
design space without going to code. We explore the design using a
"less costly" medium.

"Greg Bacon" <gbacon@hiwaay.net> wrote in message
news:108tjfk9ttej34c@corp.supernews.com...
> In article <qaCdnboZIZXKCxPdRVn-hg@comcast.com>,
>     Scott Kinney <sakinney@ix.netcom.com> wrote:
>
> What makes you believe that estimating a construction job is analagous
> to estimating a software project?
>
Don't recall saying I believed that, but estimates *can* be developed
for both kinds of projects.


>  The idea of abrogating risk because
> we've taken pains to write The Plan is a nice fantasy and makes for a
> pleasant fa�ade to present to management, but not much more.

Never heard that claim made, don't know where you got it.

>
> Careful not to construe my words as saying "plan-based approaches"
> cannot work.

Not a problem, you seem to be doing quite well on your own
in that regard.

> but the Much-Vaunted Models make the bad assumption
> -- to name only one -- that software people are more or less
> indistinguishable in terms of contribution.

I know this is a theme that comes up in XP literature, and it's
comforting, and creates a polarizing us vs. them vibe. The puzzling
thing is, over the many years that I've managed projects neither I nor
my peers ever said "Oh, I don't care, give me whoever." when staffing
projects teams. We all had our own "A" teams, our preferred folks for
various kinds of projects. We argued, cajoled, horse-traded to get the
people we wanted. And on more than one occasion, re-estimated projects
when we couldn't get the right people. So, yeah, I can see that you've
bought the XP party line in this area, it just doesn't match my experience
or training.

From your confusion of project planning, project scheduling and
risk management, I suspect you haven't had much exposure to
real, professional-grade project management. Which is too bad.

"Greg Bacon" <gbacon@hiwaay.net> wrote in message
news:108tk7e7buu2ge5@corp.supernews.com...
> In article <f_WdnfQFNdEBKxPdRVn-sQ@comcast.com>,
>     Scott Kinney <sakinney@ix.netcom.com> wrote:
>
> : "Phlip" <phlip_cpp@yahoo.com> wrote in message
> : news:Knyjc.12913$xl.4260@newssvr31.news.prodigy.com...
> :
> : > Then ... so what? I don't see how you think XP helps or hinders this
> : > out-of-band activity.
> :
> : It doesn't. You told a story where a new requirement resulted in
> : horrible disaster for a plan-driven approach. I told one where it
> : didn't.
>
> Yes, these scenarios have different impacts, but what are their relative
> frequencies?
>
> : [...]
> : Among long-time martial arts enthusiasts there's an inside joke:
> : whenever a style trumpets "We have this completely amazing technique!",
> : other styles respond "We have the same thing we just call it something
> : different." I see a lot of that in these discussions.
>
> Said another way: "There's nothing new under the sun."
>
> Can you provide some examples?  I haven't found another set of practices
> that matches XP's heavy emphasis on feedback and visibility.
>
Classical project management disciplines, as you'd find described
in the Project Management Institute's curriculum, or Boston University's.

"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0404271517.4ffe5c55@posting.google.com...

> If we 'document' (that is if we work out a design with documents) we
> may avoid the cost of writing code - we may prune that part of the
> design space without going to code. We explore the design using a
> "less costly" medium.

I am curious on your view here, how is it a less costly medium?

Regards
Shane

shanemingins@yahoo.com.duplication
remove duplication

----------------------------------------------------------------------------
------------
"Our thinking was wrong - but our tests were not.  Very interesting..." -
Ron Jefrries
----------------------------------------------------------------------------
------------

"Scott Kinney" <sakinney@ix.netcom.com> wrote in
news:FeadnQDyZNGAKRPdRVn-jg@comcast.com: 

> 
> "Otis Bricker" <obricker@my-dejanews.com> wrote in message
> news:Xns94D899DC2D9FAobrickermydejanewsco@216.196.97.136...
>> "Scott Kinney" <sakinney@ix.netcom.com> wrote in
>> news:PdmdnQ5sN8ukDBPdRVn-sw@comcast.com:
>>
>> >
>> > "Greg Bacon" <gbacon@hiwaay.net> wrote in message
>> > news:108t3qens049u30@corp.supernews.com...
>> >> In article <25udnWYzo-4aGBPdRVn-jw@comcast.com>,
>> >>     Scott Kinney <sakinney@ix.netcom.com> wrote:
>> >>
>> >> : [...]
>> >> :
>> >> : [Refactoring] is additional work, the cost of labor is greater
>> >> : than zero, .so...
>> >>
>> >> Additional relative to what?
>> >>
>> > Additional relative to work performed to implement the feature.
>> >
>> >
>>
>> But it is part of the work performed to implement the feature. And
>> future features.
>>
>> Labor Needed to implement feature with refactoring:
>> Gather Basic Requirments.
>> Modify Current Code/Design to allow addition of feature(Refactoring).
>> Code to implement feature To spec.
>> Modify Code/design to Expected Quality Level(Refactoring).
>>
> Thank you. At last a response that actually addresses my question!
> And makes sense at the same time.
> 
> 

Your welcome. 

I often feel as if we get lost in terminology. We all modify code to 
improve designs over time. We just don't always do it in the systematic 
style Fowler( or does the term predate his use?) dubbed refactoring.

On Tue, 27 Apr 2004 05:31:27 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>> month    revenue
>> 1           0
>> 2           0
>> 3           0
>> 4           0
>> 5           0
>> 6           0
>> 7           6000
>> 8           6000
>> 9           6000
>> 10         6000
>> 11         6000
>> 12         6000
>> 13         12000
>> total       48000 in 13 months
>>
>> If we deploy 1 feature every month, revenue looks like this:
>> 1           0
>> 2           1000
>> 3           2000
>> 4           3000
>> 5           4000
>> 6           5000
>> 7           6000
>> 8           7000
>> 9           8000
>> 10         9000
>> 11         10000
>> 12         11000
>> 13 12000
>> total       78000 in 13 months
>>
>> The same reasoning holds, less numerically, for any kind of value,
>> tangible or intangible, that the program may provide. Value sooner
>> increases ROI.
>>
>> Questions?
>>
>
>The simplifying assumption you made that each feature has a non-zero
>return was one place where I was having formulation difficulties.
>
>While a project as a whole has a return, it's not clear that all of
>its component features do. 

Yes. So let it be K features every month, such that the release has
some value. And note that value can be in dollar return from
deployment, or from learning, or any number of other benefits.

In any case, all you asked for was a clue on how it could be true, and
I trust you get the drift now, yes? Details and elaborations are
possible but the principle is, I hope, clear?

>Further, under the planning game, those
>with the highest perceived return are done first, and lesser returns
>later. That said, assuming uniform returns are the simplest assumption.

Yes, but that only make the advantage go more strongly to early
release.
>
>Another difficulty was the presence of end-users on the project
>team for its duration. The additional cost for their time should include
>an opportunity cost for their lost revenue while participating.

If there was an additional cost, one would take it into account. But
there might not be. And there are also advantages to having end users
present, which would also need to be considered.
>
>Finally, the cost of refactoring at the conclusion of the project
>increases the cost.

I don't refactor at the conclusion of the project. I refactor every
day.

My view is that the predictability and early release outweigh any
slowing down which //might// come from refactoring, and that in fact
an evolutionary approach to the development does not obviously take
any longer anyway.

In any case, it's just a simple model, showing that there is A LOT of
benefit to be had IF we can release incrementally. To me, this is
enough to suggest that we should look more deeply.

If you do a little simulation with unequal value on the features,
you'll quickly see that you can typically release well over half the
value in well under half the time. Thinking about that incents me to
find ways to do that -- and the rest of the agile practices fall out
of that one desire.
>
>How do you take these into account?

Roughly, at still the level of a simplified model, as above. Further
questions welcome, of course.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Tue, 27 Apr 2004 06:58:14 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>> If a feature as a non-positive value, why would you implement it?
>
>A feature  with no economic return may be required in order to support
>another
>feature with a higher return.

I would argue that this "never" occurs. Can you think of an example we
could kick around?

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Tue, 27 Apr 2004 06:58:14 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>> > Finally, the cost of refactoring at the conclusion of the project
>> > increases the cost.
>>
>> I guess you mean refactoring during the project - refactoring at the end
>> wouldn't make much sense.
>>
>OK, the cost of refactoring. It also increases the cost of the project and
>reduces the ROI.

That's not obvious. The cost of refactoring (a) isn't as high as
people imagine, and (b) is balanced by the cost of overdesign and
mis-design. Certainly all these costs, and many others, appear in the
real equation. Note, though, that in my little example, the difference
in project value after 13 months was 78,000 vs 48,000. We could buy a
lot of refactoring with what is nearly a 2/3 improvement in return.

Naturally, any real project is different from this model (and from any
other real project). What the numbers would do, ideally, is get people
thinking about the possibilities.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On Tue, 27 Apr 2004 10:44:51 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>>
>An infrastructure feature, say a particular level of security, is not, of
>itself
>profitable (does not generate revenue, does not reduce costs, in fact *is*
>an
>item of cost.), it's a 'sunk cost', but it may be necessary to support
>another
>feature that is profitable.
>
>This distinction is an artifact of breaking a project with many features
>that has a positive return overall, into many features. Some will have
>positive returns some will not.

Leaving out security will cost us millions. Therefore security has
high value.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On 27 Apr 2004 10:04:13 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Is there a //role// project manager?

Not defined in XP. Most projects have them, of course.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

> Paul Sinnett wrote:
>> In, The Paradox of Choice, Barry Schwartz describes an experiment 
>> where two groups of college students were asked to choose between a
>> variety of snacks during the break of three seminars (one a week 
>> for three weeks).

Isaac Gouy wrote:
> This is about "preferences". What the students really want is not to
> be hungry.

I don't know enough about the experiment to make that kind of judgement.
I couldn't find an online source for the it, but if you're interested in
following it up, the author of the article is here:

http://gobi.stanford.edu/facultybios/bio.asp?ID=153

The article is:

The Effect of Purchase Quantity and Timing on Variety-Seeking Behavior,
Journal of Marketing Research, May, 1990

On Tue, 27 Apr 2004 05:31:27 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:


>Finally, the cost of refactoring at the conclusion of the project
>increases the cost.

Refactoring is not done at the end of the project, it is done
throughout.  IMHO refactoring decreases the cost of the project
significantly.  Clean code is easier to change and maintain.


-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

Otis Bricker wrote:

> I often feel as if we get lost in terminology. We all modify code to 
> improve designs over time. We just don't always do it in the systematic 
> style Fowler( or does the term predate his use?) dubbed refactoring.

The first publication I'm aware of is William F. (Bill) Opdyke's PhD 
Thesis paper, "Refactoring Object-Oriented Frameworks" in 1992, 
University of Illinois at Urbana-Champaign. Also available as Technical 
Report UIUCDCS-R-92-1759, Department of Computer Science, University of 
Illinois at Urbana-Champaign.

I believe that Bill met Martin Fowler at OOPSLA '92 and that Bill was a 
contributor of the Refactoring book.

I wouldn't be surprised if the term was used before Bill's doctoral 
thesis, but I'm unaware of an earlier publication.

Also, yes, many people have often improved the design of sections of 
sourcecode over time, but simply rewriting code is not refactoring 
(lacking the systematic approach as you noted).

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Scott Kinney wrote:

> The broad range of responses in the thread indicates to me that no one
> actually knows if it's literally true, or rather actually has a model that
> demonstrates it. So it seems to be more of a wish or belief that it has
> a higher return on investment.

The best advice I have seen in this forum is to try it for yourself. 
Then, formulate your own opinion. From my experience, most people who 
have sincerely tried XP practices have come to the conclusion that 
defects go down and productivity goes up. It's not difficult to figure 
out how that results in better ROI.

With large research budgets, you could conduct extensive experiments and 
publish the actual results. If the research were done fairly, everyone 
here would be interested in those results. Unfortunately, the kind of 
money and/or resources necessary to do this type of research and 
eliminate other possible causes for differences in results is often 
unavailable. This has already recently been discussed in the "Irony" thread.

The simplest, most cost effective approach if you are interested but not 
convinced is to try out some of the practices if you are experiencing 
problems with your current practices. Since it's public knowledge that 
something like 75% of traditional software development projects have 
been considered failures, it's not very surprising that there are a lot 
of people asking whether or not they should consider new Agile 
practices, such as those that make up XP.

Sabre Airline Solutions embraced most of the XP practices and claims an 
increase in productivity of 42% and one-fifth the number of defects in 
their largest software product. These results have been posted to this 
newsgroup before. You can check out the ComputerWorld article at: 
http://www.computerworld.com/softwaretopics/software/story/0,10801,91646,00.html

Personally, my company has been able to commit to tight deadlines 
working less hours than we would have using a traditional plan-driven 
approach. In traditional tight-deadline projects, the hours worked per 
developer would steadily increase as a tight deadline approached. Using 
XP practices, the hours worked per developer remained flat, even with 
all sorts of other usually risky project elements (buggy existing code, 
variables written in multiple unfamiliar foreign languages, etc.).

In fact, with a traditional plan-driven approach we could never have 
committed to the project in the first place. I've done enough 
traditional plan-driven projects to be quite confident that we could not 
have done this. There would not have been enough time to gather all of 
the requirements up front, then do a full detailed design document, then 
produce the code and test and debug it. Not to mention integration with 
existing code. Not to mention fixing a number of bugs in the existing 
code. Not to mention a bunch of "Oh by the way, we also need..." changes 
to the scope.

The deadline for delivering working, tested code was 2 months from the 
start of the project. We completed it and the most hours anyone put in 
was between 40 and 50, and only in the last week of the final release. 
And, in the process we improved the design of some of the existing code, 
plus built a suite of automated Unit Tests, plus started a couple of 
automated Acceptance Tests, plus fixed some bugs that had remained 
unfixed for 7 years. Plus, ...

So for my company, a traditional plan-driven approach would have 
resulted in a return of $0, no matter how much we invested. An XP-based 
approach resulted in a much larger than $0 return with a fairly fixed 
investment. That's the most conclusive evidence I would ever expect to 
get. You can do the math.

To me, the results I have personally seen are //literally// impressive. 
The results published by Sabre are //literally// impressive.

But, don't take my word for it, or anyone else's. Try it out for 
yourself. Or, don't. It's up to you. If you will not try XP until 
someone proves beyond a shadow of a doubt that XP is more efficient, or 
XP is more cost-effective, or XP is more... then please don't use XP. 
There is currently no conclusive proof when it comes to what software 
process is the most efficient, or most cost effective, or most... 
Software projects are all different, with different objectives. 
Meanwhile, most of the people in this newsgroup seem to be more than 
satisfied with the resutls we've seen.

If you feel that it should be possible to definitively proove that one 
process is more efficient or cost effective than another, then please 
proove that a traditional, plan-drive approach is more cost-effective 
than XP and get back to us.

Nobody here is telling you that you *must not* use traditional 
plan-driven project management. Nobody here is telling you that it is 
*impossible* to successfully deliver software projects using traditional 
approaches (something like 25% of traditional projects have 
statistically been considered successful).

This "requirements misalignment" thread was spawned by you out of the 
"Irony" sub-thread which is basically about an article that states why 
XP *cannot work*. If that's the case, then I'm happy to be achieving the 
impossible every day.

If you have *questions* about how XP practices work, or how to adopt 
Agile processes in general, I think most of the people in this newsgroup 
(myself included) would be more than happy to answer them.

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Scott Kinney wrote:

> Help me understand why refactoring decreases the cost of the project.
>
> It is additional work, the cost of labor is greater than zero, .so...

It significantly reduces future work.

Cheers, Ilja

Ron,

> >> If a feature as a non-positive value, why would you implement it?
> >
> >A feature  with no economic return may be required in order to support
> >another
> >feature with a higher return.
>
> I would argue that this "never" occurs. Can you think of an example we
> could kick around?

Here is one, although I can already hear the symatic arguments about value.
Anyway -- In general, any architectural refactoring that paves the way for
user features is such an example.  Here is an example, we just spent a
gazillion dollars to increase the total number of object-pointers available
in our object-oriented database product.  There is no immediate economic
return on this feature.  In and of itself, we can consider this enhancement
as paving the way to be able to calculate more things and provide more
features to the user in future releases.  It may also sustain additional
growth, but this value will be determined by market conditions and not by
the software.

Regards,

Randy

Bob,

> >Finally, the cost of refactoring at the conclusion of the project
> >increases the cost.
>
> Refactoring is not done at the end of the project, it is done
> throughout.  IMHO refactoring decreases the cost of the project
> significantly.  Clean code is easier to change and maintain.

It all depends.  If the code does not need to change, then refactoring it
will increase the cost.  If the code needs to be refactored a different way,
chances are that at least 50% of the money spent on the first refactoring
will be wasted.  I am not speaking against clean code.  I am saying that
clean code is not free; and only those team's who have good enough
developers who make good refactoring decisions better than 50% of the time
will likely achieve a decreased cost of the project.  I am saying that money
spent to refactor code to say it was refactored is wasted money and
increases the cost of the project.  Money spent refactoring code one way,
only to find out it needs to be refactored another way usually increases the
cost of the project.

Regards,

Randy

On Wed, 28 Apr 2004 02:25:56 -0600, "Randy A. Ynchausti"
<randy_ynchausti@msn.com> wrote:

>> >Finally, the cost of refactoring at the conclusion of the project
>> >increases the cost.
>>
>> Refactoring is not done at the end of the project, it is done
>> throughout.  IMHO refactoring decreases the cost of the project
>> significantly.  Clean code is easier to change and maintain.
>
>It all depends.  If the code does not need to change, then refactoring it
>will increase the cost.  

If the code doesn't need to change, no one is suggesting changing it.
Does the code need to be /clean/? I would argue that it does, and that
making it clean is part of the initial job that we all should be doing
whatever our approach. I see below that we probably agree on that.

Does it need to be more general or otherwise have its design changed?
Not in anticipation of some future need -- I'd wait until the need
arises.

>If the code needs to be refactored a different way,
>chances are that at least 50% of the money spent on the first refactoring
>will be wasted.  

This turns out not to be the case in my experience. In my experience,
refactoring consists mostly in moving things around, not rewriting,
and it's not all that costly. With good refactoring tools, it's a
breeze!

>I am not speaking against clean code.  I am saying that
>clean code is not free; and only those team's who have good enough
>developers who make good refactoring decisions better than 50% of the time
>will likely achieve a decreased cost of the project.  

It is tautological that only those teams who are good enough will be
able to do well. If they aren't good enough, no other process will
help them either.

>I am saying that money
>spent to refactor code to say it was refactored is wasted money and
>increases the cost of the project. 

As far as I know, no one is recommending refactoring for the fun of
it. XP teams are focused on user stories. Long refactoring jags are
inappropriate. Even if a big refactoring is /necessary/, it is
evidence of some simpler refactoring that was missed earlier on. Your
example of the gazillion dollars spent stretching a pointer might be
such an example. There was almost certainly a day when that change
would have been easy to make. But who knew that a couple of billion
pionters weren't enough? No one. Who knew that encapsulating that
decision in an object might be important? I guess no one, wo it sounds
like big design didn't help much either.

> Money spent refactoring code one way,
>only to find out it needs to be refactored another way usually increases the
>cost of the project.

This turns out not to be the case in my experience. I'm gathering from
the other folks who are posting to the topic that it isn't the case in
their experience either. If you're talking from experience, my guess
is that we're not all doing the same things. Should we explore the
differences?

Regards,

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

In article <BfudnWHpzpyOfhPdRVn-ig@comcast.com>,
    Scott Kinney <sakinney@ix.netcom.com> wrote:

: Actually, that wasn't what we were talking about. Bob was using the
: analogy to support Ron's revenue stream of $1000 per month in project
: 'return' being worth more than quarterly payments, or biannual
: payments or annual payments.

I believe you've misunderstood what Ron wrote.  He was talking about
value that the customer derives from the delivered software, not
payments from the customer to the developer.

Greg
-- 
Life, liberty, and property do not exist because men have made laws.  On the
contrary, it was the fact that life, liberty, and property existed beforehand
that caused men to make laws in the first place.
    -- Frederic Bastiat, *The Law*

"Shane Mingins" <shanemingins@yahoo.com.clothes> wrote in message news:<408ef03a$1@news.iconz.co.nz>...

> > If we 'document' (that is if we work out a design with documents) we
> > may avoid the cost of writing code - we may prune that part of the
> > design space without going to code. We explore the design using a
> > "less costly" medium.
> 
> I am curious on your view here, how is it a less costly medium?

I was quoting from Ron's posting: "(where documenting may be less costly)"

In article <84SdnXNGTMDKcBPd4p2dnA@comcast.com>,
    Scott Kinney <sakinney@ix.netcom.com> wrote:

: "Greg Bacon" <gbacon@hiwaay.net> wrote in message
: news:108tk7e7buu2ge5@corp.supernews.com...
:
: > In article <f_WdnfQFNdEBKxPdRVn-sQ@comcast.com>,
: >     Scott Kinney <sakinney@ix.netcom.com> wrote:
: >
: > : It doesn't. You told a story where a new requirement resulted in
: > : horrible disaster for a plan-driven approach. I told one where it
: > : didn't.
: >
: > Yes, these scenarios have different impacts, but what are their
: > relative frequencies?
: [...]

No answer?  You come in chiding people about not using econometrics,
but you don't seem to be able to provide your own.

This discussion has turned political, complete with name calling and "Is
not! Is too!"  Later in your post, you tried to brush off my request for
specific examples by merely invoking classical project management.

Are you interested in a technical discussion or not?

Greg
-- 
My son, I give thee now a valuable parcel of land; I assure you I have found
a considerable quantity of gold by digging there. Thee mayest do the same:
but thee must carefully observe this, never dig more than a plough deep.
    -- Ben Franklin

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<hbvt8016m43h0aeie6pi819dthuntgl2bq@4ax.com>...
> On 27 Apr 2004 10:04:13 -0700, igouy@yahoo.com (Isaac Gouy) wrote:
> 
> >Is there a //role// project manager?
> 
> Not defined in XP. Most projects have them, of course.

So how do the XP team work with the PM?

"Greg Bacon" <gbacon@hiwaay.net> wrote in message
news:108vaofq2ppdkf8@corp.supernews.com...
> In article <84SdnXNGTMDKcBPd4p2dnA@comcast.com>,
>     Scott Kinney <sakinney@ix.netcom.com> wrote:
>
> : "Greg Bacon" <gbacon@hiwaay.net> wrote in message
> : news:108tk7e7buu2ge5@corp.supernews.com...
> :
> : > In article <f_WdnfQFNdEBKxPdRVn-sQ@comcast.com>,
> : >     Scott Kinney <sakinney@ix.netcom.com> wrote:
> : >
> : > : It doesn't. You told a story where a new requirement resulted in
> : > : horrible disaster for a plan-driven approach. I told one where it
> : > : didn't.
> : >
> : > Yes, these scenarios have different impacts, but what are their
> : > relative frequencies?
> : [...]
>
> No answer?  You come in chiding people about not using econometrics,
> but you don't seem to be able to provide your own.
>

I haven't 'chided' people for not using econometrics, only for not
being able explain their own.

I can, and have modelled the NPV and IRR for plan-driven projects.
The reason for my initial question on how to formulate that model for
XP was that, all other things being equal, was that quarterly releases
offered a rate of return pretty close to that of monthly releases.

Attempting to validate that result, I asked for base assumptions and cost
components so a side-by-side comparison would be possible.

That said, your specific distaste for quantititative modelling is fairly
obvious,
so there's little point in discussing it with you.

As to the relative frequencies question: over what universe of projects?
Mine,
all I've ever worked on, all I've ever studied, or all projects everywhere?
And to what
result? Any examples I offer of effective change management (ie,
non-disruptive)
will be countered by you with examples (or more likely flat assertions) of
changes that
disrupted a project. So what?

> This discussion has turned political, complete with name calling and "Is
> not! Is too!"  Later in your post, you tried to brush off my request for
> specific examples by merely invoking classical project management.
>
> Are you interested in a technical discussion or not?

It wasn't a brush off, you asked me for a methodology with a
heavy emphasis on feedback and visibility. I named one.

If you'd like a technical discussion on how feedback
and visibvility are achieved in classical project management,
you'll have to be more specific. Do you mean in the domain of
Scope Management
Quality Management
Time Management
Cost Management
Risk Management
Human Resource Management
Procurement Management
or
Communications Management?

"Greg Bacon" <gbacon@hiwaay.net> wrote in message
news:108v9g7mdikpf4d@corp.supernews.com...
> In article <BfudnWHpzpyOfhPdRVn-ig@comcast.com>,
>     Scott Kinney <sakinney@ix.netcom.com> wrote:
>
> : Actually, that wasn't what we were talking about. Bob was using the
> : analogy to support Ron's revenue stream of $1000 per month in project
> : 'return' being worth more than quarterly payments, or biannual
> : payments or annual payments.
>
> I believe you've misunderstood what Ron wrote.  He was talking about
> value that the customer derives from the delivered software, not
> payments from the customer to the developer.
>
>
No, I understood that he meant the financial return (or additional revenue
less costs) from the delivered software.

Randy A. Ynchausti wrote:

> Bob,
> 
>>>Finally, the cost of refactoring at the conclusion of the project
>>>increases the cost.
>>
>>Refactoring is not done at the end of the project, it is done
>>throughout.  IMHO refactoring decreases the cost of the project
>>significantly.  Clean code is easier to change and maintain.
> 
> It all depends.  If the code does not need to change, then refactoring it
> will increase the cost.  If the code needs to be refactored a different way,

If I do not need to change the code for any reason, then I do not 
refactor it either.

> chances are that at least 50% of the money spent on the first refactoring
> will be wasted.  I am not speaking against clean code.  I am saying that
> clean code is not free; and only those team's who have good enough
> developers who make good refactoring decisions better than 50% of the time
> will likely achieve a decreased cost of the project.  I am saying that money

First of all, refactoring should involve very small steps, not wholesale 
rewriting. With adequate tools, you can work even faster, but if done 
correctly, refactoring tools are not absolutely required to work 
efficiently.

Secondly, in TDD I see two very common instances of refactoring. In both 
cases, the refactoring pays for itself.

1) In TDD, refactoring often occurs at the end of the following sequence:
Add a test that fails, get the test to pass (green bar), then refactor.

In this sequence, I am trying to get the test to pass in short order. I 
don't worry about introducing a small amount of duplication, or 
committing some other //sin//. Just after getting the test to pass, I 
then eliminate that duplication, or clean up whatever small //sin// I've 
committed.

Because I'm working in small steps, getting to a green bar plus the 
small amount of refactoring take no more time than just sitting down and 
writing that code cleanly and correctly (in fact even less, but see below).

2) At other times in a project, I will look at some functionality that I 
need to add. It is quite common to refactor the code just prior to 
adding this new functionality. The reason is to make the design of the 
code better to make it easier to add the new functionality. Because I am 
refactoring in small steps, the refactoring cost most likely pays for 
itself by the savings in time adding the new functionality.

> spent to refactor code to say it was refactored is wasted money and
> increases the cost of the project.  Money spent refactoring code one way,
> only to find out it needs to be refactored another way usually increases the
> cost of the project.

No, I don't find this to be the case at all. If some new functionality 
is required that wasn't in the previous list of User Stories, 
refactoring makes it easier to implement the new functionality. Again, 
this refactoring pays for itself very quickly when done in small steps. 
Compare this to wedging in the functionality in a design that really 
doesn't allow for that possibility. We've all seen what that type of 
code looks like. It's expensive to write and even more expensive to 
maintain.

> Regards,
> 
> Randy

IMHO, the real time savings from TDD occurs as a result of less 
debugging, troubleshooting and wondering about the code. This is due to 
the fact that with TDD, you are building a suite of automated Unit Tests 
as part of the process of writing the code. Again, working in small 
steps, the activity of writing Unit Tests (that are small) does not take 
much time. And, writing the tests first results in cleaner code that is 
testable and less tightly coupled to begin with.

So, by itself Refactoring may not offer you as much of a benefit in time 
savings, but it doesn't cost much (if anything). In the context of TDD, 
there are huge time savings as a result of not having to do a lot of 
debugging, troubleshooting, and wondering why some bug is happening, or 
some new feature doesn't quite work as expected, or debating the 
ramifications of larger design changes (work in smaller, more obvious 
steps), or ...

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Isaac Gouy wrote:

> "Shane Mingins" <shanemingins@yahoo.com.clothes> wrote in message news:<408ef03a$1@news.iconz.co.nz>...
> 
> 
>>>If we 'document' (that is if we work out a design with documents) we
>>>may avoid the cost of writing code - we may prune that part of the
>>>design space without going to code. We explore the design using a
>>>"less costly" medium.
>>
>>I am curious on your view here, how is it a less costly medium?
> 
> I was quoting from Ron's posting: "(where documenting may be less costly)"

Well, Ron said "may be". You indicate that you *are* "using a 'less 
costly' medium". Do you have some proof of this?

What proof is there that changing a line of text in a design document is 
less costly than changing a line of text in source code? Why should 
changing text in one place necessarily be less costly than changing text 
in another? Source code is a type of document, isn't it? It is intended 
to be human readable isn't it?

If your source code is not very human readable, we'd be happy to discuss 
ways to make it more so :)

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Jason Nocks <nocksj@sourcextreme.com> wrote in message news:<3a622$408fc40b$cff54506$31982@dcanet.allthenewsgroups.com>...

> >>>If we 'document' (that is if we work out a design with documents) we
> >>>may avoid the cost of writing code - we may prune that part of the
> >>>design space without going to code. We explore the design using a
> >>>"less costly" medium.
> >>
> >>I am curious on your view here, how is it a less costly medium?
> > 
> > I was quoting from Ron's posting: "(where documenting may be less costly)"
> 
> Well, Ron said "may be". You indicate that you *are* "using a 'less 
> costly' medium". 

Reading, like listening, is difficult.
Who does "we" refer to in "we may avoid the..."? 
Who does "we" refer to in "we may prune that..."? 
Who does "We" refer to in "We explore the design..."?

gbacon@hiwaay.net (Greg Bacon) wrote in message news:<108tk7e7buu2ge5@corp.supernews.com>...

> : Among long-time martial arts enthusiasts there's an inside joke:
> : whenever a style trumpets "We have this completely amazing technique!",
> : other styles respond "We have the same thing we just call it something
> : different." I see a lot of that in these discussions.
> 
> Said another way: "There's nothing new under the sun."

IMO knowing what's new and what's the same is more useful than that
implies. Pair programming isn't *new* to Ward Cunningham and Kent
Beck, but it seems reasonable to claim that the emphasis XP places on
pair programming is new. Incremental development isn't *new* to a
larger group of developers.

> Can you provide some examples?  I haven't found another set of practices
> that matches XP's heavy emphasis on feedback and visibility.

Feedback of what to whom?
Visibility of what to whom?

On Wed, 28 Apr 2004 10:10:12 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:

>"Greg Bacon" <gbacon@hiwaay.net> wrote in message
>news:108v9g7mdikpf4d@corp.supernews.com...
>> In article <BfudnWHpzpyOfhPdRVn-ig@comcast.com>,
>>     Scott Kinney <sakinney@ix.netcom.com> wrote:
>>
>> : Actually, that wasn't what we were talking about. Bob was using the
>> : analogy to support Ron's revenue stream of $1000 per month in project
>> : 'return' being worth more than quarterly payments, or biannual
>> : payments or annual payments.
>>
>> I believe you've misunderstood what Ron wrote.  He was talking about
>> value that the customer derives from the delivered software, not
>> payments from the customer to the developer.
>>
>>
>No, I understood that he meant the financial return (or additional revenue
>less costs) from the delivered software.

I believe that I made the point that the reasoning works for any form
of return, tangible and intangible. Whatever you value, the sooner you
deliver it, the better you do, ceteris paribus. 

So then one factors in whether one thinks one goes faster, with simple
design + refactoring, or slower. I know the answer for me, and for
enough other people to think it's worth learning the techniques. But
everyone's mileage varies.

Regards,

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

On 28 Apr 2004 06:38:01 -0700, igouy@yahoo.com (Isaac Gouy) wrote:

>Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<hbvt8016m43h0aeie6pi819dthuntgl2bq@4ax.com>...
>> On 27 Apr 2004 10:04:13 -0700, igouy@yahoo.com (Isaac Gouy) wrote:
>> 
>> >Is there a //role// project manager?
>> 
>> Not defined in XP. Most projects have them, of course.
>
>So how do the XP team work with the PM?

Release plan, iteration plan, burndown. More information than most PMs
ever had before about a software project.

-- 
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Scott:

> I can, and have modelled the NPV and IRR for plan-driven projects.
> The reason for my initial question on how to formulate that model for
> XP was that, all other things being equal, was that quarterly releases
> offered a rate of return pretty close to that of monthly releases.

The following link might be of interest - I won't pretend I have read
or understood all of it, I lack the background to make it a quick read,
but it's very probably on-topic:

  http://sern.ucalgary.ca/courses/SENG/693/F00/readings/Erdogmus/XPOptionsPaper.pdf

Laurent
http://bossavit.com/thoughts/

Isaac:

> If we 'document' (that is if we work out a design with documents) we
> may avoid the cost of writing code - we may prune that part of the
> design space without going to code. We explore the design using a
> "less costly" medium.

Yes, given the assumption that text (*) is a less costly medium than 
code.

That assumption seems pretty shaky to me, since producing text requires 
more or less the same types of activities as producing code. (Thinking, 
typing, talking.)

More accurately, we may say that the source code to a system /is/ a text 
(in the lit crit sense of the term "text"). It is a text which documents 
a design.

I might be missing a good reason to assume that documentation is a "less 
costly" medium than code ?

(*) Non-text forms of documentation are generally more costly to produce 
than text, as can be demonstrated by comparing the salaries of 
secretaries vs. draftsmen, audio engineers, etc. So if text forms of 
documentation cost the same, or more, as documentation, the assumption 
falls for "documentation" in general.

Laurent
http://bossavit.com/thoughts/

Thanks Laurent, it's an interesting article. It raises  points
that may be beyond this thread to discuss; estimating the
$ value of individual features, and packaging features such
that the value of the feature remains if the rest of the project is
cancelled.


"Laurent Bossavit" <laurent@dontspambossavit.com> wrote in message
news:MPG.1afa3f567979b329989767@news.noos.fr...
> Scott:
>
> > I can, and have modelled the NPV and IRR for plan-driven projects.
> > The reason for my initial question on how to formulate that model for
> > XP was that, all other things being equal, was that quarterly releases
> > offered a rate of return pretty close to that of monthly releases.
>
> The following link might be of interest - I won't pretend I have read
> or understood all of it, I lack the background to make it a quick read,
> but it's very probably on-topic:
>
>
http://sern.ucalgary.ca/courses/SENG/693/F00/readings/Erdogmus/XPOptionsPaper.pdf
>
> Laurent
> http://bossavit.com/thoughts/

Isaac Gouy wrote:

> Jason Nocks <nocksj@sourcextreme.com> wrote in message news:<3a622$408fc40b$cff54506$31982@dcanet.allthenewsgroups.com>...
> 
>>>>>If we 'document' (that is if we work out a design with documents) we
>>>>>may avoid the cost of writing code - we may prune that part of the
>>>>>design space without going to code. We explore the design using a
>>>>>"less costly" medium.
>>>>
>>>>I am curious on your view here, how is it a less costly medium?
>>>
>>>I was quoting from Ron's posting: "(where documenting may be less costly)"
>>
>>Well, Ron said "may be". You indicate that you *are* "using a 'less 
>>costly' medium". 
> 
> Reading, like listening, is difficult.

And can be made even more difficult by not being very forthcoming.

> Who does "we" refer to in "we may avoid the..."? 
> Who does "we" refer to in "we may prune that..."? 
> Who does "We" refer to in "We explore the design..."?

Why so cryptic?

//You// wrote the comments. Why don't //you// tell me what collective 
"we" you were referring to.

And what does this question of "we" have to do with the questions I posted?

Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/

Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<5s7090dt9q4v1es5vip5otajikcvol6ora@4ax.com>...

> >> >Is there a //role// project manager?
> >> 
> >> Not defined in XP. Most projects have them, of course.
> >
> >So how do the XP team work with the PM?
> 
> Release plan, iteration plan, burndown. More information than most PMs
> ever had before about a software project.

What role is the PM playing - another incarnation of the //customer// role?

Jason Nocks <nocksj@sourcextreme.com> wrote in message news:<60524$4090450a$cff54506$3687@dcanet.allthenewsgroups.com>...

> And what does this question of "we" have to do with the questions I posted?

"You indicate that you *are* "using a 'less costly' medium". Do you
have some proof of this?"

The question is based on a misreading.
I did not indicate that I use anything.

Writing is difficult, but the ambiguity and contextual slop of
language places most burden on the reader.

Laurent Bossavit <laurent@dontspambossavit.com> wrote in message news:<MPG.1afa41ac39f2d643989768@news.noos.fr>...

> That assumption seems pretty shaky to me, since producing text requires 
> more or less the same types of activities as producing code. (Thinking, 
> typing, talking.)
> 
> More accurately, we may say that the source code to a system /is/ a text 
> (in the lit crit sense of the term "text"). It is a text which documents 
> a design.
> 
> I might be missing a good reason to assume that documentation is a "less 
> costly" medium than code ?

We probably don't know what we're talking about ;-)

Assuming we do design at many levels of abstraction, is too concrete
for high-level design?

Scott Kinney wrote:
> "Ilja Preu�" <preuss@disy.net> wrote in message
> news:c6lvfg$67d$1@stu1id2.ip.tesion.net...
>> Scott Kinney wrote:
>>
>>> An infrastructure feature, say a particular level of security, is
>>> not, of itself
>>> profitable (does not generate revenue, does not reduce costs, in
>>> fact *is* an item of cost.), it's a 'sunk cost', but it may be
>>> necessary to support another feature that is profitable.
>>
>> How do you determine which one of the features has the value and
>> which does not?
>>
> By performing an economic, or cost benefit estimate of the features.

What would that look like for the example above?

>>> This distinction is an artifact of breaking a project with many
>>> features that has a positive return overall, into many features.
>>> Some will have positive returns some will not.
>>
>> Well, perhaps the art is to break a project into features so that
>> every feature *does* have a positive value. Perhaps, infrastructure
>> isn't a feature at all...
>
> Perhaps it isn't, perhaps it is.

Am I understanding you correctly that you are not interested in exploring
this idea?

> If a frog had wings he wouldn't bump
> his ass quite so much...

Yeah - but probably wouldn't call giving a frog wings an art... :eek: ;)

Take care, Ilja