Estimating Costs Up Front
Corey Burnett
businesses. Our customers always want to know how much a project is
going to cost and how long it's going to take before they will sign up
for the project. Our current approach is to get them to pay for a
lengthy requirements analysis effort first. This seems to be the "big
design up front" methodology. I am interested how XP would tackle
this. What I have read about XP seems to infer that the design is
more fluid and happening throughout the development cycles. If that
is the case then how in the world would I accurately estimate the
entire project before starting and give a fixed price estimate?
Our current process involves a mini requirements project first.
Basically the customer pays us for about 100 hours worth of work to
define the project and produce a requirements document (big design up
front). For their money they get a nice requirements document that
they could shop around if they want and they also get a FIXED price
cost for what it would take for us to do the project. At that point
they could decide not to do the project, scale it back, or shop it
around.
I really like the idea of a more agile process that would adapt to
change better, involve the customer more, help the customer understand
the system better, etc. But our customers don't want to write blank
checks either. So how do you accurately estimate the cost of the
project up front using XP? And if I could get a customer to sign up
for some sort of XP design/estimation phase what would the
output/deliverable be that they would be paying for in the case where
they decide not to go forward with the project?
Thanks - interested in any and all opinions/thoughts.
Corey
John Roth
"Corey Burnett" <thebu...@yahoo.com> wrote in message
news:73447641.04092...@posting.google.com...
I'd do "just enough" of a requirements process to define the
project to the customer's satisfaction and get an estimate you
(and they) can live with.
The key question to ask before filling anything out in
the up front requirements document is: "who needs it
when?" If it's not needed by either the estimating
team or the customer before signing the contract,
you don't need to research it and put it in the
document.
The resulting requirements document is going to look like
a list of XP style stories, with an estimate for each story.
If you want more formality, you might associate each
story with a specific use case, where the story is one
scenario, or a data or technology extension to a scenario.
In either case, you wouldn't actually write the rest of the
use cases until it came time to do the work.
John Roth
>
> Corey
Corey Burnett
> I'd do "just enough" of a requirements process to define the
> project to the customer's satisfaction and get an estimate you
> (and they) can live with.
>
> The key question to ask before filling anything out in
> the up front requirements document is: "who needs it
> when?" If it's not needed by either the estimating
> team or the customer before signing the contract,
> you don't need to research it and put it in the
> document.
>
> The resulting requirements document is going to look like
> a list of XP style stories, with an estimate for each story.
> If you want more formality, you might associate each
> story with a specific use case, where the story is one
> scenario, or a data or technology extension to a scenario.
> In either case, you wouldn't actually write the rest of the
> use cases until it came time to do the work.
>
> John Roth
Thanks. Are we nuts to try and do our projects for a fixed price? XP
seems to be all about adapting to change well and not forcing the
customer to tell us *everything* up front. If we use XP, my fear is
that we are fixing the price up front but not fixing the requirements
up front - which could spell disaster for us. If we don't do it fixed
price then what are the alternatives? None of our customers want to
do a "time and materials" project because it seems like they are
writing a blank check.
Thanks again,
Corey
Anthony Williams
> Thanks. Are we nuts to try and do our projects for a fixed price? XP
> seems to be all about adapting to change well and not forcing the
> customer to tell us *everything* up front. If we use XP, my fear is
> that we are fixing the price up front but not fixing the requirements
> up front - which could spell disaster for us. If we don't do it fixed
> price then what are the alternatives? None of our customers want to
> do a "time and materials" project because it seems like they are
> writing a blank check.
You could do fixed price, variable scope --- "we estimate that what you're
asking will take about N months. If you hire us for N months, for X pounds,
we'll ship you completed features every few weeks. We'll focus on what you
decide is highest priority, and you can tell us any time if a requirement
changes or you think of a new one. We'll keep you posted with up-to-date
estimates of outstanding work. If you're not happy with our progress, or
you've got all the features you need before N months is up, you can terminate
the contract."
Not that I've ever been in a situation to try it....
Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
John Roth
You do the same thing most other projects do: charge an arm and
both legs for changes. (Whether you get a lien on the first-born
daughter is domain specific.)
The fact is, any project of any significant size is going to have
requirements changes midstream. You need to have an agreement
as to how these will be handled. Agile lets you handle them at
less cost than most other methodologies, but they can't be
invisible.
John Roth
>
> Thanks again,
> Corey
Laurent Bossavit
> For their money they get a nice requirements document that
> they could shop around if they want and they also get a FIXED price
> cost for what it would take for us to do the project. At that point
> they could decide not to do the project, scale it back, or shop it
> around.
How often does each of those actually happen ?
Laurent
Vladimir Levin
to both the duration and the features of the project. If you can get the
customers to agree that some features may have to be left behind or slimmed
down in terms of their scope, then fixed cost is ok. Otherwise, time (and
presumably) cost may vary. I would estimate a project based on a) How long
similar projects I've done took, and b) Estimating an initial list of known
requirements. Then I would add some padding to reduce risk of failure.
I think doing a fixed price project in an agile way would be tough because
it would be hard to accomodate any changes in requirements as you go along.
In general, I would only agree to a fixed price contract if I was well
acquainted with the customer and the business domain, and felt in general
that the project was not a high risk of requiring more resources. Also,
I guess I would have to be willing to eat a potential loss if I could not
meet my agreed-upon commitments within the specified cost. Sometimes that
may be worth it if the customer has good potential for future work.
thebu...@yahoo.com (Corey Burnett) wrote in message news:<73447641.04092...@posting.google.com>...
Corey Burnett
> You do the same thing most other projects do: charge an arm and
> both legs for changes. (Whether you get a lien on the first-born
> daughter is domain specific.)
>
> The fact is, any project of any significant size is going to have
> requirements changes midstream. You need to have an agreement
> as to how these will be handled. Agile lets you handle them at
> less cost than most other methodologies, but they can't be
> invisible.
>
> John Roth
But I still feel like XP does not address the initial up front process
of telling the customer about how much it's going to cost and about
how long it's going to take (within some reasonable percentage). The
XP process as I have read it seems to say that the developers do not
provide estimates for implementing the individual user stories until
just before they begin programming and that this happens in every
phase. Let's say that I have 50 User Stories defined and they
naturally break up into 10 seperate modules with 5 stories per module.
It seems to me like XP would tell you to only estimate the first 5
stories, then program the first phase and then release the
application. Then repeat again for phase 2, etc. There doesn't seem
to be a step in the beginning of estimating the entire project - you
only seem to ever estimate the next step in the process. Our dilemma
is this: how do I get an accurate estimate for the whole project
without getting a ton of detail up front? XP seems to want me to get
just a little detail up front and then flesh it out as I go. That's
great for me the software developer - but stinks for my customers. Am
I missing something as to how XP estimation works? Or is estimation
beyond the scope of what XP is designed to do?
Corey
Jackson
Corey Burnett wrote:
> Am I missing something as to how XP estimation works? Or is estimation
> beyond the scope of what XP is designed to do?
I don't think you are missing anything. XP doesn't help you
when you need to make early decisions about things that will
happen later. That includes cost, sizing for hardware, reliability,
performance, etc. It also has no component to help the
customer come up the detail for the planning game.
This isn't necessarily bad. There is great help when
you get to the coding part.
It may be there's no help because it is really hard to do
and there are no obvious answers.
You can look COCOMO II and the like for help. But in the end i think
maybe a JAD session where you puzzle things out to the
depth you need to feel comfortable with your estimates.
If this is a new domain for you then you are clearly
at great risk. The good part is this data will feed nicely
into the planning game.
Laurent Bossavit
> Let's say that I have 50 User Stories defined and they
> naturally break up into 10 seperate modules with 5 stories per module.
> It seems to me like XP would tell you to only estimate the first 5
> stories, then program the first phase and then release the
> application.
That's not correct. The canonical descriptions of XP suggest that you
estimate all 50 stories. Once you have completed the first iteration,
you obtain an estimate of the project's overall duration by dividing the
sum of estimates for all 50 stories into the sum of estimates for all
the stories that got done in that iteration.
Thus, you obtain a whole-project estimate - a rather accurate one, since
it takes into account the real productivity of the actual team that's
working on the project, as opposed to some guesstimate of that measure -
for the cost of one iteration.
Jackson
Laurent Bossavit wrote:
> Thus, you obtain a whole-project estimate - a rather accurate one, since
> it takes into account the real productivity of the actual team that's
> working on the project, as opposed to some guesstimate of that measure -
> for the cost of one iteration.
How can one believe in the principles of change and be against
BFUD and at the same time think your whole project estimates
created at the beginning of the project will mean anything?
You will be discovering a lot about your system as you
go on and that needs to be fed back. You can't just move BFUD
to a different place in the process and say BFUD works
for planning but not for code.
John Roth
"Jackson" <sp...@spam.com> wrote in message
news:10l6gcl...@news.supernews.com...
The issue here is how much requirements analysis you're
doing. Traditional development says you need to do *all*
of the requirements up front. XP says you only need to do
what's required for the immediate purpose: that is,
planning. You can defer the detail until the developers
need it.
XP puts everyone in a room (the Planning Game) and
comes out of that room with a list of stories and estimates.
Based on that, you may decided the project isn't worth
doing, or you may decide to go for a few iterations to
get a realistic estimate of velocity (and find out if there
were any major issues not covered - it happens.)
That's XP's up front process, and you (or someone
in this thread) is absolutely correct that the Planning
Game itself doesn't give you a time and cost estimate
unless you pull a velocity estimate out of your back
pocket.
On the other hand, any seasoned consulting
company knows how to do this, and they know
the risks inherent in estimating a process they don't
have sufficient experience with.
John Roth
Jackson
> John Roth wrote:
> That's XP's up front process, and you (or someone
> in this thread) is absolutely correct that the Planning
> Game itself doesn't give you a time and cost estimate
> unless you pull a velocity estimate out of your back
> pocket.
The planning game pretty much assumes you got funding
for a project because you have all the people to run
through the game. You would need these people to get
the estimates. Yet to fund a project you would need
the estimates so you could get funding. Catch 22.
In any case your data prior to the planning game
is likely to be poor for the same reasons BFUD
is disliked. Any plan based on this process is
therefor suspect which makes your resulting
predictions suspect.
John Roth
>
>
> > John Roth wrote:
>> That's XP's up front process, and you (or someone
>> in this thread) is absolutely correct that the Planning
>> Game itself doesn't give you a time and cost estimate
>> unless you pull a velocity estimate out of your back
>> pocket.
>
> The planning game pretty much assumes you got funding
> for a project because you have all the people to run
> through the game. You would need these people to get
> the estimates. Yet to fund a project you would need
> the estimates so you could get funding. Catch 22.
Not exactly. You always need some variety of
project kickoff. That's the project sponsor's
responsibility. The sponsor needs some kind of
a business case, otherwise it won't get off of
ground zero.
> In any case your data prior to the planning game
> is likely to be poor for the same reasons BFUD
> is disliked. Any plan based on this process is
> therefor suspect which makes your resulting
> predictions suspect.
Of course. That's the primary thought behind
agile, after all. Please remember that the question
that kicked off this thread was how to do a
fixed price contract with an agile methodology.
The whole notion of a fixed price, fixed
time, fixed scope project is seriously flawed,
so any plan to accomplish it is necessarily
flawed as well. That's simply the nature
of the beast, but since there are people that
want that, you will sooner or later have to
provide it while knowing full well that the
plan is going to change.
Until we get the "fixed price" meme out of
the public consciousness, that's the nature of
the game.
John Roth
Corey Burnett
In actuality it almost never happens. The customer never shops around
the document to find someone else to do the work. However they need
to feel like they are getting something for the $10,000 they spend on
the requirements. Remember these are small businesses and $10,000 is
a lot for them. It is frightening to them that they might spend
$10,000 just to get a price for the whole project and then have
nothing to show for it. This formalizes the requirements process a
bit and gives them a nice shiny document to show for it. But it is
more than just a shiny document - it ends up being our road map for
the project.
Corey
Corey Burnett
> Corey,
>
> That's not correct. The canonical descriptions of XP suggest that you
> estimate all 50 stories. Once you have completed the first iteration,
> you obtain an estimate of the project's overall duration by dividing the
> sum of estimates for all 50 stories into the sum of estimates for all
> the stories that got done in that iteration.
>
> Thus, you obtain a whole-project estimate - a rather accurate one, since
> it takes into account the real productivity of the actual team that's
> working on the project, as opposed to some guesstimate of that measure -
> for the cost of one iteration.
>
> Laurent
> http://bossavit.com/thoughts/
So it seems like you can't really get an accurate estimate of the
entire project until after your first or second iteration. And my
dillemma is how to get a reasonably accurate estimate up front - I'm
beginning to think it is not really possible! :)
Believe me, as a software developer I am completely on board with
everything that is being said here. I realize that it is next to
impossible to accurately estimate a software project of any
consequence before any work has been done. And I realize that this
method of estimation is probably more accurate.
However my quandry is how to sell this to customers who want to set a
fixed budget before the project begins? Maybe I just have to really,
really pad my initial estimates to leave room for change.
It seems like there are two ends of the spectrum. On one end is a
fixed price job where all of the risk is on the developer. If they
didn't get it right at the beginning then they have to eat the over
runs. The other end of the spectrum is a total time and materials
project where we just bill the customer for whatever it takes to do
the project. In this case all of the risk is on the customer. They
basically have an open checkbook and might spend a lot more money than
they wanted. Is there anything in between?
Thanks for all of the input.
Corey
Corey Burnett
> Corey,
>
> estimate all 50 stories. Once you have completed the first iteration,
> you obtain an estimate of the project's overall duration by dividing the
> sum of estimates for all 50 stories into the sum of estimates for all
> the stories that got done in that iteration.
>
> Thus, you obtain a whole-project estimate - a rather accurate one, since
> it takes into account the real productivity of the actual team that's
> working on the project, as opposed to some guesstimate of that measure -
> for the cost of one iteration.
>
> Laurent
> http://bossavit.com/thoughts/
So it seems like you can't really get an accurate estimate of the
Corey Burnett
> Corey,
>
> estimate all 50 stories. Once you have completed the first iteration,
> you obtain an estimate of the project's overall duration by dividing the
> sum of estimates for all 50 stories into the sum of estimates for all
> the stories that got done in that iteration.
>
> Thus, you obtain a whole-project estimate - a rather accurate one, since
> it takes into account the real productivity of the actual team that's
> working on the project, as opposed to some guesstimate of that measure -
> for the cost of one iteration.
>
> Laurent
> http://bossavit.com/thoughts/
So it seems like you can't really get an accurate estimate of the
sirgilligan
> estimate all 50 stories. Once you have completed the first iteration,
> you obtain an estimate of the project's overall duration by dividing the
> sum of estimates for all 50 stories into the sum of estimates for all
> the stories that got done in that iteration.
>
> Thus, you obtain a whole-project estimate - a rather accurate one, since
> it takes into account the real productivity of the actual team that's
> working on the project, as opposed to some guesstimate of that measure -
> for the cost of one iteration.
Very accurate statement.
I would compare this to "stock market" analysis and the fundamental
tool of the moving average. Lets suppose you are doing a 5 day moving
average and the stock has just started trading publicly today. For the
first 4 days you will not have enough information to compute your 5
day moving average. After the fifth day you have enough information
and you now can begin to try and predict the direction and momentum of
the stock.
So, this will be somewhat repetitive, you estimate as much as you can.
This estimation is constrained by time, money, foresight, experience,
and other factors. You develop your first iteration. You measure what
was completed. This is where "cheating" can come into play. Checking
in the code changes at the last second of the iteration and waving
hands concerning V&V is cheating. So, measure what was completed. If
you didn't get everything done that you thought you could then your
estimates are already incorrect. It is up to the customer to decide
how badly you missed. Since you deliver at the end of each iteration
the customer could decide to take what is finished and go elsewhere.
Suppose you don't loose the contract after the first iteration. You
redefine the next iteration to include the things you didn't get
finsihed. This might cause (and really should cause) a cascading
effect of all planned iterations. Then you go for another interation.
You measure again.
For an agile method to work the customer must be more involved. You
may find that the customer is not as available as you image and that
the time necessary for the customer to commit is much greater than
they imagined. This is a cost factor as well. Ideally the customer
would be on site doing some kind of acceptance role daily. This means
that one of the customer's full-time employees is not doing what she
used to do for her wages but she is off-campus sitting with the
developers so to speak. If it is a year estimate that is one person's
full-time salary + the cost of someone doing the person's other
responsibilities + the contract cost.
In summary... estimation accuracy is checked at the end of each
iteration. Getting the customer to commit to the level necessary may
be difficult.
P.S.
Estimation in BUFD can be accurate as well if the level of progress
tracking is fine enough. If a programmer says it will take two days to
code feature x and it took them three days then ALL dependencies must
be recalculated. The practice is "oh, we will make up a day somewhere
along the line and so we are still on schedule." For some reason, and
maybe it id caused by too much Star Trek, Dr. Who, Red Dwarf, and
Black Adder, but programmers think they can alter time and space and
gain a days work somewhere along the line.
Corey Burnett
> Not exactly. You always need some variety of
> project kickoff. That's the project sponsor's
> responsibility. The sponsor needs some kind of
> a business case, otherwise it won't get off of
> ground zero.
>
> agile, after all. Please remember that the question
> that kicked off this thread was how to do a
> fixed price contract with an agile methodology.
>
> The whole notion of a fixed price, fixed
> time, fixed scope project is seriously flawed,
> so any plan to accomplish it is necessarily
> flawed as well. That's simply the nature
> of the beast, but since there are people that
> want that, you will sooner or later have to
> provide it while knowing full well that the
> plan is going to change.
>
> Until we get the "fixed price" meme out of
> the public consciousness, that's the nature of
> the game.
>
> John Roth
John,
I couldn't agree with you more. I too believe that the notiion of
"fixed price" for anything other than the most trivial software
applications is a bad idea and doomed to failure. I am completely on
board with XP and how it embraces and adapts to change during the
project. But how do I convince a small business to sign up for a
project without really knowing how much it is going to cost and how
long it will take?
Maybe this is the solution...
Currently we manage to convince them to sign up for a requirements
exercise and shell out $10K to produce a large requirements document
(BDUF). Then we give them a fixed price cost and schedule. So they
are used to having an up front exercise that they have to pay for that
yields a better estimate for the entire project.
What if we replaced the traditional up front large requirements
document exercise (BDUF) with the XP steps of capturing the User
Stories, making estimates and going through the first few iterations
so that we can figure out the velocity and more accurately estimate
the rest of the project? I wonder if we could accomplish this for
about the same $10K? (I realize that that is completely dependent on
the size and scope of the project but a lot of our engagements tend to
be about the same size)
My only hesitation is that what if after the initial exercise they
decide not to do the project. In the traditional method (BDUF) they
would have a professional requirements document that they could put on
the shelf and then pull off later to do the project if they desired.
In the XP method, what would we have to show for the first $10K worth
of work?
Thanks - this has been very enlightening.
Corey
Laurent Bossavit
> In the XP method, what would we have to show for the first $10K worth
> of work?
A piece of the system that actually works, has business value, and has
tests to demonstrate that this value is delivered with quality - and to
facilitate further evolution of the system, should the customer shop it
around to someone else. Cheaper than starting from scratch.
Laurent Bossavit
> The planning game pretty much assumes you got funding
> for a project because you have all the people to run
> through the game. You would need these people to get
> the estimates. Yet to fund a project you would need
> the estimates so you could get funding. Catch 22.
Corey's report of his experiences suggests that there is relatively
little problem getting funding, to the tune of $10K, to produce no more
than a requirements document - less concrete information than would be
provided by a planning game and an iteration or two. Ergo, no catch-22.
Your mileage may vary.
John Roth
Well, that's not an entirely accurate presentation. It would
be accurate for a standard plan-driven approach where
you don't see what you're getting until close to the end,
but for an agile approach you've got intermediate checkpoints
where the customer can see, in very real world terms,
how much he's got, how much it's cost, and whether it's
on track. That's one reason why I've seen a "you can
cancel it after any iteration" approach recommended.
It's just occured to me that there is a very good discussion
of contracts toward the end of "Lean Software Development",
(Poppendieck and Poppendieck, 2003).
John Roth
Graham Astles
are fiction, and only work with surcharges for the inevitable change
requests.
One under-emphasized aspect of XP is that it has constant scope
management built in. We often break a card "xxx" into "bare-bones xxx",
"advanced xxx" and "best-of-breed xxx", and will generally cover most of
the "bare-bones" cards before moving on to the higher level functions
with all the bells and whistles that will make the big difference.
Since the customer chooses at each step what will bring the greatest
value to the application, whatever is left over at the end is by
definition the items that are of lesser business value.
This contrasts with many BDUF projects where we define only the "best-
of-breed" requirements in all areas, then build module by module, and
run out of time with a half-completed project that has no business
value.
So for the first $10K the user should have a list of requirements (user
stories), with preliminary estimates on each, and a limited-
functionality first pass of the application that demonstrates code
quality through automated tests. This can be used by the customer to
determine not only what is being promised, but also the team's
capability to actually deliver quality work. That sounds like good
value to me.
Robert C. Martin
wrote:
>I work for a software development company serving small to mid-size
>businesses. Our customers always want to know how much a project is
>going to cost and how long it's going to take before they will sign up
>for the project. Our current approach is to get them to pay for a
>lengthy requirements analysis effort first. This seems to be the "big
>design up front" methodology. I am interested how XP would tackle
>this. What I have read about XP seems to infer that the design is
>more fluid and happening throughout the development cycles. If that
>is the case then how in the world would I accurately estimate the
>entire project before starting and give a fixed price estimate?
How in the world do you *accurately* estimate the entire project now?
Answer: You don't. Worse still: Everybody knows it. So, let's not
pretend that we know how to estimate projects. As a rule, we're
really bad at it.
The XP way is to substitute your "lengthy requirements analysis" for a
time and materials contract to do the first few iterations. Once we
have established our velocity, we can give much better estimates for
the rest of the project.
Of course I would still avoid a strict fixed fee. Rather I'd
establish a low time and materials rate punctuated with milestone
bonuses.
>
>Our current process involves a mini requirements project first.
>Basically the customer pays us for about 100 hours worth of work to
>define the project and produce a requirements document (big design up
>front). For their money they get a nice requirements document that
>they could shop around if they want and they also get a FIXED price
>cost for what it would take for us to do the project. At that point
>they could decide not to do the project, scale it back, or shop it
>around.
Instead, give them something that executes after 100 hours of work.
An initial executable architecture with one or two features working.
That's much better than a big requirements document.
>
>I really like the idea of a more agile process that would adapt to
>change better, involve the customer more, help the customer understand
>the system better, etc. But our customers don't want to write blank
>checks either.
There's no need for that. They can pay for each iteration, and stop
any time they like.
>So how do you accurately estimate the cost of the
>project up front using XP? And if I could get a customer to sign up
>for some sort of XP design/estimation phase what would the
>output/deliverable be that they would be paying for in the case where
>they decide not to go forward with the project?
This is something I've done several times now. The customer has a lot
more control over the process because they pay as they go, and get
value as they go. They can cancel any time they want.
Rather than a fixed price estimate, we give them a rolling history of
progress. Every week we demonstrate new features. They can see how
many features we get done every week, and do the math themselves --
though we tend to do it for them.
Up front they are given the output of the first few iterations of
work, along with the records of how much got done in those iterations.
They can do the math from that too; though, again, we usually help.
-----
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
Robert C. Martin
wrote:
>
>Thanks. Are we nuts to try and do our projects for a fixed price?
No, though it's likely to lead to trouble. Fixed price contracts
assume something that's not true. They assume that you can control
cost, schedule, and quality simultaneously. In reality there is an
uncertainty principle in play. The more accurately you know any two,
the less accurately you know the third.
You can still do fixed price. But you'd better be very conservative
about your estimates, and you'd better be very careful about
liquidated damages and penalties.
>If we use XP, my fear is
>that we are fixing the price up front but not fixing the requirements
>up front - which could spell disaster for us.
One way to work the fixed price contract is to say: $X == X months.
We'll work for X months delivering something that executes every week.
We'll work on the most important features first. In fact, you can
pick the features we work on every week. When we run out of money, we
stop.
A time and materials contract is a better choice. I like a low time
and materials rate -- just enough to pay for the team. And milestone
bonuses that make the profit.
Robert C. Martin
wrote:
>But I still feel like XP does not address the initial up front process
>of telling the customer about how much it's going to cost and about
>how long it's going to take (within some reasonable percentage).
XP is very good at predicting this, once you've got two or three
iterations under your belt. So the trick is to get the customer to
pay time and materials for those first few iterations, and then settle
on a fixed bid (if you must), or a milestone bonus program.
>The
>XP process as I have read it seems to say that the developers do not
>provide estimates for implementing the individual user stories until
>just before they begin programming and that this happens in every
>phase.
Not quite. Estimates are done for all or most stories known.
However, they are not done in man-hours, they are done in points. So
the estimates don't do you any good until you know how many points per
week the team is getting done.
Robert C. Martin
For the life of me I cannot figure out what BFUD stands for. Or
rather, I can, but I don't believe that's what you meant.
Robert C. Martin
wrote:
>I too believe that the notiion of
>"fixed price" for anything other than the most trivial software
>applications is a bad idea and doomed to failure.
I think that's too strong. Fixed price can work so long as scope is
not fixed. Fixed price and scope does not work very well.
>I am completely on
>board with XP and how it embraces and adapts to change during the
>project. But how do I convince a small business to sign up for a
>project without really knowing how much it is going to cost and how
>long it will take?
There is no way to reliably discover this unless you run the project
for a few iterations and measure your progress. No up front analysis
can reliably tell you how long it will take, or what the cost will be.
Everybody knows this already. Anyone who has been involved with more
than a few software projects knows that fixed price and scope is an
illusion.
What you need to do is explain to your client that fixed price and
scope is an illusion; but that you can demonstrate velocity by working
through a few iterations. Let the client know that they will see the
system begin to work after the first week, and that every week
thereafter they will see the system do more and more. Tell them they
can choose the features they want in the order they want. Tell them
that they can stop development at any time, and take the existing
system with them.
>What if we replaced the traditional up front large requirements
>document exercise (BDUF) with the XP steps of capturing the User
>Stories, making estimates and going through the first few iterations
>so that we can figure out the velocity and more accurately estimate
>the rest of the project?
Excellent!
>My only hesitation is that what if after the initial exercise they
>decide not to do the project. In the traditional method (BDUF) they
>would have a professional requirements document that they could put on
>the shelf and then pull off later to do the project if they desired.
>In the XP method, what would we have to show for the first $10K worth
>of work?
A working program that did a few of their most important features.
They'd also have the start of a design and architecture.
Donald Roby
> It seems like there are two ends of the spectrum. On one end is a fixed
> price job where all of the risk is on the developer. If they didn't get
> it right at the beginning then they have to eat the over runs. The
> other end of the spectrum is a total time and materials project where we
> just bill the customer for whatever it takes to do the project. In this
> case all of the risk is on the customer. They basically have an open
> checkbook and might spend a lot more money than they wanted. Is there
> anything in between?
>
>
One benefit for the customer that works a bit against the noted risk is
that the checkbook can be closed at the end of any iteration. If you
drive the order of things worked by the business value, the highest value
will be delivered early, and at the end of each iteration the customer has
a working system with the value added thus far.
The customer can decide to stop at any point and it's not a failed,
cancelled project with nothing but paper plans and designs - it's a
completed project of smaller scope than originally expected. And the
removed scope is the stories the customer thought of as less critical.
Jackson
Corey Burnett wrote:
> I couldn't agree with you more. I too believe that the notiion of
> "fixed price" for anything other than the most trivial software
> applications is a bad idea and doomed to failure.
Is that how you build a house? Is it how you get your car
fixed? Is that how you get your yard landscaped?
Is the how you get a sculpture made?
The customer is always right and customers want to know
what they'll get and how much it costs. Protesting
the world is complex doesn't change this. It sounds
like people what to change the world so it makes
their life easier rather than figure out how to
give the customer what they want.
Jackson
Laurent Bossavit wrote:
> Corey's report of his experiences suggests that there is relatively
> little problem getting funding, to the tune of $10K, to produce no more
> than a requirements document - less concrete information than would be
> provided by a planning game and an iteration or two. Ergo, no catch-22.
> Your mileage may vary.
That's not very much money. How far do you think $10K
would get you in figuring out the plan for making a
device like an ipod?
John Roth
"Donald Roby" <dr...@acm.org> wrote in message
news:pan.2004.09.25....@acm.org...
I've seen this statement, and I'm becoming less and less
comfortable with it. Each iteration is supposed to end with
a production quality deployable, true. And you're supposed
to develop in order of business value.
However ...
There are lots of stories that don't produce *any* business
value by themselves, or actually produce negative business
value by themselves. Why?
Think of it in use case terminology. To do something
that the customer can actually use, you need to implement
a complete scenario, end to end. To do something that
won't cause problems, you need to implement all of the
scenarios necessary to protect all of the stakeholder's
interests (and at least one that advances a stakeholder's
interest).
If you're starting a new use case, this can take a while,
and the system may not adequately protect all stakeholder's
interests while it's in that state. In other words, it may
not be safe to install, even if it looks like it delivers
actual value. If you develop in a safe order, then it
may not deliver value for a while.
Now, if you're fleshing out a use case, then you
may well have a lot of stories that deliver value on
their own. But that happens later in a project, when
the value-producing skeleton of the use case has
already been implemented and is working.
In other words, every iteration should be installable,
but is not necessarilly releasable. And only
releasable products provide business value.
Or am I off base on this analysis again?
John Roth
>
>
>
Laurent Bossavit
> In other words, every iteration should be installable,
> but is not necessarilly releasable.
A concrete example would help me here...
Laurent
Robert C. Martin
>
>
>Corey Burnett wrote:
>> I couldn't agree with you more. I too believe that the notiion of
>> "fixed price" for anything other than the most trivial software
>> applications is a bad idea and doomed to failure.
>
>Is that how you build a house? Is it how you get your car
>fixed? Is that how you get your yard landscaped?
>Is the how you get a sculpture made?
Do you negotiate fixed price contracts with your lawyer to defend
against a law suite, get a divorce, fight a custody battle?
Do you negotiate fixed price contracts with your doctor to cure your
cancer?
There are certain activities that a fixed price contract is
appropriate for. Specifically, things that have been done many times
before and have a well known level of effort and a standard cost.
There are other things that a fixed price contract is quite
inappropriate for, specifically things for which the level of effort
is unknown. Software often falls into the latter case.
Robert C. Martin
On the other hand, a reasonable website project could take less then
100K, and 10K is 10% of that. (Sorry for the obvious math).
Robert C. Martin
<newsg...@jhrothjr.com> wrote:
>In other words, every iteration should be installable,
>but is not necessarilly releasable. And only
>releasable products provide business value.
Granted. You'd like each iteration to be releasable, but this is not
always (or even often) achievable. So, we keep our iterations short,
and we drive to a releasable system in the fewest possible iterations.
Corey Burnett
> I think that's too strong. Fixed price can work so long as scope is
> not fixed. Fixed price and scope does not work very well.
>
> for a few iterations and measure your progress. No up front analysis
> can reliably tell you how long it will take, or what the cost will be.
>
> Everybody knows this already. Anyone who has been involved with more
> than a few software projects knows that fixed price and scope is an
> illusion.
>
> What you need to do is explain to your client that fixed price and
> scope is an illusion; but that you can demonstrate velocity by working
> through a few iterations. Let the client know that they will see the
> system begin to work after the first week, and that every week
> thereafter they will see the system do more and more. Tell them they
> can choose the features they want in the order they want. Tell them
> that they can stop development at any time, and take the existing
> system with them.
>
>
> They'd also have the start of a design and architecture.
>
Ok, I feel like I am starting to see the light a bit on this. But I
do have a couple of practical questions.
1. So we get all of our user stories together at the beginning, make
some rough estimates and then go through a couple of iterations so
that we can accurately measure velocity and refine our schedule and
estimates for the rest of the project. And we keep doing this through
the whole project. How do you deal with the situation where 6 weeks
into the project we are beginning to work on User Story #38.
Originally we had guessed that this would be a 1.5 week effort. Now
that we are really sitting down with them we are uncovering a lot of
detail that we didn't know about before. (Not really scope change
since the client envisioned this all along - we just didn't realize
until now some of the complicated details). So the new estimate for
story #38 is 4 weeks. Now I've got an unhappy client because the
estimate for the whole project just shot up by about $10K (2.5 weeks
at $100 / hour) without much scope change (at least in their eyes).
Admittedly this is a hypothetical - but as a project manager this is
what worries me. I need to be able to set clients expectations (cost
and schedule) and then meet those expectations. Is the answer that we
need to educate our clients more on the risks of custom software
development? From the clients perspective they might say something
like "I wish that we would have uncovered this before, maybe I
wouldn't have even started the project."
2. I have read a lot about having the client determine the most
important stories and letting them choose the order of implementation.
How do you deal with very obvious technical dependencies between
stories? Sometimes you can't really implement story A unless you are
going to implement story B, C, and D.
3. How do you effectively build an object-oriented system of real
complexity without a planning phase where you really sit and
contemplate your object model? It would seem that to really create a
good system of classes that will be easy to maintain that it would
make sense to have a more traditional analysis phase to really
refactor your object model before you have even typed one line of
code. XP seems to favor a sort of "code as you go" approach. I can
envision getting to the last section of a system after 12 weeks of
coding and suddenly realizing that I should go back and really
re-think how my classes inter-relate - sort of a "if I knew then what
I know now" kind of thing where I have to rip out a lot of the guts of
my system. Either that or my system starts to feel like it was pasted
together instead of built with any forethought. To me XP seems to
ignore the maintenance aspect of good coding. If a system is really
well thought out in advance, then it can be much easier to maintain
over the long haul. If it is sort of just thrown together using
whatever seemed easiest that day it can be a nightmare to maintain and
be a very brittle application.
Just some thoughts. As you may be able to tell I am very, very
interested in a new process as I too believe that fixed price, fixed
scope is an illusion - but I still have some reservations as to how it
will work in practice. I have become very weary of any sort of "magic
bullets".
Thanks for all of the input - this has been a very helpful
conversation.
Corey
Jackson
Robert C. Martin wrote:
> Do you negotiate fixed price contracts with your lawyer to defend
> against a law suite, get a divorce, fight a custody battle?
You ask how much it will cost. If that's too much you go
somewhere else. Or you lose. That's the tough nuggies
of life. You can't say i have $10,000 but spend as much
as you need to anyway.
> Do you negotiate fixed price contracts with your doctor to cure your
> cancer?
If you haven't noticed a lot of people die because they can't
afford treatment. So yes.
> There are other things that a fixed price contract is quite
> inappropriate for, specifically things for which the level of effort
> is unknown. Software often falls into the latter case.
On any project there are unknowns. Complexities. Uncertainties.
Twists and turns. It's a lot of whining to say software is special,
so open up the checkbook and shut up about it. You want to say
it's the hard reality that software is difficult so we can't
predict what will happen. It's also the hard reality that
people want to know how much it will cost and how long it will
take. It's still the golden rule.
Isaac Gouy
-snip-
> Everybody knows this already. Anyone who has been involved with more
> than a few software projects knows that fixed price and scope is an
> illusion.
Anyone who has been involved with more than a few software projects
knows that we have 4 variables to play with:
Time
Cost
Scope
Quality
Isaac Gouy
John Roth
Well, a good example might be Use Case
22 from "Writing Effective Use Cases" by
Alaistar Cockburn. It's almost three
pages long in the book, the extension
scenarios themselves are over a page
and a half. I doubt if any reasonable
team could implement the main success
scenario plus the minimum number of
extensions required to protect all stakeholder's
interests in one iteration.
John Roth
>
> Laurent
>
Ronald E Jeffries
In software development Cost ~= k*Time, since the cost is generally in
the people.
And no one is very good at controlling the Quality variable, other
than just driving quality down willy-nilly.
So when we fix cost and scope, we've basically done something unknown
to quality. That seems like a bad idea to me.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Donald Roby
<snip/>
Note: I snipped simply because I think others can and will address most
of your points much better than I could. That may be true of the
following as well, but I hope I have some small contribution.
>
> I can envision getting to the last
> section of a system after 12 weeks of coding and suddenly realizing that
> I should go back and really re-think how my classes inter-relate - sort
> of a "if I knew then what I know now" kind of thing where I have to rip
> out a lot of the guts of my system. Either that or my system starts to
> feel like it was pasted together instead of built with any forethought.
> To me XP seems to ignore the maintenance aspect of good coding. If a
> system is really well thought out in advance, then it can be much easier
> to maintain over the long haul. If it is sort of just thrown together
> using whatever seemed easiest that day it can be a nightmare to maintain
> and be a very brittle application.
>
>
My immediate sense on seeing XP described was almost the exact opposite of
this. The XP attitude toward maintenance is for me one of its
attractions.
XP does not ignore maintenance. Rather it takes you almost immediately to
maintenance. After the first iteration, you're maintaining a working
system. And in the first iteration, you're enabling that maintenance.
By writing the tests before the code, you ensure that the code is testable
and in fact tested at least at the unit level. This allows you as
maintainer to add features with less fear of breaking something already
implemented.
By implementing only what is needed to add the current feature, you keep
the system free of unnecessary complexity, a frequent cause of maintenance
nightmares. Note that this does not mean "whatever seems easiest".
By frequent refactoring, you evolve the code to a design that covers the
needs with quality code. This is not by any means automatic, and looks to
me like it's basically a large part of the XP design process. But if it's
done well and done when it's needed, it allows you to keep the code at a
high quality. Refactoring is a design tactic substituting good hindsight
and good localized forethought for the upfront forethought that so many
people think is needed. If you do it well, you may never have the moment
of disastrous hindsight you describe above.
All these practices provide things that are critical to the
maintainability of a system.
I think a system is much more likely to be maintainable and to be
maintained well if an attitude of creating and maintaining quality is
there from the start.
> Just some thoughts. As you may be able to tell I am very, very
> interested in a new process as I too believe that fixed price, fixed
> scope is an illusion - but I still have some reservations as to how it
> will work in practice. I have become very weary of any sort of "magic
> bullets".
>
As well you should be. Fred Brooks was right. There is no silver bullet.
None of this will solve all problems, and it is not magic. Plenty of hard
work is still required.
I have not yet been able to try the entire thing in practice, so please
take anything I say with a grain of salt. I in fact still have some
doubts, primarily worries as to whether it can work in the context of my
workplace.
Ronald E Jeffries
>Corey Burnett wrote:
>> I couldn't agree with you more. I too believe that the notiion of
>> "fixed price" for anything other than the most trivial software
>> applications is a bad idea and doomed to failure.
>
>Is that how you build a house?
Almost all houses go over budget or have to make compromises late in
the game.
> Is it how you get your car
>fixed?
Your mechanic's estimate is an estimate. He'll agree to call you when
he learns something that will take him over.
>Is that how you get your yard landscaped?
It frequently happens that something dies and has to be replaced.
After a short warranty period, that's your problem. If they discover a
rock under your ground, the landscapers will in fact charge extra to
take it out.
>Is the how you get a sculpture made?
I don't know.
>
>The customer is always right and customers want to know
>what they'll get and how much it costs. Protesting
>the world is complex doesn't change this. It sounds
>like people what to change the world so it makes
>their life easier rather than figure out how to
>give the customer what they want.
You may have heard the rumor that the great majority of software
projects come in over the time and dollar budget and/or under on
scope. Some of us want to change people's understanding of what this
means, because we think that in fact, the people who set the budgets
for software projects are not capable of doing so effectively. We
prefer an approach with better feedback, better tracking, and a better
chance of delivering the best possible value on time and on budget.
We are here to change the world, to make things work better.
What's your plan for getting software projects to come in on time and
budget, fit for purpose?
Ronald E Jeffries
wrote:
>So it seems like you can't really get an accurate estimate of the
>entire project until after your first or second iteration. And my
>dillemma is how to get a reasonably accurate estimate up front - I'm
>beginning to think it is not really possible! :)
An iteration is a week or two of work. How can you get any decent
estimate any faster?
Donald Roby
Unfortunately, Time, Cost, Scope and Quality are tangled up in a
non-linear interdependency.
Many people try to fix Time, Cost and Scope, only to find that letting
Quality go down makes Time and Cost go way up unless you cut Scope.
Andrew McDonagh
> Robert C. Martin <uncl...@objectmentor.com> wrote in message news:<6ds9l0d2li2g4dud9...@4ax.com>...
>
Snipped.
As I feel the first 2 questions have been well discussed.
>
> 3. How do you effectively build an object-oriented system of real
> complexity without a planning phase where you really sit and
> contemplate your object model? It would seem that to really create a
> good system of classes that will be easy to maintain that it would
> make sense to have a more traditional analysis phase to really
> refactor your object model before you have even typed one line of
> code.
Without the benefit of experiencing XP, this is a common reaction to XPs
removal of BUFD. Somethings can only be fully understood when they are
attempted. However, we all need reassurance and this is where this list
and others come in.
> XP seems to favor a sort of "code as you go" approach.
This is true, instead of analysising, designing, implementing and
testing, with each stage taking weeks, months or years.
XP changes us to do these same activities (slightly re-ordered) in a
much shorter time scale.... in minutes and seconds.
Its vital to understand (note I'm not suggesting anyone here has implied
this), that when programming in XP, the developers are constantly
designing, not constantly 'hacking out code'
XP is about evolutionary design of the code, letting the code direct
which way the code wants to go. No dupication, loosely coupled, highly
coherent good quality OO code.
> I can envision getting to the last section of a system after 12 weeks of
> coding and suddenly realizing that I should go back and really
> re-think how my classes inter-relate - sort of a "if I knew then what
> I know now" kind of thing where I have to rip out a lot of the guts of
> my system.
I can only tell you what I have experienced during the 16 months of
using XP. This has happened, but not where you'd think.
The product my team is developing is a large client-server GSM Telecom
network management system. There is currently a third of the code base
which is pre-XP, and isn't unittested. This code is the worst within
the system. We only change it when needed due to working upon stories
in that area of the code. When these stories come along we tread VERY
carefully. We also try very hard to refactor the code to be testable,
cleaner, safer, etc.
On the other hand, most code developed since XP is fully tested, well
designed, maintable, etc. This hasn't been easy, its the result of
constant refactoring of the code, whenever it 'smells'...i.e. doesn't
enable new features, the OO-ness is off, the class or method names are
intent-revealing enough, etc..
The only other times have been when we have implemented a story and the
customer has seen that it was just the wrong. No fault of the customer,
developers or code. The functionality just didn't sit right with the
entended use. But until having implemented the story, the customer had
no way of seeing this error. This is where XPs constant, quick feedback
to the customer really helped. The story was just one of a dozen during
a single iteration. Using two week iterations meant the customer saw
the completed story very quickly and could change quickly due to this
feedback.
>Either that or my system starts to feel like it was pasted
> together instead of built with any forethought. To me XP seems to
> ignore the maintenance aspect of good coding.
XP embraces maintenance, as the code will offen have to change when
adding new features. And if those changes affect its smell, then the
code is refactored - it should NOT be left to fester.
> If a system is really
> well thought out in advance, then it can be much easier to maintain
> over the long haul. If it is sort of just thrown together using
> whatever seemed easiest that day it can be a nightmare to maintain and
> be a very brittle application.
I understand your feeling, the only thing I can say to this, is that the
opposite is what I'm currently seeing in our large code base.
>
> Just some thoughts. As you may be able to tell I am very, very
> interested in a new process as I too believe that fixed price, fixed
> scope is an illusion - but I still have some reservations as to how it
> will work in practice.
Which in itself is a great thing, the more people in our industry become
interested in changing rather than the status-quo, the better we all
will be.
>I have become very weary of any sort of "magic
> bullets".
we all have, I don't think many XPers would descibe XP as one, but we
are VERY fond of it ;-)
>
> Thanks for all of the input - this has been a very helpful
> conversation.
>
> Corey
Pleasure is all ours, great thread.
Andrew
Laurent Bossavit
> Well, a good example might be Use Case
> 22 from "Writing Effective Use Cases" by
> Alaistar Cockburn.
I don't have the book, so that doesn't help me - yet. Can you
elaborate ? What is the use case about ?
Laurent
Robert C. Martin
wrote:
>1. So we get all of our user stories together at the beginning,
The word "all" is inappropriate. You can get many of the most
important stories together; but you'll never find them all. If the
project is successful there will be a never-ending stream of changes
and additions. So what you try to do is find the batch of stories
that address the most significant needs.
>make
>some rough estimates and then go through a couple of iterations so
>that we can accurately measure velocity and refine our schedule and
>estimates for the rest of the project. And we keep doing this through
>the whole project.
Yes. Though remember that the estimates are not in man-hours. The
estimates have no units at all. They are just points. We *measure*
how many of those points we get done each iteration.
>How do you deal with the situation where 6 weeks
>into the project we are beginning to work on User Story #38.
>Originally we had guessed that this would be a 1.5 week effort. Now
>that we are really sitting down with them we are uncovering a lot of
>detail that we didn't know about before. (Not really scope change
>since the client envisioned this all along - we just didn't realize
>until now some of the complicated details). So the new estimate for
>story #38 is 4 weeks. Now I've got an unhappy client because the
>estimate for the whole project just shot up by about $10K (2.5 weeks
>at $100 / hour) without much scope change (at least in their eyes).
One way to deal with this is for everyone to agree at the outset that
the estimates are, well, estimates. Both you and the customer agree
that what is really being purchased is points per week. When the
shortfall of story #38 becomes evident, the customer can delay the
story, simplify the story, or authorize the story in its current form.
When you get the customer working with you, then you form a single
team. You look at the problems together and try to work out an
acceptable solution.
Another way to deal with this is to agree to pay a certain amount for
each point completed, plus a certain amount for each hour worked. For
example, let's say you've got a project of 1000 points. Let's also
say that a team of four has established an estimated velocity of 50
points per week. This looks like about an 80 man-week job. At
$100/hour this would be a $320,000 job. So lets reduce the hourly
rate to $30/hour, and ask the customer for $224 per point.
This sets up a very interesting dynamic. If the job really does take
80 man-weeks, then it will cost the same. If it takes 100 man-weeks
then it will cost $344,000. If it takes 70 man-weeks it will cost
$308,000. Notice that this is a small difference for a significant
amount of time. Notice also that you, as developer feel strong
motivation to be done early, since that increases your true hourly
rate.
This is a share-the-risk model which I have employed to great success
on multi-million dollar contracts.
>Admittedly this is a hypothetical - but as a project manager this is
>what worries me. I need to be able to set clients expectations (cost
>and schedule) and then meet those expectations.
Set a range. It will cost between $308K and $340K. You'll be able to
see our velocity in points per week. After five weeks you should be
able to project when we'll be done and how much it will cost.
>Is the answer that we
>need to educate our clients more on the risks of custom software
>development?
Certainly they need to agree that the price is a constrained random
variable.
>From the clients perspective they might say something
>like "I wish that we would have uncovered this before, maybe I
>wouldn't have even started the project."
That's always a risk, so any project-breaker stories should be done
early to mitigate that risk.
>2. I have read a lot about having the client determine the most
>important stories and letting them choose the order of implementation.
> How do you deal with very obvious technical dependencies between
>stories? Sometimes you can't really implement story A unless you are
>going to implement story B, C, and D.
That's a very common question, that has a very counter-intuitive
answer. You don't deal with it at all. You trust that you'll be able
to find a way around the dependencies. Most of the time you will. In
the odd event that you don't -- well that's part of the risk.
>3. How do you effectively build an object-oriented system of real
>complexity without a planning phase where you really sit and
>contemplate your object model?
We try to build an object model of much lesser complexity by building
it in very small increments and validating it as we go. We *always*
consider the object model; but we don't allow it to grow in intuition
alone. We check every decision by coding it. We don't build one
decision on top of the next until the code tells us that the first
decision was workable.
Code can be kept very flexible. This can be hard to imagine if you
are used to tangled masses of legacy code. However, when you build
incrementally, and when you are constantly adjusting your designs, and
when you are following the testing disciplines of TDD, the code
remains remarkably malleable. So when a design change comes along, it
can be addressed without great pain.
>It would seem that to really create a
>good system of classes that will be easy to maintain that it would
>make sense to have a more traditional analysis phase to really
>refactor your object model before you have even typed one line of
>code.
It would seem that way. The opposite is often true. Up front designs
based on intuition tend to be much more complex than incremental
designs based on reality. They also tend to be more rigid and less
maintainable. I know this is counter-intuitive, but it's something
I've seen over and over again. I know that this argument amounts to
"trust me". You'll have to make your own call.
>XP seems to favor a sort of "code as you go" approach. I can
>envision getting to the last section of a system after 12 weeks of
>coding and suddenly realizing that I should go back and really
>re-think how my classes inter-relate - sort of a "if I knew then what
>I know now" kind of thing where I have to rip out a lot of the guts of
>my system. Either that or my system starts to feel like it was pasted
>together instead of built with any forethought.
That is certainly the fear. Indeed, this frequently happens even with
lots of up-front design work. All I can tell you is that my
experience has been that incrementally designed code is much more
flexible and adaptable than you'd expect. More flexible and adaptable
than code designed up front.
>To me XP seems to
>ignore the maintenance aspect of good coding.
From a traditional point of view, it seems to. Yes. In fact, I've
experienced just the opposite. Code generated in small increments
using TDD is much easier to maintain.
>If a system is really
>well thought out in advance, then it can be much easier to maintain
>over the long haul.
That is not my experience. I recognize that it is many people's hope.
>If it is sort of just thrown together using
>whatever seemed easiest that day it can be a nightmare to maintain and
>be a very brittle application.
We aren't talking about throwing anything together. The discipline of
an XP team is something that needs to be seen to be understood. Every
line of code has a test case written first. The code is kept as clean
and expressive as possible. Duplication is mercilessly removed.
There is no "throwing it together" going on.
Robert C. Martin
>
>
>Robert C. Martin wrote:
>> Do you negotiate fixed price contracts with your lawyer to defend
>> against a law suite, get a divorce, fight a custody battle?
>
>You ask how much it will cost.
They say: $300/hour.
>> Do you negotiate fixed price contracts with your doctor to cure your
>> cancer?
>
>If you haven't noticed a lot of people die because they can't
>afford treatment. So yes.
There is a difference between limited resources, and fixed price.
John Roth
It's an insurance claims handling use case. You really
don't need it - the main point I was trying to make
is that is was, as such things go, huge, and there was
no way you could do enough of it in one iteration to
provide "business value."
John Roth
>
> Laurent
Jackson
Robert C. Martin wrote:
>>You ask how much it will cost.
>
> They say: $300/hour.
Then you have to decide if you think you can
accomplish your goals given that price.
If not then you need to do something else.
If you can't then you can't.
> There is a difference between limited resources, and fixed price.
Certainly. But in a network of fixed resources
you must make tradeoffs. One of your limits will
be the top price. If something can't be done
for that price then you need to be agile enough
to do something else. We aren't talking just
about agile programming. We are talking about
agile life. And it no area of life are costs
unbounded.
joesephf
> rather, I can, but I don't believe that's what you meant.
I think it is an anagram. And FUD stands for fear, uncertainty,
and doubt.
Phlip
> >If you haven't noticed a lot of people die because they can't
> >afford treatment. So yes.
>
> There is a difference between limited resources, and fixed price.
While Babylon values money above human life, resources will appear limited.
Insurance lawyer parasites, on both sides, collude to corrupt that system.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Corey Burnett
Snipped to preserve space - read previous message...
Andrew,
Good points. I guess I think of a traditional construction metaphor
(don't know if it is a proper metaphor or not). Let's say that I am
building a house. I read all of my user stories up front and I know
that it will be a three story house. So I make some rough plans and
estimates ahead of time and I feel pretty good because I have built
homes before. We start off and build the first floor first. Things
are going well, we are getting lots of feedback, making little changes
along the way. Then I build the second floor and things are still
going well. Then when it comes time to build the third floor we have
the developers sit down and get the detailed requirements for the
third floor (as we did for the other floors). At that time we find
out that one of the people who will be living on this floor is in a
wheelchair so they need an elevator!! Rats. We have already built
two really nice floors with traditional stairs and now we will have to
rip up a lot of wood and stuff to install an elevator after the fact.
If only we had known this up front. We would have done things
differently and it might have cost a lot less. And now we are worried
how the changes that we will need to do to install the elevator will
affect the rest of the house.
We did know that we were going to have 3 floors but because we
deferred the details until we were ready to build the 3rd floor we are
screwed now.
I know this is a very extreme example - but is my point valid? Or am
I just a big worry wart! :)
Thanks,
Corey
Phlip
> Good points. I guess I think of a traditional construction metaphor
> (don't know if it is a proper metaphor or not). Let's say that I am
> building a house. I read all of my user stories up front and I know
> that it will be a three story house. So I make some rough plans and
> estimates ahead of time and I feel pretty good because I have built
> homes before.
Software is weightless. Source code is the design, and one construction is a
compilation and test run.
To design a house, we build a hut, add a business requirement, build a
larger hut, add a requirement, and keep going until we have a skyscraper.
XPers fear BDUF for a simple reason. Exploring a design in code very often
leads rapidly to a surprisingly simple design that does not need rework.
Designing for extensibility, without code, often leads to a design burdened
with excessive speculative complexity.
Complexity is easy to add and hard to remove, so start with simplicity.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Corey Burnett
Bob is correct. I used the figure of $10K because most of our
engagements are in the vicinity of $50K - $100K for the entire
project. So $5K - $10K up front to gather requirements (or whatever)
seems reasonable. If in the future we start landing larger projects
and our company grows then we will certainly spend more up front to
estimate the entire project.
Corey
Corey Burnett
> On 24 Sep 2004 08:22:58 -0700, thebu...@yahoo.com (Corey Burnett)
> wrote:
>
> >So it seems like you can't really get an accurate estimate of the
> >entire project until after your first or second iteration. And my
> >dillemma is how to get a reasonably accurate estimate up front - I'm
> >beginning to think it is not really possible! :)
>
> An iteration is a week or two of work. How can you get any decent
> estimate any faster?
I'm curious about the iteration size. Most people have referred to an
iteration as lasting 1 - 2 weeks. Would this vary depending on the
overall complexity and scope of the project or is it pretty standard?
Might you have a very small iteration size (2 days) on a very small
project? And might you have a very large iteration size (2 months) on
a very, very large project? I know there is nothing written in stone
but I was wondering what the prevailing wisdom was.
Corey
Corey Burnett
I have to agree here. I can think of lots of systems that I have
built in the past that only really become usable and valuable to the
customer when all of the major modules are completed and integrated.
Let's say I'm building some sort of web-based data collection,
analysis, and reporting tool for a small business. I might come up
with the following modules: Login, User Management, Sales Data Entry,
Product Data Entry, Reporting. Usually it makes sense to start with
login first so that is the first module I build. After iteration 1 I
have a system that you can log in to but it doesn't really do
anything. So then I build the User Management next because you have
to be able to add, edit, and delete users. Done. So after iteration
2 I have a system that you can log in to and maintain users.
Functions great but really offers no business value yet. You can see
where I am going. The whole system doesn't really give the customer
what they want until they can run the reports and see all of the
product and sales data. And that doesn't really happen until almost
all of the modules are done. If we stopped after we had the Login,
User Management and Product Data Entry modules the customer really
wouldn't have anything that would do anything for them.
So when we talk about illusions (and people have mentioned earlier in
this thread that fixed price, fixed scope software development (BDUF -
big design up front) is an illusion), it seems to me that the XP
promise of a usable system that provides business value after every
iteration is also a bit of an illusion.
Interested in what others think.
Corey
Isaac Gouy
> >Robert C. Martin <uncl...@objectmentor.com> wrote
> >> Everybody knows this already. Anyone who has been involved with more
> >> than a few software projects knows that fixed price and scope is an
> >> illusion.
> >
> >Anyone who has been involved with more than a few software projects
> >knows that we have 4 variables to play with:
> > Time
> > Cost
> > Scope
> > Quality
>
> In software development Cost ~= k*Time, since the cost is generally in
> the people.
Some clients are very interested in getting the software quickly, and
are willing to pay. Some have other ideas.
> And no one is very good at controlling the Quality variable, other
> than just driving quality down willy-nilly.
Ignoring the Quality variable hardly improves the situation.
> So when we fix cost and scope, we've basically done something unknown
> to quality. That seems like a bad idea to me.
Not specifying what quality level we are trying to achieve seems like
Isaac Gouy
> Unfortunately, Time, Cost, Scope and Quality are tangled up in a
> non-linear interdependency.
>
> Many people try to fix Time, Cost and Scope, only to find that letting
> Quality go down makes Time and Cost go way up unless you cut Scope.
As usual we may be tripping over ambiguities.
Internal quality (quality of code) vs external quality (quality of product).
Andrew McDonagh
Yes you are a big worry wart, but then most of us developers are!
Ok, your metaphor is a nice one to show the 'whats, buts & ifs' of an XP
project...
If the customer knew that a wheel chair user was going to be living on
the top floor, then they normally would have had a strong gut feeling
about telling you very soon into the project and not leaving it until so
late in the day.
But what if the customer didn't know about this user's special needs?
But lets keep with the idea that the customer did know about this user,
but simply didn't realise it would cause much of a problem. This is
especially true seeing as its obvious to the customer and so should be
obvious to you!
Ok, whats the simplest way of getting access to the floor for this user?
Can the Elevator be installed outside, providing direct access, rather
than internally and thereby saving any need to redesign the internals?
If the elevator was added to the exterior of the building, it might even
lead to further enhancements, e.g. utility area? Garage? Car Port?
What it the design of the interior was so well constructed that it was
highly modular? The walls can easily be moved around and the pluming is
the new plastic flexible type which moves easy with the walls too.
Sounds like a little refactoring is needed, but then we'll be able to
have an interior elevator.
So far so good, we can in some way accommodate the new story. Yes the
cost of implementing it so late in the game certainly feels like its
more than it would have been if we knew about it at the beginning.
But what if....
...even though the customer knew about the access problem way in advance
and didn't tell us until way late in the day, the access problem went
away? The user passed away, or decided to live somewhere else?
Then thats great, because we hadn't built anything for the special
access, which now so late in the day, is no longer needed. Which means
we never spent any money on something which was never needed.
A concrete example of this very problem is currently happening on my
very own product.
Brief reminder: My team is developing a Large client server GSM mobile
telecoms network management system.
The building access problem you used is almost identical to an issue we
are having right now.
We are just getting our first stories regarding the system supporting
USER accounts. Different access rights, User groups, Audit trails, etc.
The system currently has no support for any of this and is now nearly 3
years old. We guessed in the very early days that something like user
access control would be needed, but our customer decided its priority
was lower than the normal Network Management functionality. So by only
doing whats important 'at this time' to the customer, we managed to get
a working product out which they can use today. Tomorrow we'll add the
extra functionality they need.
Its almost akin to 'premature optimization', don't try and guess what
needs doing, use a tool (in our case the customer) to tell you what
needs to be done.
HTH
Andrew
Andrew McDonagh
What is business value?
We tend to think its fully working, fully developed systems meeting all
of the critical requirements...
But what about the other business values?
Schedule? budgets? resources?
By implementing small sub-parts of the critical requirements in dribs
and drabs, with each passing iteration. The customers get to see REAL
working applications that meet those small sub-part requirements.
Sure these releases may well be useless for the customer to actually
deploy beyond into full use, but it does show them that they AND us are
moving towards the goal in the right direction.
It allows them to not only hear that the apps development is
progressing, but to actually see it progressing.
It allows them to get rapid feedback of this development, allowing them
to make changes, allowing us to make those changes.
Andrew
Robert C. Martin
wrote:
>We did know that we were going to have 3 floors but because we
>deferred the details until we were ready to build the 3rd floor we are
>screwed now.
>
>I know this is a very extreme example - but is my point valid? Or am
>I just a big worry wart! :)
Something of a worry wart I'm afraid. In software there's no
foundation to dig, no forms to set up, no concrete to pour. Moreover,
there's no gravity to force ordering upon you. Yes, there are certain
things that are relatively harder to do when done out of order, but
with nowhere near the cost sensitivity of building a house.
Complex software is not designed -- it is grown from humble
beginnings. To quote Booch who quoted Gall: "A complex system that
works is invariably found to have evolved from a simple system that
worked..... A complex system designed from scratch never works and can
not be patched up to make it work. You have to start over, beginning
with a [simple] system that works."
John Roth
"Corey Burnett" <thebu...@yahoo.com> wrote in message
news:73447641.04092...@posting.google.com...
It is and it isn't. The fact is that some things are easier to change
than others. The reason the building example is a bad example
is that it is something that will cost significant time and money
to change.
Well designed software is very easy to change. Why? Well,
it's a circular arguement: most people's criterion for well
designed software is that it needs to be easy to change!
What's hard is actually doing it.
XP does not have a monopoly on making easy to change
software. Any large shop that has been maintaining programs
for many years knows how to do this, at least to a great
extent.
What XP does is start off on day one with a very great
need for easy to change software. The entire process
will fail rapidly if the software is not easy to change.
So to make it work at all, the development team has
to learn how to write software that is easy to change,
and they frequently learn this in the school of hard knocks,
one problem at a time.
It's easy to say: "reduce coupling," "eliminate duplication,"
"remove code smells," "increase expressiveness."
It's not easy to do it without a significant learning
curve.
"Waterfall" doesn't do this. The ideal in a classical
project is to write each module once, deliver the
product and hand it over to the maintenance team
while the original developers head for the tall timber
(uh, move on to another project) before the
maintenance team finds out what they've got and
forms a posse.
Up front design and requirements is a compensation
for the tendency to write brittle, hard to understand
and maintain code. The hope is that if you do well
enough on requirements and design, you won't have
to wade into the allegator infested swamp to change
the code once it's written.
John Roth
>
> Thanks,
> Corey
John Roth
"Isaac Gouy" <ig...@yahoo.com> wrote in message
news:ce7ef1c8.04092...@posting.google.com...
They are related.
External quality has two dimensions:
First, fitness for purpose
Second, stability (lack of bugs...)
Internal code quality has three significant points on the axis:
First, the quality that the team will produce without additional effort.
(the flow point.)
Second, the quality level that the team requires to maintain velocity.
Third, the quality level that produces the desired degree of
stability in the delivered code.
If the first point is lower than either the second or third,
you're going to have problems.
If it's higher than both the second or third, everyone is
going to be happy (except the cost accountant who will
mutter that the level of quality is costing him money.)
What the cost accountant misses is that it's not easy
to reduce the level of quality if that's the team's flow
point.
John Roth
John Roth
We prefer to implement a minimal end-to-end system and
expand on that. In other words, the first iteration would let
someone log on, enter some data and get a report.
It might not validate the user, be very much data, or a
very big (or useful) report, but it's the skeleton of the
complete system.
There are a number of reasons for doing it that way,
among which is that you have to have all of the significant
technology and interface ducks lined up and quacking
in synch to do it. It front loads a lot of the technology
"oops" factors.
End-to-end means all the way out through deployment.
Each iteration should end one button press (or equivalent)
away from going live.
It also gives the customer something end to end to look
at, each and every iteration.
John Roth
>
> Corey
sirgilligan
There have been excellent responses to your questions about XP and
bidding contracts.
There was one statement concerning that at the end of an iteration
their might not be a shippable product. This is very true. Also I feel
that it is true that you do have a transferable piece of work. I mean
this, at the end of the iteration your customer says, "you took too
long for this piece. Thank you. I am pulling out." The customer takes
the first iteration and the user stories and use cases and whatever
and finds a new contractor.
My question to you is this: What level is the person that is hiring
you for the contract?
Following will be a snippet from a paper I wrote. The point is, if he
does not understand software development then he might not understand
XP and say something like, "What do you mean you want me their to pick
the features for each step. That is what I am hiring you to do!"
You not only have to understand the product you are bidding on, but
the nature of the employer so that you can anticipate future requests,
reactions, and direction.
Here is the snippet:
http://home.att.net/~geoffrey.slinker/maverick/MaverickHiring.html
Level 1 Understanding
This is an idea by a non-computer savvy person. This is when someone
says, "I have this idea about a computer program that I want
developed." If you ask them, "What platform does this program need to
run on?" and they say something like "Windows", did they really mean
Windows or did the mean in a Web Browser. This person has no idea of
how long it takes to write software and what the expense can be.
Level 1 understanding requires an Architect level computer scientist.
One that understands desktop versus web based solutions. One that can
gather requirements, use cases, user scenarios, and design the
software and select the development environment and the deployment
environment. The correct computer scientist for this job will also
understand cost estimation, effort estimation, strategic planning,
testing, and all of the other aspects of delivering quality software.
Level 2 Understanding
This is a person that is computer literate and has an idea for a
software product. They are aware of which computer platform on which
they want the software developed. They do not understand the cost of
software development. They do not know about development platforms,
computer languages, open-source solutions versus major vendor
solutions. They have no idea that runtime licenses can be hundreds of
thousands of dollars.
Level 2 understanding also requires a Senior Developer or an
Architect. This computer scientist is a specialist on the platform
that is required. The computer scientist understands the current
solutions, tools, and resources available on the specified platform.
Level 3 Understanding
This is a person that is familiar with software development and has
experience in the area. A Product Manager is typically at this level.
They are aware of customer needs so the requirements will be
specified. They have experience with developers and are aware that
estimated dates are rarely accurate and that costs often overrun. They
know of these difficulties in software development but they do not
fully understand why they occur. They know of the levels of computer
scientists and are capable of deciding on which level is appropriate
for the task at hand. They are familiar with the capabilities of
junior developers, senior developers, architects, and the other roles
of software development.
Level 4 Understanding
This is a person that is understands the product to be developed and
the details of software development. A Project Manager is typically at
this level. This person maybe a former software engineer that has
taken a management path in their career. This person could be very
current in issues even at the level of writing code themselves, or
they maybe a few years removed from the cutting edge development
practices but still are in touch enough to walk the walk and talk the
talk.
They know what the job is and what type of person they need to perform
the task.
Level 5 Understanding
This is a person that could do the job. They are typically team leads
and senior developers. They are hiring because they do not have the
time to do the task themselves. They know exactly what they want. They
could do it themselves if they just had the time.
Ronald E Jeffries
wrote:
>I know this is a very extreme example - but is my point valid? Or am
>I just a big worry wart! :)
If you're building a house, your concern is valid. In software, I
think not.
Regards,
Ronald E Jeffries
>> In software development Cost ~= k*Time, since the cost is generally in
>> the people.
>
>Some clients are very interested in getting the software quickly, and
>are willing to pay. Some have other ideas.
You mean there are clients who would like to pay more, and get the
software later? I've never encountered any like that.
>
>> And no one is very good at controlling the Quality variable, other
>> than just driving quality down willy-nilly.
>
>Ignoring the Quality variable hardly improves the situation.
True, that's why I'd not suggest ignoring it. I'm just pointing out
that it's not possible to adjust quality up and down in any effective
way. The bugs just won't go where we want. That's why XP sets the
quality dial as close to perfect as we can get it.
>
>> So when we fix cost and scope, we've basically done something unknown
>> to quality. That seems like a bad idea to me.
>
>Not specifying what quality level we are trying to achieve seems like
>a bad idea to me.
True. That's why we do all that testing, and why we keep all the tests
running at 100 percent all the time.
Ronald E Jeffries
wrote:
>Ronald E Jeffries <ronje...@acm.org> wrote in message news:<18qbl0pmv4vartg5v...@4ax.com>...
>> On 24 Sep 2004 08:22:58 -0700, thebu...@yahoo.com (Corey Burnett)
>> wrote:
>>
>> >So it seems like you can't really get an accurate estimate of the
>> >entire project until after your first or second iteration. And my
>> >dillemma is how to get a reasonably accurate estimate up front - I'm
>> >beginning to think it is not really possible! :)
>>
>> An iteration is a week or two of work. How can you get any decent
>> estimate any faster?
>
>I'm curious about the iteration size. Most people have referred to an
>iteration as lasting 1 - 2 weeks. Would this vary depending on the
>overall complexity and scope of the project or is it pretty standard?
>Might you have a very small iteration size (2 days) on a very small
>project? And might you have a very large iteration size (2 months) on
>a very, very large project? I know there is nothing written in stone
>but I was wondering what the prevailing wisdom was.
I'd do one or two weeks on any project up to around 30 or 40 people at
least.
Even one week feels pretty relentless to a lot of teams. I have worked
in one-day iterations and it was maddening.
Ronald E Jeffries
<newsg...@jhrothjr.com> wrote:
>Well, a good example might be Use Case
>22 from "Writing Effective Use Cases" by
>Alaistar Cockburn. It's almost three
>pages long in the book, the extension
>scenarios themselves are over a page
>and a half. I doubt if any reasonable
>team could implement the main success
>scenario plus the minimum number of
>extensions required to protect all stakeholder's
>interests in one iteration.
But I'll bet without looking at it that I can break it down into
something that looks like value that can be done in a week. (I will
have to look at it to do the breakdown, though. :))
Ronald E Jeffries
<newsg...@jhrothjr.com> wrote:
>It's an insurance claims handling use case. You really
>don't need it - the main point I was trying to make
>is that is was, as such things go, huge, and there was
>no way you could do enough of it in one iteration to
>provide "business value."
What definition of "business value"?
John Roth
> On Sun, 26 Sep 2004 10:10:13 -0500, "John Roth"
> <newsg...@jhrothjr.com> wrote:
>
>>It's an insurance claims handling use case. You really
>>don't need it - the main point I was trying to make
>>is that is was, as such things go, huge, and there was
>>no way you could do enough of it in one iteration to
>>provide "business value."
>
> What definition of "business value"?
Something that can be installed and begin
either creating revenue or reducing costs,
while not creating problems because stakeholder's
interests weren't protected.
John Roth
John Roth
> On Sat, 25 Sep 2004 15:53:07 -0500, "John Roth"
> <newsg...@jhrothjr.com> wrote:
>
>>Well, a good example might be Use Case
>>22 from "Writing Effective Use Cases" by
>>Alaistar Cockburn. It's almost three
>>pages long in the book, the extension
>>scenarios themselves are over a page
>>and a half. I doubt if any reasonable
>>team could implement the main success
>>scenario plus the minimum number of
>>extensions required to protect all stakeholder's
>>interests in one iteration.
>
> But I'll bet without looking at it that I can break it down into
> something that looks like value that can be done in a week. (I will
> have to look at it to do the breakdown, though. :))
Could be. I suspect that it can be done in most
cases, but probably not in all (maybe???)
John Roth
Corey Burnett
>
> We prefer to implement a minimal end-to-end system and
> expand on that. In other words, the first iteration would let
> someone log on, enter some data and get a report.
> It might not validate the user, be very much data, or a
> very big (or useful) report, but it's the skeleton of the
> complete system.
>
> There are a number of reasons for doing it that way,
> among which is that you have to have all of the significant
> technology and interface ducks lined up and quacking
> in synch to do it. It front loads a lot of the technology
> "oops" factors.
>
> End-to-end means all the way out through deployment.
> Each iteration should end one button press (or equivalent)
> away from going live.
>
> It also gives the customer something end to end to look
> at, each and every iteration.
>
> John Roth
This is an interesting approach. But it sounds like if you do that
then you are working on many user stories at once instead of one at a
time. I thought that the process of an iteration involved getting the
detailed requirements for a story, creating acceptance tests, and then
coding that story. Then you move on to the next story. This approach
seems more chaotic in that you are trying to meld a number of stories
together to try and provide a usable, valuable system for each
iteration.
I really wish that there was somewhere that I could go to see the
ACTUAL artifacts from an ACTUAL XP implementation on a complex
project. By artifacts I mean that I would like to see the ACTUAL user
stories that were captured as well as the ACTUAL detailed requirements
and see how the project estimates, velocity, etc. were captured. Kind
of a timeline of the project. I am having difficulty reading the
descriptions of how XP works and then seeing how the heck it would
work on current and past projects of my own.
Corey
Laurent Bossavit
> I really wish that there was somewhere that I could go to see the
> ACTUAL artifacts from an ACTUAL XP implementation on a complex
> project.
Where are you located ? The C2 wiki has a list of some XP or XPish
projects. Make that "lists". Some of the lists are keyed by area.
Laurent Bossavit
> I have to agree here. I can think of lots of systems that I have
> built in the past that only really become usable and valuable to the
> customer when all of the major modules are completed and integrated.
There's a hierarchy of needs involved in coordinating "serious"
projects. Let me add one term : Usable > Valuable > Reviewable. It makes
sense to build a system in small slices that the customer can
independently assess - even if they can't be put to use incrementally.
> Usually it makes sense to start with login first so that is the first
> module I build. After iteration 1 I have a system that you can log
> in to but it doesn't really do anything. So then I build the User
> Management next because you have to be able to add, edit, and delete users.
Who says you "have to" ? If Sales Data Entry is the more important part
of the system, build that first and worry about the relatively simple
issue of managing the user list later.
This order doesn't make sense if you think of software as building a
house, but it does if you think of it as writing a novel (you may start
by writing the ending) or proving a theorem (you may start by stating a
few lemmas that you don't bother proving until the end, because you know
them to be almost trivial compared to the main theorem structure).
Isaac Gouy
> On 26 Sep 2004 14:44:00 -0700, ig...@yahoo.com (Isaac Gouy) wrote:
>
> >> In software development Cost ~= k*Time, since the cost is generally in
> >> the people.
> >
> >Some clients are very interested in getting the software quickly, and
> >are willing to pay. Some have other ideas.
>
> You mean there are clients who would like to pay more, and get the
> software later? I've never encountered any like that.
It's easy to mock, for example - Is that why C3 was closed down?
> >> And no one is very good at controlling the Quality variable, other
> >> than just driving quality down willy-nilly.
> >
> >Ignoring the Quality variable hardly improves the situation.
>
> True, that's why I'd not suggest ignoring it. I'm just pointing out
> that it's not possible to adjust quality up and down in any effective
> way. The bugs just won't go where we want. That's why XP sets the
> quality dial as close to perfect as we can get it.
Ho hum - isn't the product quality set by the customer?
> >> So when we fix cost and scope, we've basically done something unknown
> >> to quality. That seems like a bad idea to me.
> >
> >Not specifying what quality level we are trying to achieve seems like
> >a bad idea to me.
>
> True. That's why we do all that testing, and why we keep all the tests
> running at 100 percent all the time.
No, it's why the quality level must be specified.
("we do all that testing" to demonstrate the specification has been met.)
Ronald E Jeffries
>> True, that's why I'd not suggest ignoring it. I'm just pointing out
>> that it's not possible to adjust quality up and down in any effective
>> way. The bugs just won't go where we want. That's why XP sets the
>> quality dial as close to perfect as we can get it.
>
>Ho hum - isn't the product quality set by the customer?
Ho hum. No. The customer can set the requirements and test for them.
The customer has little control over, and few ways of measuring code
quality and the many other aspects of quality.
My point is that if you were to say "reduce quality and thereby go
faster", you'll get quality degrading in place you didn't intend,
because by reducing the amount of care you put in the system, defects
arise essentially randomly, not just where one imagines one wants
them.
In addition, I've never really encountered anyone who wanted a product
that only sort of worked. I could just be lucky in that regard.
>
>
>> >> So when we fix cost and scope, we've basically done something unknown
>> >> to quality. That seems like a bad idea to me.
>> >
>> >Not specifying what quality level we are trying to achieve seems like
>> >a bad idea to me.
>>
>> True. That's why we do all that testing, and why we keep all the tests
>> running at 100 percent all the time.
>
>No, it's why the quality level must be specified.
>("we do all that testing" to demonstrate the specification has been met.)
What do you mean by "quality level"? Are you familiar with projects
where the customer says things like "Here are 100 tests, you must pass
any 80 to attain a quality level of 80 percent?
Ronald E Jeffries
<newsg...@jhrothjr.com> wrote:
>>>It's an insurance claims handling use case. You really
>>>don't need it - the main point I was trying to make
>>>is that is was, as such things go, huge, and there was
>>>no way you could do enough of it in one iteration to
>>>provide "business value."
>>
>> What definition of "business value"?
>
>Something that can be installed and begin
>either creating revenue or reducing costs,
>while not creating problems because stakeholder's
>interests weren't protected.
Ah. I did have in mind a more broad definition of business value.
If a use case has, say, three parts, and they must all be deployed to
be of use (NPI), you're saying that part 1 has no value, part 2 has no
value, part 3 has no value, but somehow part1 + 2 + 3 has value.
That seems ... unlikly. It seems to me that the individual parts have
value that is unrecognized. And that there are other forms of value,
such as "1/3 done", that aren't being discussed.
Ronald E Jeffries
<newsg...@jhrothjr.com> wrote:
>> But I'll bet without looking at it that I can break it down into
>> something that looks like value that can be done in a week. (I will
>> have to look at it to do the breakdown, though. :))
>
>Could be. I suspect that it can be done in most
>cases, but probably not in all (maybe???)
Maybe not in all. But it's the way to bet.
Isaac Gouy
> >> True, that's why I'd not suggest ignoring it. I'm just pointing out
> >> that it's not possible to adjust quality up and down in any effective
> >> way. The bugs just won't go where we want. That's why XP sets the
> >> quality dial as close to perfect as we can get it.
> >
> >Ho hum - isn't the product quality set by the customer?
>
> Ho hum. No. The customer can set the requirements and test for them.
> The customer has little control over, and few ways of measuring code
> quality and the many other aspects of quality.
Really?
The customer can set requirements for code complexity, inter-module
dependency, system availability, training time to accomplish x tasks,
...
> My point is that if you were to say "reduce quality and thereby go
> faster", you'll get quality degrading in place you didn't intend,
> because by reducing the amount of care you put in the system, defects
> arise essentially randomly, not just where one imagines one wants
> them.
imo Defects arise systematically from process failures.
Or did you mean defects are randomly distributed across the code base?
afaict Defects have a log series distribution - a few code chunks have
many defects and the other chunks have only one or two.
> In addition, I've never really encountered anyone who wanted a product
> that only sort of worked. I could just be lucky in that regard.
We want perfection - we accept less.
Even telcos accept 99.999% availability.
> >> >> So when we fix cost and scope, we've basically done something unknown
> >> >> to quality. That seems like a bad idea to me.
> >> >
> >> >Not specifying what quality level we are trying to achieve seems like
> >> >a bad idea to me.
> >>
> >> True. That's why we do all that testing, and why we keep all the tests
> >> running at 100 percent all the time.
> >
> >No, it's why the quality level must be specified.
> >("we do all that testing" to demonstrate the specification has been met.)
>
> What do you mean by "quality level"? Are you familiar with projects
> where the customer says things like "Here are 100 tests, you must pass
> any 80 to attain a quality level of 80 percent?
Are you familiar with autos that don't have leather seats and walnut
trim?
Laurent Bossavit
> > What do you mean by "quality level"? Are you familiar with projects
> > where the customer says things like "Here are 100 tests, you must pass
> > any 80 to attain a quality level of 80 percent?
>
> Are you familiar with autos that don't have leather seats and walnut
> trim?
It seems that these are different definitions of "quality". Ron is
talking about "conformance to specifications" (à la Phil Crosby), you're
talking about "what I'd like to have if it didn't cost anything".
According to Crosby, if you get leather seats that you didn't specify,
that's a quality shortfall. If you specified plastic seats and you got
that, you have quality.
Ronald E Jeffries
>Ronald E Jeffries <ronje...@acm.org> wrote in message news:<pajpl0tk86pkpbqqh...@4ax.com>...
>
>> >> True, that's why I'd not suggest ignoring it. I'm just pointing out
>> >> that it's not possible to adjust quality up and down in any effective
>> >> way. The bugs just won't go where we want. That's why XP sets the
>> >> quality dial as close to perfect as we can get it.
>> >
>> >Ho hum - isn't the product quality set by the customer?
>>
>> Ho hum. No. The customer can set the requirements and test for them.
>> The customer has little control over, and few ways of measuring code
>> quality and the many other aspects of quality.
>
>Really?
>The customer can set requirements for code complexity, inter-module
>dependency, system availability, training time to accomplish x tasks,
That would be a kind of customer that I've never seen. Sounds more
like a programming manager to me. Most of the customers I'm familiar
with know about some other domain, not programming.
>...
>
>> My point is that if you were to say "reduce quality and thereby go
>> faster", you'll get quality degrading in place you didn't intend,
>> because by reducing the amount of care you put in the system, defects
>> arise essentially randomly, not just where one imagines one wants
>> them.
>
>imo Defects arise systematically from process failures.
Yes. But since the process impacts the whole system, those defects
show up all over. I suppose we could stop using our best process in
areas where we don't mind defects, but I'm not familiar with anyone
who would do that.
>
>Or did you mean defects are randomly distributed across the code base?
>afaict Defects have a log series distribution - a few code chunks have
>many defects and the other chunks have only one or two.
Yes, certainly. But we still cannot generally choose where they'll be
high and where they'll be low. They are random. Not uniformly
distributed, but random.
>
>> In addition, I've never really encountered anyone who wanted a product
>> that only sort of worked. I could just be lucky in that regard.
>
>We want perfection - we accept less.
>Even telcos accept 99.999% availability.
Yes. And most software is way below that standard. I'm not sure what
your point is.
>
>> >> >> So when we fix cost and scope, we've basically done something unknown
>> >> >> to quality. That seems like a bad idea to me.
>> >> >
>> >> >Not specifying what quality level we are trying to achieve seems like
>> >> >a bad idea to me.
>> >>
>> >> True. That's why we do all that testing, and why we keep all the tests
>> >> running at 100 percent all the time.
>> >
>> >No, it's why the quality level must be specified.
>> >("we do all that testing" to demonstrate the specification has been met.)
>>
>> What do you mean by "quality level"? Are you familiar with projects
>> where the customer says things like "Here are 100 tests, you must pass
>> any 80 to attain a quality level of 80 percent?
>
>Are you familiar with autos that don't have leather seats and walnut
>trim?
Yes. But that's a choice of feature, not a choice of quality. And
automobiles are things of manufacture. Software is a thing of design.
Regards,
Andrew McDonagh
And as someone who's works in the telcos, I can tell you that no
software has so few defects as to meet the 99.999 % Availability.
What the software has is fast restart times and processs watch dog
services to restart them 'when' the crash.
Brian S. Smith
I agree with you, Corey, in many respects--and this is not to slight
XP in any way, simply to challenge the claims some XP enthusists make,
the "illusions" of which you speak. Many medium-to-large
systems--think of the Federal Govt, for instance, or major industries
such as Telecomm and Banking, etc., cannot use an incremental
installment of functionality that "plays with" with an existing
system. They want a factory tested, stability tested system that is
ready to phased in to replace an older system. Now the new system may
have its bugs, and patches are expected, but when it's time for
roll-out or deployment, a substantial part of the entire system
typically needs to be ready to "go on-line" and take control--or
interface with--the other systems or subsystems.
Small-to-medium size, application-based, projects lend themselves
better to the XP methodology. I do like the boldness of XP, and it
does integrate proven techniques borrowed from other methodlogies,
such as joint application development (JAD) and use cases (akin to
user "stories") and even pair-programming, but we need to keep an open
mind with every project and match the methodology to the project
demands.
XP is ideal for a project where the customer is not completely sure of
all the functionality the system should have, and is willing to make
these determinations as development progresses.
Responding to Andrew:
Business value is how the application, software system, or IT solution
provides value to the customer. Typically this is manifested in
increased efficiency, where the business is able to expedite the
processing of some data, which often results in a savings of time and
money (enabling a downsizing of the workforce, in many cases), but
which could also result in better interpretation and understanding of
data (for instance, telemetry data for rockets).
--
Brian S. Smith
Leap Systems
http://www.leapse.com
"Turn requirements into object models, instantly, with Leap SE."
.....RAD from the source
Phlip
> I agree with you, Corey, in many respects--and this is not to slight
> XP in any way, simply to challenge the claims some XP enthusists make,
> the "illusions" of which you speak. Many medium-to-large
> systems--think of the Federal Govt, for instance, or major industries
> such as Telecomm and Banking, etc., cannot use an incremental
> installment of functionality that "plays with" with an existing
> system. They want a factory tested, stability tested system that is
> ready to phased in to replace an older system. Now the new system may
> have its bugs, and patches are expected, but when it's time for
> roll-out or deployment, a substantial part of the entire system
> typically needs to be ready to "go on-line" and take control--or
> interface with--the other systems or subsystems.
This is the difference between "release" and "deploy". Each week, a team
must release a program that demonstrates a hypothetical productivity boost.
As often as possible, the project community around the team must deploy the
latest version. Both efforts gain feedback. If deployment must be
infrequent, then releases must still chase hypothetical business value.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Isaac Gouy
-snip-
> > We want perfection - we accept less.
> > Even telcos accept 99.999% availability.
> And as someone who's works in the telcos, I can tell you that no
> software has so few defects as to meet the 99.999 % Availability.
>
> What the software has is fast restart times and processs watch dog
> services to restart them 'when' the crash.
And that's the point.
We gain design freedom when we understand what the required qualities
(and quality levels) actually are: when we understand that "defect
free software" isn't the only approach we can use to reach the
required level of availability.
(And of course, it's not just telcos that take the fast restart
approach.)
Why Do Computers Stop and What Can Be Done About It?
Jim Gray, June 1985
http://www.hpl.hp.com/techreports/tandem/TR-85.7.html
Phlip
> We gain design freedom when we understand what the required qualities
> (and quality levels) actually are: when we understand that "defect
> free software" isn't the only approach we can use to reach the
> required level of availability.
XP projects routinely report defect rates better than <10 bugs in >10
months. Do you have enough experience with defect-free process to know when
to trade-off?
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Robert Grace
Phlip wrote:
> XP projects routinely report defect rates better than <10 bugs in >10
> months. Do you have enough experience with defect-free process to know when
> to trade-off?
I guarantee you if you make a system as complex as a class 5 core switch
that undergoes the testing they do, you'll have more than 10 bugs
in 10 months. Have you power cycled your network 100 times in a row
lately? It's a whole different level.
Andrew McDonagh
I can only tell you what we currently have within our large client
server Network Management System product (OMC-R).
Using XP, we currently have 0 critical (show-stopper), < 10 Major, < 20
Minor.
And 80% of all of those bugs are in areas developed prior to
implementing XP.
Phlip
Another benefit - without bugs in the GUI or Logic layer (where they
traditionally kill the schedule) - you also free up your schedule. You find
time to force all the weird hard bugs to the surface, and kill them too.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Andrew McDonagh
>
> This is the difference between "release" and "deploy". Each week, a team
> must release a program that demonstrates a hypothetical productivity boost.
> As often as possible, the project community around the team must deploy the
> latest version. Both efforts gain feedback. If deployment must be
> infrequent, then releases must still chase hypothetical business value.
>
Cheers couldn't have said it better myself.
Andrew McDonagh
> Andrew McDonagh <ne...@andrewcdonagh.f2s.com> wrote in message news:<cj7gal$mqk$1...@news.freedom2surf.net>...
snipped
>
> Responding to Andrew:
>
> Business value is how the application, software system, or IT solution
> provides value to the customer.
Its also that the customer doesn't spend more money on a lame duck.
There are countless examples where large systems have been paid for,
that have never seen the light of day because they don't fulfill the
customers needs.
XP aims to stop that.
> Typically this is manifested in
> increased efficiency, where the business is able to expedite the
> processing of some data, which often results in a savings of time and
> money (enabling a downsizing of the workforce, in many cases), but
> which could also result in better interpretation and understanding of
> data (for instance, telemetry data for rockets).
>
Yes typically these are some of the manifestations of business value,
but there are also the usual business values of reducing expenditure,
cutting loses, etc, which can be helped if the customer of large scale
systems have more control and insight over the system is developing.
The 'typical' business manifestations you mention are easy for 'typical'
developers and architects to see. The other business values are
'typically' seen by the 'business' people.
Andrew
Robert Grace
Andrew McDonagh wrote:
> I can only tell you what we currently have within our large client
> server Network Management System product (OMC-R).
>
> Using XP, we currently have 0 critical (show-stopper), < 10 Major, < 20
> Minor.
A NMS is nothing like a core switch. Though that's still great.
Scott Kinney
> Brian S. Smith wrote:
> > Andrew McDonagh <ne...@andrewcdonagh.f2s.com> wrote in message
news:<cj7gal$mqk$1...@news.freedom2surf.net>...
>
> snipped
>
> >
> > Responding to Andrew:
> >
> > Business value is how the application, software system, or IT solution
> > provides value to the customer.
>
>
> > increased efficiency, where the business is able to expedite the
> > processing of some data, which often results in a savings of time and
> > money (enabling a downsizing of the workforce, in many cases), but
> > which could also result in better interpretation and understanding of
> > data (for instance, telemetry data for rockets).
> >
>
> Yes typically these are some of the manifestations of business value,
> but there are also the usual business values of reducing expenditure,
> cutting loses, etc, which can be helped if the customer of large scale
> systems have more control and insight over the system is developing.
>
> The 'typical' business manifestations you mention are easy for 'typical'
> developers and architects to see. The other business values are
> 'typically' seen by the 'business' people.
>
Unless the business people/customer can actually see the cost savings,
or count the increased sales, or measure the improvements in cycle time
or number of transactions processed, then there isn't any business value.
That's a difficult and demanding standard to meet, but it's the sine qua non
of
business value.
Isaac Gouy
> > > where the customer says things like "Here are 100 tests, you must pass
> > > any 80 to attain a quality level of 80 percent?
> >
> > Are you familiar with autos that don't have leather seats and walnut
> > trim?
>
> It seems that these are different definitions of "quality". Ron is
> talking about "conformance to specifications" (à la Phil Crosby), you're
> talking about "what I'd like to have if it didn't cost anything".
No, I'm talking about non-functional requirements.
For example ISO9126 & IEEE830 & QFD.
> According to Crosby, if you get leather seats that you didn't specify,
> that's a quality shortfall. If you specified plastic seats and you got
> that, you have quality.
You'd certainly have conformance to spec.
Isaac Gouy
> >Really?
> >The customer can set requirements for code complexity, inter-module
> >dependency, system availability, training time to accomplish x tasks,
>
> That would be a kind of customer that I've never seen. Sounds more
> like a programming manager to me. Most of the customers I'm familiar
> with know about some other domain, not programming.
My impression was that the hydra-headed XP Customer included all
stake-holders, doesn't the XP Customer include IT representatives in
the client organisation?
-snip-
> >We want perfection - we accept less.
> >Even telcos accept 99.999% availability.
>
> Yes. And most software is way below that standard. I'm not sure what
> your point is.
My point is that lower quality can be acceptable.
-snip-
> >> What do you mean by "quality level"? Are you familiar with projects
> >> where the customer says things like "Here are 100 tests, you must pass
> >> any 80 to attain a quality level of 80 percent?
> >
> >Are you familiar with autos that don't have leather seats and walnut
> >trim?
>
> Yes. But that's a choice of feature, not a choice of quality.
We can turn a particular "quality" into a feature by specifying a
quality level that must be met. For example, IS0 9126 lists some
"quality characteristics to be used in the evaluation of software
products".
> And automobiles are things of manufacture. Software is a thing of design.
Isn't this just a little absurd?
Are automobiles not designed before they are manufactured?