The Irony of Extreme Programming
Ronald E Jeffries
Ron Jeffries
04/12/2004
The irony of Extreme Programming is that while detractors continue
to explain why it cannot work, software developers all over the world
are having success with it.
http://www.xprogramming.com/xpmag/jatIronyOfXP.htm
Enjoy ...
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Phlip
> The Irony of Extreme Programming
> Ron Jeffries
> 04/12/2004
>
> The irony of Extreme Programming is that while detractors continue
> to explain why it cannot work, software developers all over the world
> are having success with it.
>
> http://www.xprogramming.com/xpmag/jatIronyOfXP.htm
If they all posted here, they'd drown out the dissent (the same way the
occassional troll gets drowned out on the XP mailing list).
They don't post here, because of the detractors.
--
Phlip
http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces
Laurent Bossavit
> They don't post here, because of the detractors.
I'm not sure about "detractors", per se. It's just Usenet. I was quite
leery of posting anything here at first, and I'm still not convinced the
forum works, in the sense of drawing out the best ideas from all.
Sebastian Stein
wrote:
> The irony of Extreme Programming is that while detractors continue to
> explain why it cannot work, software developers all over the world are
> having success with it.
I think you have to prove it, because it is just a statement. Have you maybe
done a research survey or something like this? Where are the figures I can
check?
Sebastian
--
http://www.hpfsc.de/ - die Seite rund um:
Assembler, Bundeswehr, TFT LCDs, Halle/Saale, Fahrradtouren, Neuseeland,
Wanderstaat Mauma, Raumschiff USS Nathan, Enemy Room, MLCAD Tutorial
Ronald E Jeffries
wrote:
>On Mon, 12 Apr 2004 08:13:04 -0400, Ronald E Jeffries <ronje...@acm.org>
>wrote:
>> The irony of Extreme Programming is that while detractors continue to
>> explain why it cannot work, software developers all over the world are
>> having success with it.
>
>I think you have to prove it, because it is just a statement. Have you maybe
>done a research survey or something like this? Where are the figures I can
>check?
With all due respect, Sebastian, I don't have to prove it. You don't
have to believe it without a research survey or figures, however.
That's OK.
Sebastian Stein
wrote:
>>I think you have to prove it, because it is just a statement. Have you maybe
>>done a research survey or something like this? Where are the figures I can
>>check?
>
> With all due respect, Sebastian, I don't have to prove it.
Right, but how would you try to confince me if you don't prove it? I might
think you can't prove it, it is just marketing talk...
John Roth
"Sebastian Stein" <seb_...@gmx.de> wrote in message
news:1q6rk1-...@laptop-seb.hpfsc.de...
> On Mon, 12 Apr 2004 13:52:26 -0400, Ronald E Jeffries
<ronje...@acm.org>
> wrote:
> >>I think you have to prove it, because it is just a statement. Have you
maybe
> >>done a research survey or something like this? Where are the figures I
can
> >>check?
> >
> > With all due respect, Sebastian, I don't have to prove it.
>
> Right, but how would you try to confince me if you don't prove it? I might
> think you can't prove it, it is just marketing talk...
You can belive what you want. You cannot, however,
control the results of holding that belief.
John Roth
Robert C. Martin
<lau...@dontspambossavit.com> wrote:
>Phlip:
>
>> They don't post here, because of the detractors.
>
>I'm not sure about "detractors", per se. It's just Usenet. I was quite
>leery of posting anything here at first, and I'm still not convinced the
>forum works, in the sense of drawing out the best ideas from all.
You mean you don't think that half the bandwidth should be spent
arguing about whether it's OK to call someone an idiot?
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
Ronald E Jeffries
wrote:
>On Mon, 12 Apr 2004 13:52:26 -0400, Ronald E Jeffries <ronje...@acm.org>
>wrote:
>>>I think you have to prove it, because it is just a statement. Have you maybe
>>>done a research survey or something like this? Where are the figures I can
>>>check?
>>
>> With all due respect, Sebastian, I don't have to prove it.
>
>Right, but how would you try to confince me if you don't prove it? I might
>think you can't prove it, it is just marketing talk...
If you're interested, you'll look into it. If you want to know more,
you'll ask me questions and assess what I say. If you aren't
interested, I have no current need to try to turn you in a different
direction. You're a smart lad, you'll learn things that are useful to
you.
Regards,
Jeff Grigg
>>> Have you maybe done a research survey or something like this?
>>> Where are the figures I can check?
> --- Ronald E Jeffries <ronje...@acm.org> wrote:
>> With all due respect, Sebastian, I don't have to prove it.
--- Sebastian Stein <seb_...@gmx.de> wrote...
> Right, but how would you try to convince me if you don't prove it?
> I might think you can't prove it; it is just marketing talk...
Scientific studies are not the only way to demonstrate the
effectiveness of a technique sufficiently for one to make a rational
and well-informed business decision. In fact, remarkably few business
decisions are made based on the "proven" results of scientific
studies. Also, some scientific studies produce invalid results.
Good business decisions can be based on a number of things.
Including...
1. Trying it, and observing how well it works (or not).
2. Observing others doing it. Visit a team using the technique (or
tool); watch them; talk to them.
3. Talk to people who have used various techniques (or tools). Ask
them how well they worked.
Metrics and numbers are valuable, when you can get them. But full
double-blind scientific studies are expensive and time-consuming.
Their cost may not be justified based on the reduction in risk they
may provide for your business decisions.
Vladimir Levin
good people to do good work. Calling the techniques "extreme" is a
good marketing gimmick, but I don't think there is really anything so
extreme about them. Extreme programming is basically an approach
grounded in common sense: The quality of the people doing the work
matters more than any methods you employ; make sure your
customer/sponsor stays in the loop; test your work and automate those
tests so you have some well defined way to know you application
continues to work as you make changes to it over time; keep your
product in a functional state as you add features; work in short
iterations so your work demonstrates visible progress; keep the
channels of communication open, etc... Perhaps some people's doubts
about extreme programming stem from the very marketing gimmick that
made it popular. While scientific studies to measure the effectiveness
of XP teams ought to continue being done, it seems fairly obvious to
me that extreme programming can't really be a bad thing. Perhaps
another problem is that people believe an all-encompassing process
will yield good results under all conditions. It seems self-evident to
me, with the experience in the industry I've had, that this is simply
impossible. You have to have good people with a can-do, cooperative
attitude (including the management and the customers/sponsors).
Ronald E Jeffries <ronje...@acm.org> wrote in message news:<is1l70h0hjpa6ik7l...@4ax.com>...
Phlip
> I think you have to prove it, because it is just a statement. Have you
maybe
> done a research survey or something like this? Where are the figures I can
> check?
He has witnessed the odds someone detracts goes down as they try a project
for themselves.
--
Phlip
http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces
Randy A. Ynchausti
> Scientific studies are not the only way to demonstrate the
> effectiveness of a technique sufficiently for one to make a rational
> and well-informed business decision. In fact, remarkably few business
> decisions are made based on the "proven" results of scientific
> studies. Also, some scientific studies produce invalid results.
It is unfortunate that there are some scientific studies that produce
invalid results, but this is the reality. However, there are many, many
more personal anecdotes that propitiate invalid results. I selected that
word "propitiate" because it means to gain or regain the favor or goodwill
of ... Humans consistently support ideas and notions that benefit
themselves, but are suboptimal for those around them. Without measurement
and study, those benefits can not be compared to anything and therefore have
no basis. This adds very little value to our profession. It leads to
arguments like:
Person 1: I have metrics that show when two experienced programmers pair,
they produce the same amount of work product that an individual experienced
programmer produces.
Person 2: You can't measure that.
Person 1: I did.
Person 2: Well you can't. It's apples and oranges.
Person 1: So why don't you measure it.
Person 2: Because you can't measure it.
Person 1: How do you know you can't measure it and that it's apples and
oranges? Why don't you just try?
Person 2: Because it can't be measured.
> Good business decisions can be based on a number of things.
Good business decisions are always based on past performance data, sound
experience and some prediction of the future. To the degree that these
three elements are missing, one has to rely only on luck. When one relies
on luck, it's at best a 50/50 proposition; sometimes right and some times
wrong.
> Including...
>
> 1. Trying it, and observing how well it works (or not).
>
> 2. Observing others doing it. Visit a team using the technique (or
> tool); watch them; talk to them.
>
> 3. Talk to people who have used various techniques (or tools). Ask
> them how well they worked.
>
> Metrics and numbers are valuable, when you can get them. But full
> double-blind scientific studies are expensive and time-consuming.
The old, can't measure it agrument! If I could offer a $10,000,000.00 for a
project to measure the performance of XP, I assume there are many who would
compete to win that project. Since I don't have the $10,000,000.00 to
offer, I will offer one big challenge. I challenge every XP enthusiast to
measure and document the cost and benefit of XP in a professional software
development team -- consider it the greatest Open Source project ever and do
it.
As much as I enjoy unit-testing and pair-programming, my data shows that
there is a tradeoff between the quality of code (increases) and the number
of features delivered (decreases). The bad news for all those making
business decisions is that quite often it takes a lot of code quality to
balance against a small number of delivered features. You may not like to
hear that, but this is the reality.
> Their cost may not be justified based on the reduction in risk they
> may provide for your business decisions.
Software development is expensive. Enough measurement can be done to
identify the costs and benefits, expecially when considering how much money
XP enthusiasts quote is being lost by not using XP. Furthermore,
professionals should be able to analyze their processes and identify the
costs and benefits. I dare you!
Regards,
Randy
Sebastian Stein
wrote:
> You can belive what you want. You cannot, however,
> control the results of holding that belief.
I'm not talking about believe. I'm talking about knowledge. Of course you
can not prove a belief - it is impossible e.g. to prove god exists or not.
XP is not a religion I think, so it must be possible to build a prove or at
least some kind argumentation line, why it should work.
Sebastian Stein
> Scientific studies are not the only way to demonstrate the
> effectiveness of a technique sufficiently for one to make a rational
> and well-informed business decision. In fact, remarkably few business
> decisions are made based on the "proven" results of scientific
> studies.
Can you give a percentage value of all remarkably business decisions, who
are not based on scietific studies or theories?
Nevertheless, I don't want to stress this point, you may be right, that
people make good business decisions by their feeling and not based on some
fancy theories. But, and now the big but, you can explore such decisions and
try to understand why they are so remarkable. Let's say XP has shown a great
benefit in software projects. Now I ask, why? Why do the application of the
XP principles improve software development? If we understand the reasons, we
can maybe improve XP further more.
Sebastian Stein
wrote:
> If you're interested, you'll look into it. If you want to know more,
> you'll ask me questions and assess what I say. If you aren't
> interested, I have no current need to try to turn you in a different
> direction. You're a smart lad, you'll learn things that are useful to
> you.
Let me rewrite your initial statement to another notation:
Thesis: Software development can be greatly improved
Condition: by applying XP (described e.g. in "Extreme Programming Explained.
Embrace Change" by K. Beck, 2000)
Prove/Explenation: ???
Suppose you are a consultant selling for example XP training sessions. I'm a
manager of a software production company. You want my money. So you made the
offer to me to improve my software production by applying XP. I ask you to
explain me, why those XP principles should work. I may also ask you what is
meant by "improve software development". Will the software quality be
better, the costs lower and the production faster (better schedules)?
Laurent Bossavit
> As much as I enjoy unit-testing and pair-programming, my data shows that
> there is a tradeoff between the quality of code (increases) and the number
> of features delivered (decreases).
There are two hypotheses that could explain this. One is that these
teams spend more time on quality, and thus have less time to add
features.
A different hypothesis is that the better teams are those who ship
better code *and* less complex software, with more of the features users
actually want and none that they don't want - translating into fewer
features overall.
Data is good, but it's only data; the hard work is determining whether
the data actually supports your hypotheses. Worse, data is usually
theory-laden; research motivated by opposite purposes will often turn up
data supporting opposite conclusions.
Worst of all, *performance* data often has side-effects detrimental to
what it is supposed to measure. Cf. Robert Austin's /Measuring and
Managing Performance in Organizations/.
Ronald E Jeffries
wrote:
>On Mon, 12 Apr 2004 16:28:30 -0400, John Roth <newsg...@jhrothjr.com>
>wrote:
>> You can belive what you want. You cannot, however,
>> control the results of holding that belief.
>
>I'm not talking about believe. I'm talking about knowledge. Of course you
>can not prove a belief - it is impossible e.g. to prove god exists or not.
>XP is not a religion I think, so it must be possible to build a prove or at
>least some kind argumentation line, why it should work.
I'll be happy to explain why it works -- or my opinion on why it
works. Was there somewhere you'd like to start?
Ronald E Jeffries
wrote:
>Let me rewrite your initial statement to another notation:
>
>Thesis: Software development can be greatly improved
>Condition: by applying XP (described e.g. in "Extreme Programming Explained.
>Embrace Change" by K. Beck, 2000)
>Prove/Explenation: ???
This is not equivalent to my initial statement, as I'm sure you are
aware. Just wanted to note that ...
>
>Suppose you are a consultant selling for example XP training sessions. I'm a
>manager of a software production company. You want my money. So you made the
>offer to me to improve my software production by applying XP. I ask you to
>explain me, why those XP principles should work. I may also ask you what is
>meant by "improve software development". Will the software quality be
>better, the costs lower and the production faster (better schedules)?
I am a consultant, and selling is, perhaps unfortunately, what I do
not do. What I do is to provide training and coaching to people who
ask for it.
I also produce hundreds of pages of information every year on what XP
is, how to do it, how it works, and the like. From time to time,
people run across this information, think it might be interesting, and
contact me. This is more like marketing than it is like selling. It's
probably not even very good marketing, but so far I manage to survive.
:)
I have talks of various lengths, elevator length, one hour, half day,
and so on, describing what XP is and why it works. I try only to give
those to people who might be interested.
As it happens, the answers to your last questions are
Yes, XP teams almost uniformly report that the quality they produce
is better than what they themselves produced before. The reason why
this happens, in my opinion, is that generally they improve two
practices which are central to quality: good testing, and good,
continuous, design improvement.
Yes, XP teams generally report lower cost for producing software
than they had before. The reasons, in my opinion, include better focus
on what is really needed (On-site Customer, Planning Game, Small
Releases), higher quality (more testing, less debugging), and keeping
the code flexible (Design Improvement, Refactoring).
Yes, XP teams generally have better schedules than they had before,
owing to the practice of breaking features down into smaller bits,
estimating all of them, and tracking velocity. This induces better
business decisions about which features to include and which ones to
defer.
Yes, XP teams generally produce features faster than they had
before, owing primarily to higher quality (see above) and to better
teamwork with their customers and with each other.
I don't know whether there might be something better than XP: I've
never seen a head-to-head comparison. I do know that every team I've
worked with, or heard of, that tried XP practices found that their
situation improved in terms of quality, cost, and schedule.
Are there other ways to improve? Surely. Is this one? Surely.
Ronald E Jeffries
<randy_y...@msn.com> wrote:
>As much as I enjoy unit-testing and pair-programming, my data shows that
>there is a tradeoff between the quality of code (increases) and the number
>of features delivered (decreases). The bad news for all those making
>business decisions is that quite often it takes a lot of code quality to
>balance against a small number of delivered features. You may not like to
>hear that, but this is the reality.
I produce better code and more features when paired. Might just be me.
Might be something we're doing differently.
Ronald E Jeffries
wrote:
>On 12 Apr 2004 19:28:56 -0700, Jeff Grigg <jgr...@mo.net> wrote:
>> Scientific studies are not the only way to demonstrate the
>> effectiveness of a technique sufficiently for one to make a rational
>> and well-informed business decision. In fact, remarkably few business
>> decisions are made based on the "proven" results of scientific
>> studies.
>
>Can you give a percentage value of all remarkably business decisions, who
>are not based on scietific studies or theories?
In twenty years at ComShare, I saw thousands of business decisions
made, and not one of them ever was based on scientific data or
scientific theory.
Jeff Grigg
>>> Scientific studies are not the only way to demonstrate the
>>> effectiveness of a technique sufficiently for one to make a
rational
>>> and well-informed business decision. In fact, remarkably few
business
>>> decisions are made based on the "proven" results of scientific
>>> studies.
> --- Sebastian Stein <seb_...@gmx.de> wrote:
>> Can you give a percentage value of all remarkably business
decisions, who
>> are not based on scietific studies or theories?
Ronald E Jeffries <ronje...@acm.org> wrote...
> In twenty years at ComShare, I saw thousands of business decisions
> made, and not one of them ever was based on scientific data or
> scientific theory.
I was thinking the same thing. I've been in the business for over 20
years, and my father and I have had many talks about his business
experiences. I've made quite a few business decisions, and seen many
made. I can't recall ever hearing of any business decision made with
any significant input of hard scientific data.
So I'd have to put the number at "below 1%" -- probably some orders of
magnitude below.
On the other hand, I happen to have heard, from reliable sources,
about multi-million dollar business decisions made based on casual
conversation on the golf course, and those based on trinkets
(notepads, pens, etc) left by salesmen. (Not to mention outright
bribes and sexual relations; unfortunate, but they do happen.)
Personally, I'm generally happy to see decent numbers, when we can get
them. But even many of the "hard and fast numbers" I see are very
shaky. What's the objective value of sending Debbie to a SQL class,
to improve her ability to do ad-hoc reports? I'm a firm believer that
this value can be expressed in dollars. But computing this value can
be a bit tricky.
Sebastian Stein
wrote:
>>Thesis: Software development can be greatly improved
>>Condition: by applying XP (described e.g. in "Extreme Programming Explained.
>>Embrace Change" by K. Beck, 2000)
>>Prove/Explenation: ???
>
> This is not equivalent to my initial statement, as I'm sure you are
> aware. Just wanted to note that ...
Yes, I know, but maybe with some minor modification I think you could
support it. Maybe remove the "greatly" in the thesis.
You said you have no surveys to support your statement about developers
having success by applying XP. I didn't want to stress this point, so I
modified the thesis.
> Yes, XP teams almost uniformly report that the quality they produce
> is better than what they themselves produced before. The reason why
> this happens, in my opinion, is that generally they improve two
> practices which are central to quality: good testing, and good,
> continuous, design improvement.
Yes, I would support this. Even more you can say, writing test cases is
doing design.
> Yes, XP teams generally report lower cost for producing software
> than they had before. The reasons, in my opinion, include better focus
> on what is really needed (On-site Customer, Planning Game, Small
> Releases), higher quality (more testing, less debugging), and keeping
> the code flexible (Design Improvement, Refactoring).
I can go with that argument as well. It would be interesting if developing
an application with the same feature set is cheaper to be produced in XP in
comparision to another classical method.
> Yes, XP teams generally have better schedules than they had before,
> owing to the practice of breaking features down into smaller bits,
> estimating all of them, and tracking velocity. This induces better
> business decisions about which features to include and which ones to
> defer.
There might be a danger. By just estimating the small pieces and suming it
up, you will get a too low estimation I think.
> Yes, XP teams generally produce features faster than they had
> before, owing primarily to higher quality (see above) and to better
> teamwork with their customers and with each other.
Here I must ask why they produce features faster? I don't mean they can start
producing features earlier, because of the non-existing analysis and design
steps. Can 2 people doing pair-programming produce more features in the same
time then 2 seperated developers? I am not sure about it.
Sebastian
--
http://www.halle-ist-schoen.de/
Bilddokumentation der schoensten Saalestadt
zwetan
> Let me rewrite your initial statement to another notation:
>
> Thesis: Software development can be greatly improved
> Condition: by applying XP (described e.g. in "Extreme Programming
Explained.
> Embrace Change" by K. Beck, 2000)
> Prove/Explenation: ???
>
> Suppose you are a consultant selling for example XP training sessions. I'm
a
> manager of a software production company. You want my money. So you made
the
> offer to me to improve my software production by applying XP. I ask you to
> explain me, why those XP principles should work. I may also ask you what
is
> meant by "improve software development". Will the software quality be
> better, the costs lower and the production faster (better schedules)?
>
XP is not a product to sell,
XP is a choice to be made by the team of developpers
imho there is nothing to prove, dev try it or not, adopt it or not,
but it's a dev choice not a management choice
zwetan
John Roth
news:407b849d$1...@news.totallyobjects.com...
> Jeff ,
>
> > Scientific studies are not the only way to demonstrate the
> > effectiveness of a technique sufficiently for one to make a rational
> > and well-informed business decision. In fact, remarkably few business
> > decisions are made based on the "proven" results of scientific
> > studies. Also, some scientific studies produce invalid results.
>
> It is unfortunate that there are some scientific studies that produce
> invalid results, but this is the reality. However, there are many, many
> more personal anecdotes that propitiate invalid results. I selected that
> word "propitiate" because it means to gain or regain the favor or goodwill
> of ... Humans consistently support ideas and notions that benefit
> themselves, but are suboptimal for those around them. Without measurement
> and study, those benefits can not be compared to anything and therefore
have
> no basis. This adds very little value to our profession. It leads to
> arguments like:
>
> Person 1: I have metrics that show when two experienced programmers pair,
> they produce the same amount of work product that an individual
experienced
> programmer produces.
>
> Person 2: You can't measure that.
There's a fallacy here that I'm going to deal with in
another post. In this one...
[...]
Let's talk about measurement for a minute.
There's a school of thought that goes: "If you can't measure
it, you don't know what you're talking about."
When you get into measurement, you need to remember that
every measurement has two qualities: precision and accuracy.
If you ask what time it is, and I look out the window, see the
sun is up and reply "daytime," that's a measurement. It has one
bit of precision and one bit of accuracy. (It's probably not all
that useful to you, either, but this is a tutorial, not the real world.)
For the same question, if I look out the window and see where
the shadow cast by the flagpole is, and reply: "12:32 and 46
seconds", that measurement has somewhere around 18 bits
of precision and probably around 4 or 5 bits of accuracy - if
that.
In fact, every statement of observation is a meaurement with
a quantifiable precision and accuracy. I cannot say "blue"
without making a quantifiable statement about color, saturation
and luminance. Of course, both the accuracy and precision
of that statement are rather low.
So let's take a real world question: "how close is this project
to completion? (ignoring risk factors for the moment.) Let's
assume that we have a deliverable in three months, and we're
comparing XP and a typical plan-driven approach (*not*
monolithic waterfall).
XP will deliver the product in 13 one week increments, while
the plan driven approach will deliver at the end of the three
months. The plan-driven project manager can, of course,
always get an answer from his Microsoft Project plan, based
on status reports and so forth.
The plan-driven approach will produce more precise
measurement, but the XP approach will produce more
accurate measurements.
Why? At the end of every week, the XP team will deliver
a production quality, installable product that passes the defined
acceptance tests for more features than the previous week.
That's a measurement that has both accuracy and precision.
The plan-driven manager does not have that measurement
until near the end of the project when everything has been
integrated and acceptance testing has started. All the intermediate
measures have a degree of uncertainty because they involve
intermediate products that either haven't been tested, or
haven't been tested in their final configuration.
This is not to say that the plan-driven project manager's
estimates are completely inaccurate. A competent project
manager has a reasonably good appreciation of how much
of what's been done will have to be reworked once it's been
through the next level of verification and testing.
So let's look at risk factors. There are basically two:
1) Are there unanticipated integration problems?
2) Do the requirements actually meet the customer's needs?
I'm going to ignore the first because it's not unique to
either XP or plan-driven approaches. Both processes
take similar approaches: identify risks and move them
up front where we can assess them.
XP is the clear winner here, since the customer can take
the intermediate products out and test drive them. He
can't do that with the plan-driven project because there
is no intermediate product to test drive.
That's a measurement win, right there.
John Roth
>
> Regards,
>
> Randy
>
>
Isaac Gouy
> >Thesis: Software development can be greatly improved
> >Condition: by applying XP (described e.g. in "Extreme Programming Explained.
> >Embrace Change" by K. Beck, 2000)
> >Prove/Explenation: ???
>
> This is not equivalent to my initial statement, as I'm sure you are
> aware. Just wanted to note that ...
And an essential part of the story is missing.
Consider:
- software can be made faster by implementing in Smalltalk.
- software can be made faster by implementing in Smalltalk, instead of
interpreted Basic.
- software can be made faster by implementing in Smalltalk, instead of
compiled Ada.
"Software development can be greatly improved by applying XP"
implicitly assumes that we are comparing XP with some 'other way of
developing software'.
Once we've identified that 'other way of developing software' we can
begin to wonder about the assertion, until then...
Sebastian Stein
> Once we've identified that 'other way of developing software' we can
> begin to wonder about the assertion, until then...
Right, with the other way I meant a classical method used today.
Isaac Gouy
> >> The irony of Extreme Programming is that while detractors continue to
> >> explain why it cannot work, software developers all over the world are
> >> having success with it.
> >
> >I think you have to prove it, because it is just a statement. Have you maybe
> >done a research survey or something like this? Where are the figures I can
> >check?
>
> With all due respect, Sebastian, I don't have to prove it. You don't
> have to believe it without a research survey or figures, however.
Quite so, it's a question of role.
Ron has taken the role of XP promoter.
Horrible to imagine, but developers all over the world also have
success - whatever that means - with something other than XP.
Wondering whether there's more or less success, and why that might be,
is not the role of a promoter or a detractor.
John Roth
"Isaac Gouy" <ig...@yahoo.com> wrote in message
news:ce7ef1c8.04041...@posting.google.com...
> implicitly assumes that we are comparing XP with some 'other way of
> developing software'.
>
> Once we've identified that 'other way of developing software' we can
> begin to wonder about the assertion, until then...
Speaking broadly, there are only four general approaches
in use today: code and fix, monolithic waterfall, plan driven
and agile.
I don't think anyone is going to dispute the proposition that
XP is going to be an improvement over both code and fix and
monolithic waterfall. So the issue is XP versus plan-driven.
John Roth
Isaac Gouy
> I produce better code and more features when paired.
And you know that because you've measured the quality of code and
number of features, you & your pair produce, with and without pairing?
John Roth
No, but it does beg the question of whether you've done
your homework.
As I said in another post, there are, broadly speaking, only
four methodologies in widespread use: code and fix, monolithic
waterfall, plan-driven and agile. They will all work within
boundaries.
Code and fix will work on a single developer project of less
than a half developer-year that has relatively static requirements
and a competent developer.
Monolithic waterfall will work for projects with an experienced
project manager with stable requirements, a final delivery date
of six months or less and a relatively small team of competent
developers.
Neither scales worth s--t, and neither has any significant tolerance
for requirements instability.
Plan driven methodologies work well on any scale project
given a relatively stable set of requirements, experienced
project management and reasonably competent developers.
Agile methodologies also work on any scale project (although
"by the book XP" doesn't scale) and have a much larger tolerance
for requirements instability. Martin Fowler has an interesting
comment http://martinfowler.com/bliki/VeryLowDefectProject.html
about the possibility of using XP and getting very low defect rates.
As a parting note, have you read "Lean Software Development",
by Mary and Tom Poppendieck? While they don't single out any
particular development methodology, they do give a set of tools
that you can use to find the waste in the popular ones.
John Roth
Jeff Grigg
> Let's talk about measurement for a minute. [...]
>
> When you get into measurement, you need to remember that
> every measurement has two qualities: precision and accuracy.
Let's also consider /relevance/.
Let's say that my project cost $12,672.43 last month. Let's suppose
that this is an accurate and precise figure.
That's nice, but it doesn't help me much with decisions like,
"Should I do more or less xUnit testing?" or
"Should I do more or less Pair Programming?"
Ilja Preuss
> > owing to the practice of breaking features down into smaller bits,
> > estimating all of them, and tracking velocity. This induces better
> > business decisions about which features to include and which ones to
> > defer.
>
> There might be a danger. By just estimating the small pieces and suming it
> up, you will get a too low estimation I think.
An XP team doesn't only estimate the small pieces, it also measures how fast
they actually develop that small pieces and use that data to extrapolate for
the features still to implement.
> > Yes, XP teams generally produce features faster than they had
> > before, owing primarily to higher quality (see above) and to better
> > teamwork with their customers and with each other.
>
> Here I must ask why they produce features faster? I don't mean they can
start
> producing features earlier, because of the non-existing analysis and
design
> steps. Can 2 people doing pair-programming produce more features in the
same
> time then 2 seperated developers? I am not sure about it.
Implementing a feature is creative work. Often with one flash of wit you can
save hours of work. That's more likely to happen when you allow team members
to inspire each other.
Well, that's only part of why it works. I find it somewhat hard to explain
it, but I know that it works, because I am doing it. :)
Cheers, Ilja
Ilja Preuss
> XP is a choice to be made by the team of developpers
Very well said, very well said...
Cheers, Ilja
John Roth
"Jeff Grigg" <jgr...@mo.net> wrote in message
news:c794c0fd.04041...@posting.google.com...
That's true, and I wrote (and deleted) a fairly long screed on
that exact point in response to one of Randy's posts.
John Roth
Ilja Preuss
Regards, Ilja
Ilja Preuss
> to improve her ability to do ad-hoc reports? I'm a firm believer that
> this value can be expressed in dollars. But computing this value can
> be a bit tricky.
And even if it can be done, what's the value of an objective value?
What is the value of the improved motivation because of showing care for the
education of your employees? What is the value of Debbie getting into
contact with new people which might inspire her? What is the value of Tom's
envy because this is Debbie's second class, but he never is allowed to get
one?
I suspect the most important value of computing an objective value is the
illusion of control...
Take care, Ilja
Isaac Gouy
> There's a school of thought that goes: "If you can't measure
> it, you don't know what you're talking about."
This school of thought:
"When you can measure what you are speaking about, and express it in
numbers, you know something about it; but when you cannot measure it,
when you cannot express it in numbers, your knowledge of it is of a
meager and unsatisfactory kind; it may be the beginning of knowledge,
but you have scarcely, in your thoughts, advanced it to the stage of
science."
Sir William Thompson, Lord Kelvin (1824-1907)
Sebastian Stein
>> Suppose you are a consultant selling for example XP training sessions. I'm
> a
>> manager of a software production company. You want my money. So you made
> the
>> offer to me to improve my software production by applying XP. I ask you to
>> explain me, why those XP principles should work. I may also ask you what
> is
>> meant by "improve software development". Will the software quality be
>> better, the costs lower and the production faster (better schedules)?
>
> XP is not a product to sell,
I spoke about XP training sessions. This is indeed a product, the product of
a consultant. Please read my post again and re-think!
> XP is a choice to be made by the team of developpers
>
> imho there is nothing to prove, dev try it or not, adopt it or not,
> but it's a dev choice not a management choice
Are you sure? Who is paying the developers? Who is responsible what happens
with this money?
Isaac Gouy
> > "Software development can be greatly improved by applying XP"
> > implicitly assumes that we are comparing XP with some 'other way of
> > developing software'.
> >
> > Once we've identified that 'other way of developing software' we can
> > begin to wonder about the assertion, until then...
>
> Speaking broadly, there are only four general approaches
> in use today: code and fix, monolithic waterfall, plan driven
> and agile.
>
> I don't think anyone is going to dispute the proposition that
> XP is going to be an improvement over both code and fix and
> monolithic waterfall. So the issue is XP versus plan-driven.
If, for the sake of argument, we accept the list of 4 approaches then
we still seem to be comparing a particular example of "agile" with a
general approach.
Once we've identified the particular example of "plan driven" then
we'll have made some progress. Alternatively we might choose to
compare XP and Scrum, or XP and DSDM, or ...
zwetan
> > XP is not a product to sell,
>
> I spoke about XP training sessions. This is indeed a product, the product
of
> a consultant. Please read my post again and re-think!
if you want to keep considering XP as a product which need promotion to be
sold
ok fine, but you miss totally the point.
the idea you have of selling "XP training sessions" is by nature wrong,
imho devs can only acquire XP by willing to, ok perharps requiring the
assitance
of an experienced XP coach, but the choice of doing XP is much more a
personnal choice of a team amongs tons of other choices.
Only the devs can forsee the potential of XP, it's like choosing OO
programming
or procedural programming for a particular project,
you evaluate the pros and cons, you choose what fit best the project.
So if something as "XP training sessions" was to be sold,
it will not be sold by clueless non-programmers salesman to a clueless
non-programmers manager,
it would be asked by the team of developper to the managment:
"hey boss we need an XP coach for XP training sessions".
But as usual programmers don't wait clueless non-programmers decision to try
new stuff,
will be XP, or anyother programming related stuff.
> > XP is a choice to be made by the team of developpers
> >
> > imho there is nothing to prove, dev try it or not, adopt it or not,
> > but it's a dev choice not a management choice
>
> Are you sure? Who is paying the developers? Who is responsible what
happens
> with this money?
>
Yeah I'm sure, why do programmers get paid ?
to do a job that only them can do because they know how to do it
It's not because anyone now can sit hours in front a computers,
that anyone can be a programmer (or
[replaceWithJobNameWhichRequireYearsToBeGoodAt] etc...).
So if management is clueless about programming they have no other choice
to trust their programmers to pick the correct programming
technic/methdology/etc...
And my personnal rule is to never ever let a non-programmer choose for me,
or my team, the way we gonna develop something, because it's failure
assured.
zwetan
Vladimir Levin
+"plan driven"+"software engineering"+"agile"
Some of the results:
Balancing Plan-Driven and Agile Methods in Software Engineering Project Coursesz
Barry Boehm 1 , Dan Port 1 and A. Winsor Brown
http://www.szp.swets.nl/szp/journals/cs123187.htm
Agile and Plan-Driven Methods Oil and Water?
Barry Boehm, USC
http://www.agileuniverse.com/pdfs/agileAndPlanDrivenMethods
http://www.aw-bc.com/catalog/academic/product/0,4096,0321186125-PRE,00.html
Barry Boehm, Richard Turner
Balancing Agility and Discipline: A Guide for the Perplexed
http://www.computer.org/computer/homepage/0603/GEI/?SMSESSION=NO
Laurie Williams, Alistair Cockburn
Agile Software Development: It's about Feedback and Change
http://www.systemsguild.com/GuildSite/TDM/June2002Computer.pdf
Tom Demarco, Barry Boehm
The Agile Methods Fray
ig...@yahoo.com (Isaac Gouy) wrote in message news:<ce7ef1c8.04041...@posting.google.com>...
Robert C. Martin
We might. However, what I've noticed is that folks who adopt an agile
method don't really care much whether it is XP or FDD, or SCRUM.
Rather, they pick and choose from each of the methods the practices
that they think will fit them well. Thus, I am working with a SCRUM
team that is learning TDD, I am working with an FDD team that is
learning pair programming and TDD. I am working with an XP team that
is using sprints and backlogs from SCRUM.
There is a blending and smearing going on that is blurring the lines
between the methods and resulting in something that is more like a
body of practical knowledge than individual and distinct methods.
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
Robert C. Martin
<randy_y...@msn.com> wrote:
>I challenge every XP enthusiast to
>measure and document the cost and benefit of XP in a professional software
>development team -- consider it the greatest Open Source project ever and do
>it.
It is being done in many different companies and teams. There are a
number of published reports about the effectiveness (and failures) of
XP and Agile methods. There were two this month in Computerworld and
Business week alone. There will be many others presented at Agile
Software Development, and XP/Agile Universe this summer.
The evidence is out there is anyone cares to look. And more is
accumulating all the time.
Robert C. Martin
Of course. Don't you?
Ronald E Jeffries
wrote:
>
>> Yes, XP teams generally have better schedules than they had before,
>> owing to the practice of breaking features down into smaller bits,
>> estimating all of them, and tracking velocity. This induces better
>> business decisions about which features to include and which ones to
>> defer.
>
>There might be a danger. By just estimating the small pieces and suming it
>up, you will get a too low estimation I think.
Why would that be the case? And what would be the effect of tracking
actual velocity of implementation and using that to project end dates,
as we suggest?
Ronald E Jeffries
wrote:
>
>> Yes, XP teams generally produce features faster than they had
>> before, owing primarily to higher quality (see above) and to better
>> teamwork with their customers and with each other.
>
>Here I must ask why they produce features faster? I don't mean they can start
>producing features earlier, because of the non-existing analysis and design
>steps. Can 2 people doing pair-programming produce more features in the same
>time then 2 seperated developers? I am not sure about it.
I find that for me, I produce more features paired than my pair and I
do unpaired. The experimental stats aren't clear but suggest that
paired code takes longer to write, but has fewer defects.
There is more to XP than pairing, and quality is a result of faster
understanding -- conversation instead of passing documents back and
forth; higher quality (less debugging); more flexible scheduling (team
code ownership, pairing), and probably other aspects that don't spring
to mind right this moment.
Ronald E Jeffries
wrote:
>XP is not a product to sell,
>XP is a choice to be made by the team of developpers
>
>imho there is nothing to prove, dev try it or not, adopt it or not,
>but it's a dev choice not a management choice
To really do XP requires management buyin, because of the "on-site
customer" and "customer acceptance tests" and "planning game"
practices.
That said, a team doing just the technical practices can rock.
Regards,
Isaac Gouy
> > Wondering whether there's more or less success, and why that might be,
> > is not the role of a promoter or a detractor.
> No
Good, we agree about that.
> but it does beg the question of whether you've done your homework.
The Waterfall model is so poorly named: Does water flow backwards up
the waterfall? Nope. Yet Royce's 1970 Waterfall model included
iteration within a phase (maybe he was thinking of whirlpools) and
stepping back to a previous phase.
From the name we might think it was the same as Benington's 1956
Stagewise model.
Anyway, by '80 V&V was vital and the Waterfall was diverted into the V
model. (Req, and Spec, and Design, linking to Test phases through Test
plans like this: http://www.informatik.uni-bremen.de/uniform/gdpa/def/def_v/V_MODEL.htm
)
With Boehm's '85 Spiral model we understood that the V model, and
prototyping, and evolutionary delivery, and incremental delivery were
different ways that this meta-model could unwind.
By '90 we would stress that these "are not the only possible models
and they are not to be followed rigidly. They are simply particular
examples" and then talk of blending prototyping with the V model with
incremental delivery, to meet the needs of a specific situation.
> Plan driven methodologies work well on any scale project
> given a relatively stable set of requirements, experienced
> project management and reasonably competent developers.
Are you saying that you know of an approach that succeeds with
inexperienced project management and incompetent developers?!
> Agile methodologies also work on any scale project (although
> "by the book XP" doesn't scale) and have a much larger tolerance
> for requirements instability.
Seems like "by the book XP doesn't scales" contradicts "Agile... work
on any scale"?
Wouldn't a "plan driven" approach operating a one week plan have a
large tolerance for requirements instability?
Ronald E Jeffries
I know it because I pay attention to how long it takes me to do
things, how much debugging I have to do, how often I'm down a rathole.
Ronald E Jeffries
<newsg...@jhrothjr.com> wrote:
>Let's talk about measurement for a minute.
Nice, John. This needs to be an article somewhere.
Ronald E Jeffries
How much do you love your spouse, your kids if any, your parents?
Ronald E Jeffries
>Ronald E Jeffries <ronje...@acm.org> wrote in message news:<opll7050qnelf46n2...@4ax.com>...
>
>> >> The irony of Extreme Programming is that while detractors continue to
>> >> explain why it cannot work, software developers all over the world are
>> >> having success with it.
>> >
>> >I think you have to prove it, because it is just a statement. Have you maybe
>> >done a research survey or something like this? Where are the figures I can
>> >check?
>>
>> With all due respect, Sebastian, I don't have to prove it. You don't
>> have to believe it without a research survey or figures, however.
>
>Quite so, it's a question of role.
>Ron has taken the role of XP promoter.
Not quite, my friend. I also help people who are interested in
improving their software development results, and I'm fairly good at
it.
>
>Horrible to imagine, but developers all over the world also have
>success - whatever that means - with something other than XP.
Quite true. But few of them have success without doing many of the
same things, I find. And most of the ones I run into could improve in
some key areas, most often testing, and design improvement.
>
>Wondering whether there's more or less success, and why that might be,
>is not the role of a promoter or a detractor.
Perhaps not. But I do wonder, and I pay attention. What I don't do is
prove.
Isaac Gouy
> >This school of thought:
> >"When you can measure what you are speaking about, and express it in
> >numbers, you know something about it; but when you cannot measure it,
> >when you cannot express it in numbers, your knowledge of it is of a
> >meager and unsatisfactory kind; it may be the beginning of knowledge,
> >but you have scarcely, in your thoughts, advanced it to the stage of
> >science."
> >
> >Sir William Thompson, Lord Kelvin (1824-1907)
>
> How much do you love your spouse, your kids if any, your parents?
Love is immeasurable, so software development must be immeasurable too?
Confusion worse confounded.
Isaac Gouy
> On 13 Apr 2004 08:58:24 -0700, ig...@yahoo.com (Isaac Gouy) wrote:
>
> >Ronald E Jeffries <ronje...@acm.org> wrote in message news:<9jdn70hlgej0smde9...@4ax.com>...
> >
> >> I produce better code and more features when paired.
> >
> >And you know that because you've measured the quality of code and
> >number of features, you & your pair produce, with and without pairing?
>
> I know it because I pay attention to how long it takes me to do
> things, how much debugging I have to do, how often I'm down a rathole.
Is "paying attention" the same as measuring and recording, or is it
more... intuitive?
Isaac Gouy
> >> I produce better code and more features when paired.
> >
> >And you know that because you've measured the quality of code and
> >number of features, you & your pair produce, with and without pairing?
>
> Of course. Don't you?
Sometimes, sometimes not.
So you have measurements for the work y'all did on Fitnesse?
Randy A. Ynchausti
> > As much as I enjoy unit-testing and pair-programming, my data shows that
> > there is a tradeoff between the quality of code (increases) and the
number
> > of features delivered (decreases).
>
> There are two hypotheses that could explain this. One is that these
> teams spend more time on quality, and thus have less time to add
> features.
Sorry to single your post out, Laurent, for a response. I am not picking on
you. Your post happened to be the first of all the responses to my post in
my browser. I have not read a single response of the many respondents that
dealt with the point that is important to me (and I believe to every
software development team [although not to consultants]). With the possible
exception of Ron's claim to have data that shows he delivers more
features/code when he pairs (the data I have for various developers does not
support this conclusion), although I fully support and practice the notion
of tracking one's own performance (I have been laughed at by many several
times when I posted the metrics that I track). The point is that one has to
make a business decision. The question to decide upon is:
How many features are equivalent to how much quality?
If you give up three features, how much quality does it take to make up for
those features? If quality is, "Meeting the customer's expectations," then
to optimize the software development process you only need as much quality
as is required to make the customer happy. At that point, a team should
maintain quality and focus on delivering features. Absolute quality is a
lofty altruistic goal, but it is way beyond the mark in terms of running a
software development business.
GE had this problem several years ago. They had the altruistic goal of
being number 1 or 2 in their product-business domain. The problem was that
they could define the "product-business" domain in ways that guaranteed they
were 1 or 2. Until a consultant came in and reframed their thinking, they
thought they were doing the best they could because they had the "best" goal
that any corporation could have. User stories, unit-test and
pair-programming can be gamed the same way GE gamed their product-business
domain. These software development practices are even more at risk without
any analytical tools and yardsticks.
You need data, experience and good forecasting to answer the business
question that I posed above for a given software development project. From
the data I have, it is very likely that the optimal development rate is one
that includes part-time (15% - 35%) pair-programming and full-time
unit-testing.
By the way Ron, there is a much better article in meeting my earlier
challenge.
Regards,
Randy
Sebastian Stein
wrote:
>>> Yes, XP teams generally have better schedules than they had before,
>>> owing to the practice of breaking features down into smaller bits,
>>> estimating all of them, and tracking velocity. This induces better
>>> business decisions about which features to include and which ones to
>>> defer.
>>
>>There might be a danger. By just estimating the small pieces and suming it
>>up, you will get a too low estimation I think.
>
> Why would that be the case? And what would be the effect of tracking
> actual velocity of implementation and using that to project end dates,
> as we suggest?
As I said, I'm not sure about it. I think in XP the problem is dealt with by
the factor you multiplicate. Let's say you have 2 tasks each needing 4
hours. Now you would think a pair could implement this in one day. But after
finishing task 1, they maybe go out smoking or have to wait till they can
switch the pair. This extra time is not in the estimates. Maybe they have to
wait to get access to the integration computer (if they don't use CVS). Just
looking at the tasks, I think you would miss such breaks. Nevertheless, this
could be handled I think.
Sebastian Stein
>> I spoke about XP training sessions. This is indeed a product, the product
> of
>> a consultant. Please read my post again and re-think!
>
> if you want to keep considering XP as a product which need promotion to be
> sold ok fine, but you miss totally the point.
I'm not sure if you are joking or really mean what you are saying.
Nevertheless, I try again to explain my thoughts to you.
> the idea you have of selling "XP training sessions" is by nature wrong,
> imho devs can only acquire XP by willing to, ok perharps requiring the
> assitance of an experienced XP coach, but the choice of doing XP is much
> more a personnal choice of a team amongs tons of other choices.
Well, think about a normal programmer and not the techie hacker. He is not
interested in developments going on in the software community. He just wants
to do his job. So he has never heard about XP or other agile methods. Now
the management and/or the development team has choosen to go with XP. He
never heard about it. Of course you can say he should read a book or scan
the internet for articles. Nevertheless, reading is one of the most
ineffective learning methods. So he would be glad to have someone explaining
the concept to him. This could be someone in the company, but it can also be
someone from outside like a consultant.
> So if something as "XP training sessions" was to be sold, it will not be
> sold by clueless non-programmers salesman to a clueless non-programmers
> manager, it would be asked by the team of developper to the managment:
> "hey boss we need an XP coach for XP training sessions".
Yes, I never said something else.
>> Are you sure? Who is paying the developers? Who is responsible what
>> happens with this money?
>>
>
> Yeah I'm sure, why do programmers get paid ?
>
> to do a job that only them can do because they know how to do it
>
> ...
>
> So if management is clueless about programming they have no other choice
> to trust their programmers to pick the correct programming
> technic/methdology/etc...
Right, the development team has to choose the technic/../.. But it is a
management task to accept the choice and implement it. A switch from a
classical development process to an agile one is a high-risk step. If you
fail you can loose a lot of money and customers. The management is
responsible for the money and not the techie developer.
Of course you can say management is just interested things getting done.
They don't care how the software is developed. But, working with XP in
development needs other contracts to your customers. At least you should fix
the on-side customer in the contract. Contracts are not a task of the
developers, it is a task of management. Also think about the tasks people do
in XP. You need a lot more programmers. Maybe some people have to switch
from an analysis and design position back to a programmer position, because
analysis and design people are not that much needed. At least right here in
Germany you have change the working contract with those people. This is,
once again, a task of management and not of the techie hacker.
To sum it up, and I really hope you can live with that, switching to XP is a
task of management and development team and not just the task of the
development team.
Ilja Preuß
If you can know something without objectively measuring it, perhaps there
are other things for which it can work, too?
Take care, Ilja
John Roth
news:ce7ef1c8.04041...@posting.google.com...
> > Plan driven methodologies work well on any scale project
Jeff Grigg
>> I challenge every XP enthusiast to measure and document the cost
>> and benefit of XP in a professional software development team --
>> consider it the greatest Open Source project ever and do it.
One needs more than just lots of raw numbers. One needs comparable
numbers.
--- Robert C. Martin <uncl...@objectmentor.com> wrote...
> It is being done in many different companies and teams. There are a
> number of published reports about the effectiveness (and failures) of
> XP and Agile methods. There were two this month in ComputerWorld and
> Business week alone. There will be many others presented at Agile
> Software Development, and XP/Agile Universe this summer.
>
> The evidence is out there is anyone cares to look. And more is
> accumulating all the time.
I posted some numbers to this list late last month:
- project schedule reduced 30%.
- project cost reduced by 50% to 75%.
The reduction in risk and bugs (number and severity) and improvement
in quality and maintainability were there, but I did not have metrics
for them.
John Roth
> inexperienced project management and incompetent developers?!
Spoken with a bit of tongue in cheek - XP! There is at least
one university program where the professors prefer to use XP
for the first semester long class project, and save RUP (as an
introduction to plan driven) for the second. The reason? You can
get a running result with XP while the RUP project tends to fail
without any result. Of course, the actual code produced by the
novices should be taken out and buried...
>
> > Agile methodologies also work on any scale project (although
> > "by the book XP" doesn't scale) and have a much larger tolerance
> > for requirements instability.
>
> Seems like "by the book XP doesn't scales" contradicts "Agile... work
> on any scale"?
Agile includes Scrum, Crystal, DSDM and several others I
don't remember. Also, "by the book XP" refers to the version
defined for a single colocated team of not more than 12 developers.
There is a set of principles (Chapter 8, p 37 of the White Book) that
you can use to generate something that looks like XP for just about
any environment or size of project. I haven't seen it done (possibly
because most people don't know about the principles - they fixate
on either the values or the practices.)
> Wouldn't a "plan driven" approach operating a one week plan have a
> large tolerance for requirements instability?
That is, I think, a contradiction. What's missing is the ability
to handle the requirements backlog in a sensible fashion.
With three or four months between releases you don't
have to do any significant backlog management; with
iterations or sprints that short you need a reasonably
coherent way of managing it, which means you need
to either split requirements analysis the way Scrum and
XP do, or you need to do requirements analysis up front.
With a one week time box, you don't have the ability
to do a formal requirements analysis, get it reviewed,
approved, and then do the design, get it reviewed,
approved, and so forth. By the time you ditch all the
heavyweight aspects to get something done in one week,
you might as well be doing code and fix.
John Roth
Laurent Bossavit
> Sorry to single your post out, Laurent, for a response. I am not picking on
> you.
No problem. I appreciate you for engaging. I won't pick on you, either,
just insist on your being responsive to the points I raised. :)
> I have not read a single response of the many respondents that
> dealt with the point that is important to me (and I believe to every
> software development team [although not to consultants]).
I'd like to be responsive to your concerns, too. Before I can do that, I
have to take issue with that last parenthetical point. Perhaps we don't
mean the same thing by "consultant" - it's a vague and overused term -
but when I act as advisor to a software development team, whatever
issues matter to them are issues that matter to me. I take that to be
part of being a good advisor, or consultant as I understand the term.
Now, to try and address your question:
> How many features are equivalent to how much quality?
There's a classic reductio ad absurdum which goes: "I can deliver a
product with as many features as you care to name, and have it ready
tomorrow... as long as it doesn't have to work."
I don't think you can trade off one for the other, though I will try to
answer your question in terms of things that can be traded off for each
other. A prior discussion on the topic is recorded here:
http://c2.com/cgi/wiki?CommitmentToQuality
Quality is a problematic term, so the discussion may need a more precise
context and some (at least provisional) definitions.
A software development effort consists of automating some operations
which are relevant to some business purpose, within a finite budget in
terms of time and money.
There are typically three consequences of "low quality": a) the
operations which are implemented turn out not to be relevant to the
purpose of the effort; b) the operations turn out to have been
implemented unreliably, which jeopardizes the purpose of the effort; and
c) during development, rework due to implementation defects delay the
effort and cause it to exceed budget.
As far as problems a) and c) are concerned, there is no trade-off
between quality and features. If you only deliver relevant features, and
do not experience (unpredictably) lengthy test-and-debug cycles, then
your project will cost less and produce more.
I can see how a trade-off situation could be constructed with respect to
problem b). For instance, we are building a credit system which reduces
the cost of processing an application from $100 to $10, and it might
cost $10 million to build a system which makes one mistake every 1000
applications, versus $1 million for one which makes one mistake every
10. I gather such trade-offs are common in industrial processes.
One problem I see is that software bugs are rarely that straightforward.
Rather than mess up one operation per 1000, they will quietly lurk for a
million operations, then blow up the entire system and cause damages in
the millions or billions of dollars. Examples include the Ariane Bug or
the more recent Blackout Bug.
Another issue is that problems of type b) and problems of type c) are
obviously correlated (and probably type a) as well). If you tend to have
some bugs in production, then you have even more bugs that pop up during
the development process, and delay it by usually unpredictable amounts.
> If you give up three features, how much quality does it take to make up for
> those features?
If you give up three features you didn't need, then overall quality will
be higher and your costs will go down. Conversely, increased quality
might mean shorter test-and-debug cycles, which in turn means more time
available to implement features you do need.
> With the possible exception of Ron's claim to have data that shows he
> delivers more features/code when he pairs (the data I have for various
> developers does not support this conclusion),
I don't think Ron said these were his conclusions; he said they were his
observations - his data if you prefer.
Data matters, but so do the models or theories which make sense of the
data. Lord Kelvin had "scientific" data on the age of the Earth, yet the
conclusions he reached were wrong. Nor, it seems, was his interest in
that particular problem motivated by purely "scientific" motives. The
conclusions were wrong because there were things he didn't know about
the system he was studying which made the data irrelevant.
> Absolute quality is a lofty altruistic goal, but it is way beyond the mark
> in terms of running a software development business.
I don't think anyone here is advocating "absolute" quality, whatever
that means. I do think that a maintainable, well-factored system with no
avoidable defects or egregious failures is an economical goal.
> From the data I have, it is very likely that the optimal development
> rate is one that includes part-time (15% - 35%) pair-programming and
> full-time unit-testing.
Optimal in what contexts ? Optimal on what dimension ?
When you say "part-time", you mean relative to what total ? "Body time"
(hours in the office), total time spent at the keyboard, total time
spent on implementation tasks ?
Isaac Gouy
> >>> This school of thought:
> >>> "When you can measure what you are speaking about, and express it in
> >>> numbers, you know something about it; but when you cannot measure
> >>> it,
> >>> when you cannot express it in numbers, your knowledge of it is of a
> >>> meager and unsatisfactory kind; it may be the beginning of
> >>> knowledge,
> >>> but you have scarcely, in your thoughts, advanced it to the stage of
> >>> science."
> >>>
> >>> Sir William Thompson, Lord Kelvin (1824-1907)
> >>
> >> How much do you love your spouse, your kids if any, your parents?
> >
> > Love is immeasurable, so software development must be immeasurable
> > too?
>
> If you can know something without objectively measuring it, perhaps there
> are other things for which it can work, too?
Kelvin had that covered: "your knowledge of it is of a meager and
unsatisfactory kind".
Most prefer to maintain the mystery of Love & Faith.
Why would someone prefer to make software development mysterious?
Ronald E Jeffries
wrote:
>On Tue, 13 Apr 2004 21:37:26 -0400, Ronald E Jeffries <ronje...@acm.org>
>wrote:
>>>> Yes, XP teams generally have better schedules than they had before,
>>>> owing to the practice of breaking features down into smaller bits,
>>>> estimating all of them, and tracking velocity. This induces better
>>>> business decisions about which features to include and which ones to
>>>> defer.
>>>
>>>There might be a danger. By just estimating the small pieces and suming it
>>>up, you will get a too low estimation I think.
>>
>> Why would that be the case? And what would be the effect of tracking
>> actual velocity of implementation and using that to project end dates,
>> as we suggest?
>
>As I said, I'm not sure about it. I think in XP the problem is dealt with by
>the factor you multiplicate. Let's say you have 2 tasks each needing 4
>hours. Now you would think a pair could implement this in one day. But after
>finishing task 1, they maybe go out smoking or have to wait till they can
>switch the pair. This extra time is not in the estimates. Maybe they have to
>wait to get access to the integration computer (if they don't use CVS). Just
>looking at the tasks, I think you would miss such breaks. Nevertheless, this
>could be handled I think.
Sebastian, your recent remarks are making me think that you haven't
looked very deeply into XP at all. If that's the case, I'd
respectfully suggest that you'll profit from just a tiny bit more
study and a bit less speculation about it.
For example here, we don't multiply by a factor (though in early days
we did consider what we called "load factor") but instead we just
track how long it takes to do the story. So if it is a story of
dificulty 2, we expect that other stories of d=2 will take about the
same amount of time. That turns out to be sufficient, and quite
effective, for tracking and predicting.
I'm delighted to explain as much as I can here, of course.
Regards,
Ronald E Jeffries
More intuitive. Does that trouble you?
Ronald E Jeffries
No. It's just that there's more than one way to "measure". Do you have
enough in your pocket right now to take me to lunch? Don't look, don't
count. Just remember.
Isaac Gouy
> Speaking broadly, there are only four general approaches
> in use today: code and fix, monolithic waterfall, plan driven
> and agile.
Speaking broadly, there's a continuum.
"Figure 1. The planning spectrum. Unplanned and undisciplined hacking
occupies
the extreme left, while micromanaged milestone planning, also known as
inchpebble planning, occupies the extreme right."
Get Ready for Agile Methods, with Care
http://www2.umassd.edu/SWPI/xp/papers/r1064.pdf
Isaac Gouy
-snip-
> The plan-driven approach will produce more precise
> measurement, but the XP approach will produce more
> accurate measurements.
Precision vs accuracy really doesn't add anything to the story.
The underlying assumption is that each approach uses a different kind
of measurement to estimate project completion. We say that XP uses
measurements of delivered features, and then we say that "plan driven"
uses measurements of intermediate untested work products.
We're just assuming that the "plan driven" approach uses a longer
iteration period.
Isaac Gouy
> >Love is immeasurable, so software development must be immeasurable too?
> >Confusion worse confounded.
>
> No. It's just that there's more than one way to "measure". Do you have
> enough in your pocket right now to take me to lunch? Don't look, don't
> count. Just remember.
Did you have enough money in your pocket on Monday 14 April 2004 11:29AM PST?
Monday 14 April 2003 11:29AM PST? Just remember.
Isaac Gouy
> >> >> I produce better code and more features when paired.
> >> >
> >> >And you know that because you've measured the quality of code and
> >> >number of features, you & your pair produce, with and without pairing?
> >>
> >> I know it because I pay attention to how long it takes me to do
> >> things, how much debugging I have to do, how often I'm down a rathole.
> >
> >Is "paying attention" the same as measuring and recording, or is it
> >more... intuitive?
>
> More intuitive. Does that trouble you?
Not in the least.
Perhaps it would have been more straightforward to answer the original
question like this: "I know it based on what I can remember, not on
what I've measured."
Isaac Gouy
> >Quite so, it's a question of role.
> >Ron has taken the role of XP promoter.
>
> Not quite, my friend. I also help people who are interested in
> improving their software development results, and I'm fairly good at
> it.
We all play many roles in a variety of situations.
I was commenting on the role you take in these forums.
-snip-
> >Wondering whether there's more or less success, and why that might be,
> >is not the role of a promoter or a detractor.
>
> Perhaps not. But I do wonder, and I pay attention. What I don't do is
> prove.
That's not very Test Driven ;-)
Ronald E Jeffries
On the contrary. I try things, I observe whether they work. If they
do, I do it again. If they don't, I don't.
Randy A. Ynchausti
> > If you give up three features, how much quality does it take to make up
for
> > those features?
>
> If you give up three features you didn't need, then overall quality will
> be higher and your costs will go down. Conversely, increased quality
> might mean shorter test-and-debug cycles, which in turn means more time
> available to implement features you do need.
Qualifying the three features as features you didn't need is an example of
the gaming that I mentioned when referring to GE in an earlier post. So I
will restate the same question with a few more definitives. If you give up
three features that you really need right now, but don't have enough time or
money to have pairs of programmers work on, how much quality do the
pair-programmers have to generate to make up for those features?
Here is my latest data point (without the data and names so I won't offend
anyone). In January, a pair of developers on our team (not me), who enjoy
pair-programming and unit-testing, began pair-programming and unit-testing
work on feature changes to a large enterprise application to accommodate
some government regulation that take effect during mid-April. Mid February
they stopped pair-programming and unit-testing because they weren't making
enough progress and would not be able to deliver the feature set on time.
After two more months of very intense, hard work individual-programming,
they are delivering the feature set. It is obvious that they were right --
they could not have delivered the features if they continued to
pair-program.
The question is:
If the XP process lets two experienced developers get more done when
pair-programming as compared to working on tasks in parallel, why did they
feel they had to abandon the process to deliver the feature set?
The answer is:
The process doesn't let two experienced developers pair-program together for
one hour (spending two man-hours) and yield two man hours worth of work
product (code/features). That is just break even anyway, although it would
be better if the code quality is better, which it probably would be better.
I believe that there are some out there, who will start gaming this latest
data-point to explain how these two developers are novices at the XP
practices, genetically deficient, etc. Let me assure you that these are two
of the most talented and knowledgeable developers on staff. Both are
team-lead-level developers. They pair together quite well. It would have
been nice for the company to spend the money to have both working on the
same code, but real-world business did not allow for this luxury. This
real-world data-point, I hope, gives you a better understanding of what I
mean when I say that what is optimal for a couple of developers may not even
be close to what is optimal for the corporation. I hope it also provides a
real-world example of trading code quality for features and vice versa. In
the end, the two developers did what was right for the corporation, even
though many in the corporation were telling them to stick with
pair-programming, which is what would have been most beneficial to them
personally.
Regards,
Randy
Robert C. Martin
Of course. We have velocity measurements, coverage measurements,
acceptance and unit test measurements. I could probably infer coding
rates from the data if I wanted to.
I've already posted some of that data here. Perhaps I'll write an
article about the project one day.
-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716
"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker
Robert C. Martin
>The Waterfall model is so poorly named: Does water flow backwards up
>the waterfall? Nope. Yet Royce's 1970 Waterfall model included
>iteration within a phase (maybe he was thinking of whirlpools) and
>stepping back to a previous phase.
Royce's paper is the antithesis of what Waterfall has become. As you
say, Royce made the point that the activities could not be conducted
in phases. He separated the activities in concept, but not in time.
His diagram with arrows going in both directions simply means that the
activities will be concurrent.
Royce went on to say that one pass through all the activities isn't
enough. He recommended going through them twice or more. With just
one more little push, he'd have written a paper about iterative and
incremental development.
But that's not what we saw when we read that paper thirty four years
ago. What we saw instead was phases with dates. How we saw that I
can't say.
Gawnsoft
<lau...@dontspambossavit.com> wrote (more or less):
>Data matters, but so do the models or theories which make sense of the
>data. Lord Kelvin had "scientific" data on the age of the Earth, yet the
>conclusions he reached were wrong. Nor, it seems, was his interest in
>that particular problem motivated by purely "scientific" motives. The
>conclusions were wrong because there were things he didn't know about
>the system he was studying which made the data irrelevant.
When you say ' "scientific" ', I think you mean ' scientific '. His
data was neither unscientific nor irrelevant. It was, as you do say,
incomplete for his task (i.e. none of his calculations or data took
account of the effect of continual radioactive heating of the Earth's
core).
Cheers,
Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki: http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk
Ronald E Jeffries
<randy_y...@msn.com> wrote:
>Laurent,
>
>> > If you give up three features, how much quality does it take to make up
>for
>> > those features?
>>
>> If you give up three features you didn't need, then overall quality will
>> be higher and your costs will go down. Conversely, increased quality
>> might mean shorter test-and-debug cycles, which in turn means more time
>> available to implement features you do need.
>
>Qualifying the three features as features you didn't need is an example of
>the gaming that I mentioned when referring to GE in an earlier post. So I
>will restate the same question with a few more definitives. If you give up
>three features that you really need right now, but don't have enough time or
>money to have pairs of programmers work on, how much quality do the
>pair-programmers have to generate to make up for those features?
We'll see. If they introduce few enough defects, or if you spend
enough time in QA and fixing to remove them, then you'll wind up
ahead. If in their zeal to go faster, they introduce too many defects,
it will come back to bite you.
If they produce good enough code alone to keep their velocity high
over the duration of the project, then you'll wind up ahead. If in
programming alone, they leave the code in worse shape, or there is a
lot of code where at most one of them can work on it, the project will
slow down.
It's a judgment call.
>
>Here is my latest data point ... It is obvious that they were right --
>they could not have delivered the features if they continued to
>pair-program.
I'll take that as given. Would be interesting to see the feature
delivery data, velocity info, etc ...
And I'm wondering whether other practices were slacked on as well. In
similar situations, I've seen teams also back off on unit tests and
acceptance tests and refactoring. They left some serious junk behind.
What happened in the case you are reporting, on those dimensions?
>
>The question is:
>
>If the XP process lets two experienced developers get more done when
>pair-programming as compared to working on tasks in parallel, why did they
>feel they had to abandon the process to deliver the feature set?
Seems clear that in this case, they were faster separately. Perhaps
the results were good enough, as discussed above, perhaps they were
not. I hope you'll come back and tell us what you learn about defects
and such after the thing ships.
>
>The answer is:
>
>The process doesn't let two experienced developers pair-program together for
>one hour (spending two man-hours) and yield two man hours worth of work
>product (code/features). That is just break even anyway, although it would
>be better if the code quality is better, which it probably would be better.
Yes ...
>
>I believe that there are some out there, who will start gaming this latest
>data-point to explain how these two developers are novices at the XP
>practices, genetically deficient, etc. Let me assure you that these are two
>of the most talented and knowledgeable developers on staff. Both are
>team-lead-level developers. They pair together quite well. It would have
>been nice for the company to spend the money to have both working on the
>same code, but real-world business did not allow for this luxury. This
>real-world data-point, I hope, gives you a better understanding of what I
>mean when I say that what is optimal for a couple of developers may not even
>be close to what is optimal for the corporation. I hope it also provides a
>real-world example of trading code quality for features and vice versa. In
>the end, the two developers did what was right for the corporation, even
>though many in the corporation were telling them to stick with
>pair-programming, which is what would have been most beneficial to them
>personally.
Well, not shipping on time is not beneficial to me personally, so I'm
not clear what you mean by most beneficial.
I'd like to see the velocity data, and I hope you'll keep an eye on
quality issues and see what you can figure out about defect density in
the paired and unpaired code.
Regards,
Sebastian Stein
wrote:
> Sebastian, your recent remarks are making me think that you haven't
> looked very deeply into XP at all. If that's the case, I'd
> respectfully suggest that you'll profit from just a tiny bit more
> study and a bit less speculation about it.
Yes, I have not looked much into the field of estimation, because it is not
important for me at the moment. I'm more interested in the general approach
and the core principles behind. Estimation is just one detail...
> For example here, we don't multiply by a factor (though in early days
> we did consider what we called "load factor") but instead we just
> track how long it takes to do the story. So if it is a story of
> dificulty 2, we expect that other stories of d=2 will take about the
> same amount of time. That turns out to be sufficient, and quite
> effective, for tracking and predicting.
This sounds good. In other words you classify the tasks and you moved to
discreet estimates.
Ilja Preuß
> "Ilja Preuß" <pre...@disy.net> wrote in message
> news:<c5j0p0$6qj$1...@stu1id2.ip.tesion.net>...
>
>>>>> This school of thought:
>>>>> "When you can measure what you are speaking about, and express it
>>>>> in
>>>>> numbers, you know something about it; but when you cannot measure
>>>>> it,
>>>>> when you cannot express it in numbers, your knowledge of it is of
>>>>> a
>>>>> meager and unsatisfactory kind; it may be the beginning of
>>>>> knowledge,
>>>>> but you have scarcely, in your thoughts, advanced it to the stage
>>>>> of
>>>>> science."
>>>>>
>>>>> Sir William Thompson, Lord Kelvin (1824-1907)
>>>>
>>>> How much do you love your spouse, your kids if any, your parents?
>>>
>>> Love is immeasurable, so software development must be immeasurable
>>> too?
>>
>> If you can know something without objectively measuring it, perhaps
>> there
>> are other things for which it can work, too?
>
> Kelvin had that covered: "your knowledge of it is of a meager and
> unsatisfactory kind".
How did he measure this?
> Most prefer to maintain the mystery of Love & Faith.
> Why would someone prefer to make software development mysterious?
"Not measured" doesn't imply "mysterious" to me. I do know that Pair
Programming works better in most cases for me, and I have opinions on why.
And for none of the people I know who tried it for some time does it seem to
be mysterious.
Cheers, Ilja
Ilja Preuß
Did Pair Programming work for me at that time? I don't remember, and I don't
care.
What I do know is that most often I do have enough money in my pocket to
take someone to lunch, and that I could tell instantly for any given
situation wether I do, without ever having measured it.
Cheers, Ilja
PS: Isaac, Ron, if you are ever in Karlsruhe, Germany, remember me to take
you to lunch... ;)
Laurent Bossavit
> > If you give up three features you didn't need, then overall quality will
> > be higher and your costs will go down.
>
> Qualifying the three features as features you didn't need is an example of
> the gaming that I mentioned when referring to GE in an earlier post.
Thanks for clarifying "gaming". It seems to me that the "needed/not
needed" distinction is fair game, however, based on... industry data,
which suggests that many of the features built into a system are never
actually used.
So let's use "gaming", but call this type "fair gaming", to indicate
that I am bringing into a play a distinction not made previously in the
conversation, but which at least one of us considers relevant.
Are you familiar with the ideas in Robert Austin's book, "Measuring and
Managing Performance in Organizations ?" Your discussion of "gaming"
suggests you might be.
> If you give up three features that you really need right now, but don't
> have enough time or money to have pairs of programmers work on, how much
> quality do the pair-programmers have to generate to make up for those features?
No amount of extra quality in features X, Y Z will make up for not
having features A, B, C if you actually needed them.
However, I want to point out that if features X, Y, Z lack essential
quality attributes - such as, they actually work - then you're missing
not three, but six features.
> In January, a pair of developers on our team (not me), who enjoy
> pair-programming and unit-testing, began pair-programming and unit-testing
> work on feature changes to a large enterprise application to accommodate
> some government regulation that take effect during mid-April.
Just out of curiosity, I'd like to know when it became known that the
regulation change would take effect in April. That does not necessarily
have any bearing on our conversation, but then again it might.
> It is obvious that they were right -- they could not have delivered the
> features if they continued to pair-program.
By "obvious", do you mean that their velocity in mid-February (three
iterations into the effort) was such that you could predict some
features would be missing by mid-April (four iterations later) ?
If so, can you divulge the measure of the total scope (in "story
points" or some other unit), and the observed velocity during the first
three iterations ? I'd like to know how much of a feature shortfall
we're talking about.
> After two more months of very intense, hard work individual-programming,
> they are delivering the feature set.
That's good. So you have measured the gain in terms of number of
features delivered per unit time, which is one important dimension of
the development effort.
By "very intense, hard work", do you mean that the two worked more hours
than usual ? Was this taken into account in the "number of features per
unit time" calculation ?
How are you measuring the quality shortfall ? How are you measuring the
cost of that quality shortfall ?
My concern and the reason for this line of questioning is that, as
Austin argues in the reference above, there is a kind of "gaming" that
commonly goes on in organizations. Measurements are made of the things
which are easy to measure, leading to strong pressure for improved
performance along these dimensions. At the same time, no measurements
are made of the things harder to measure, and no pressure applied there.
However, for any given dimension of performance, "easy to mesure" does
not correlate well with "criticality to business results". Measurement
efforts therefore tend to have adverse effects, because people respond
to the differential pressure by slacking off on the aspects not
measured, even if they are critical to business results.
Ronald E Jeffries
wrote:
>> For example here, we don't multiply by a factor (though in early days
>> we did consider what we called "load factor") but instead we just
>> track how long it takes to do the story. So if it is a story of
>> dificulty 2, we expect that other stories of d=2 will take about the
>> same amount of time. That turns out to be sufficient, and quite
>> effective, for tracking and predicting.
>
>This sounds good. In other words you classify the tasks and you moved to
>discreet estimates.
Yes. And we can consider the estimates to be abstract values (though
some teams estimate in elapsed time and get good results as well).
Once we have worked for an iteration, we have an actual velocity, i.e.
the sum of the estimates of the things completed. We use that to
project the future. Works surprisingly well.
Isaac Gouy
> >> >> I produce better code and more features when paired.
> >> >
> >> >And you know that because you've measured the quality of code and
> >> >number of features, you & your pair produce, with and without pairing?
> >>
> >> Of course. Don't you?
> >
> >Sometimes, sometimes not.
> >So you have measurements for the work y'all did on Fitnesse?
>
> Of course. We have velocity measurements, coverage measurements,
> acceptance and unit test measurements. I could probably infer coding
> rates from the data if I wanted to.
>
> I've already posted some of that data here. Perhaps I'll write an
> article about the project one day.
Excellent, we have some 'after' measurements, what about the 'before' measurements?
Isaac Gouy
> >> Perhaps not. But I do wonder, and I pay attention. What I don't do is
> >> prove.
> >
> >That's not very Test Driven ;-)
>
> On the contrary. I try things, I observe whether they work. If they
> do, I do it again. If they don't, I don't.
Wouldn't that be: define the test, check it fails, try things, check the test? ;-)
(Sample size of one is kind-of small?)
Isaac Gouy
> But that's not what we saw when we read that paper thirty four years
> ago. What we saw instead was phases with dates. How we saw that I
> can't say.
The usual organizational change issue: the new thing comes along so
'of course' we're now doing the new thing - except we continue to do
the old (stagewise) thing.
(What was that quip about OO? In 20 years everyone will be doing OO
and no one will know what it is?)
Ronald E Jeffries
TDD is a programming technique, providing feedback (and a nice test
suite as a side effect). Feedback is a life technique.
>
>(Sample size of one is kind-of small?)
It's the first point of feedback. Prudent to pay attention to it. Not
prudent to overreact.
Isaac Gouy
> We might. However, what I've noticed is that folks who adopt an agile
> method don't really care much whether it is XP or FDD, or SCRUM.
Could that be because most of the benefit comes from just using an
iterative approach - any iterative approach?
"Iterative and Incremental Development: A Brief History"
http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf
(For me the interesting distinction is between iterative approaches to
development and iterative approaches to delivery.)
Isaac Gouy
> > Most prefer to maintain the mystery of Love & Faith.
> > Why would someone prefer to make software development mysterious?
>
> "Not measured" doesn't imply "mysterious" to me. I do know that Pair
> Programming works better in most cases for me, and I have opinions on why.
> And for none of the people I know who tried it for some time does it seem to
> be mysterious.
Trust and verify.
Sometimes I do user-interaction design. Folk will argue passionately
that the menu layout they have is so much faster/easier-to-use/...
than any other design could be.
And then we measure. Even though these folk are the world experts in
using their particular menu layout, there seems to be a 50/50 chance
that they themselves are significantly faster using some other design.
Self assessment of performance is notoriously inaccurate.
It isn't worth debating things which can be measured.
Jason Nocks
> Laurent,
>
>
>>>If you give up three features, how much quality does it take to make up
>
> for
>
>>>those features?
>>
>>If you give up three features you didn't need, then overall quality will
>>be higher and your costs will go down. Conversely, increased quality
>>might mean shorter test-and-debug cycles, which in turn means more time
>>available to implement features you do need.
>
> Qualifying the three features as features you didn't need is an example of
> the gaming that I mentioned when referring to GE in an earlier post. So I
> will restate the same question with a few more definitives. If you give up
> three features that you really need right now, but don't have enough time or
> money to have pairs of programmers work on, how much quality do the
> pair-programmers have to generate to make up for those features?
Seems this is oddly being treated as either/or. Perhaps this is just the
circumstance of the example stated further below.
When *planning*, it is not uncommon to consider whether the available
team can meet a particular deadline with a particular number of features
(stories), using a sustainable pace. The answer is not always yes.
Sometimes changes to the "givens" of the project need to be made.
Business managers are aware of this. They typically prefer to find out
sooner rather than later. Often, however, they are not told until it is
essentially too late to remedy the situation.
However, if the GoldOwner is informed well ahead of time of looming
problems and responds "get them all done by the deadline no matter what,
but without adding team members to the project", then you might not have
an environment that is suitable to XP. This does not seem to be directly
related to the efficiency or otherwise of a practice that includes
pair-programming versus a recommended practice that does not include
pair-programming.
> Here is my latest data point (without the data and names so I won't offend
> anyone). In January, a pair of developers on our team (not me), who enjoy
> pair-programming and unit-testing, began pair-programming and unit-testing
> work on feature changes to a large enterprise application to accommodate
> some government regulation that take effect during mid-April. Mid February
> they stopped pair-programming and unit-testing because they weren't making
> enough progress and would not be able to deliver the feature set on time.
> After two more months of very intense, hard work individual-programming,
> they are delivering the feature set. It is obvious that they were right --
> they could not have delivered the features if they continued to
> pair-program.
CowboyCoding is faster than XP in short spurts. CopyAndPasteProgramming
is faster than TestDrivenDevelopment in short spurts. I don't think that
anybody here will dispute that.
And, nobody here is going to question peoples motives for trying to meet
a tight deadline. The question is what are the repercussions. What
happens if you keep doing this? If this was a one time occurance, and
everyone can clean up and move on afterwards, fine. If the code is not
valuable after the deadline, fine. But, if this becomes commonplace, and
there will be new deadlines immediately following the previous ones,
yes, quality, and eventually development speed will suffer. The rabbit
will lose the race.
> The question is:
>
> If the XP process lets two experienced developers get more done when
> pair-programming as compared to working on tasks in parallel, why did they
> feel they had to abandon the process to deliver the feature set?
I believe that the discussion was about programmers following certain
practices alone versus practicing XP in pairs.
What practice did these programmers follow when they abandoned
pair-programmig and unit-testing? It sounds like they resorted to
CowboyCoding (coding like mad).
What is your point? That programmers coding like mad can produce lower
quality code faster in short spurts than an XP team can produce high
quality, low-defect code in a sustainable fashion? OK, fine. Been there,
done that. So what?
How long can they keep this up? When do they burn out and move on? How
much time is wasted dealing with the increased level of defects? How
much time is lost while the programmers slow down to catch their breath
after the deadline? How much time is lost with cleaning up messes made
*in the interests of saving time* Etc, ...
Are you recommending "code like mad" as a better practice for developers
overall, in the general case?
> The answer is:
>
> The process doesn't let two experienced developers pair-program together for
> one hour (spending two man-hours) and yield two man hours worth of work
> product (code/features). That is just break even anyway, although it would
> be better if the code quality is better, which it probably would be better.
>
> I believe that there are some out there, who will start gaming this latest
> data-point to explain how these two developers are novices at the XP
> practices, genetically deficient, etc. Let me assure you that these are two
No, not at all. These are real-world humans placed in a real-world
difficult situation, probably doing the best they can think of at the
time. The decisions reached, however, may not be the same decisions that
other teams would have reached. And, it is not clear who was making the
decisions, the programmers or the business manager.
Also, pair-programming is not an all or nothing issue. Especially if
there are only two developers on the team. Pair-programming is most
beneficial when the developers can switch pairs to remain fresh. That is
not possible with only two developers. I am personally aware of ways to
deal with this if you are sincerely interested.
> of the most talented and knowledgeable developers on staff. Both are
> team-lead-level developers. They pair together quite well. It would have
> been nice for the company to spend the money to have both working on the
> same code, but real-world business did not allow for this luxury. This
If the business people are going to require that developers "code like
mad" to make unrealistic deadlines, what process do you think will help
them out? How long can they keep that process up?
What happens when the business manager starts to assume that the team
can keep up this pace indefinitely (Why can't you "code like mad" all
the time? Why would you not operate at top speed at all times?)? The
reality is that *before* that point the developers need to tell the
business manager that the deadlines are not realistic. If the business
manager does not listen, what process will solve this problem?
> real-world data-point, I hope, gives you a better understanding of what I
> mean when I say that what is optimal for a couple of developers may not even
> be close to what is optimal for the corporation. I hope it also provides a
What is optimal for most corporations and most business managers is to
know what is a realistic workload for a given team of developers
*before* committing to deadlines, or at the earliest possible opportunity.
If the developers chose to throw out a process rather than discuss a
problem with the business manager, they were not valuing communication
as highly as some other teams experienced with XP I'm aware of.
If, however, the problem was presented, and the business manager just
responded "tough, just get it done", then the organization may not place
a high level of importance on some of the values that XP promotes.
> real-world example of trading code quality for features and vice versa. In
> the end, the two developers did what was right for the corporation, even
> though many in the corporation were telling them to stick with
> pair-programming, which is what would have been most beneficial to them
> personally.
XP practices are beneficial to organizations that value low-defects, a
sustainable pace, and early feedback. If those benefits are not
important to the organization, then perhaps XP is not a good fit.
> Regards,
>
> Randy
Cheers,
Jason Nocks
SourceXtreme, Inc.
http://www.sourcextreme.com/
Laurent Bossavit
> It isn't worth debating things which can be measured.
Agreed, and thanks for the example. The one you gave is of a situation
where it's (apparently) possible to obtain the ideal of measurement:
varying one parameter, "all other things being equal", and measuring the
results on one relevant dimension.
The rest of the time, we are faced with problems where all other things
are never equal, and the results have more than one relevant dimension.
As per another part of this thread, some dimensions will be easy to
measure (e.g. "faster" task performance in interaction design) and
others less easy (e.g. retention of UI procedures or accuracy in
performing the tasks). And the easy ones are often allowed to stand as
the most important to optimize.
Robert C. Martin
>Robert C. Martin <uncl...@objectmentor.com> wrote in message news:<ip4p70l44lf7tkrut...@4ax.com>...
>
>> We might. However, what I've noticed is that folks who adopt an agile
>> method don't really care much whether it is XP or FDD, or SCRUM.
>
>Could that be because most of the benefit comes from just using an
>iterative approach - any iterative approach?
If that were so, then iteration would be the only practice that these
teams have in common. Such is not the case. The common set of
practices seems to include:
short iterations (1-4 weeks)
TDD (the unit testing part)
Agile Planning (Planning Game, or Scrum backlog management)
Open Office (one of the more important ones)
Refactoring
Collective Ownership
Other practices that are frequent, but not as common are:
Pair Programming
Continuous Integration
Acceptance Testing
Metaphor
The Onsite Customer practice is one that everybody has to figure some
way to resolve. Usually it's through appointing business analysts to
the job. Some teams keep them on site, and some make them available
though various means. Everybody struggles with this one, but
everybody also recognizes that it's important.
Robert C. Martin
<randy_y...@msn.com> wrote:
>Laurent,
>
>> > If you give up three features, how much quality does it take to make up
>for
>> > those features?
>>
>> If you give up three features you didn't need, then overall quality will
>> be higher and your costs will go down. Conversely, increased quality
>> might mean shorter test-and-debug cycles, which in turn means more time
>> available to implement features you do need.
>
>Qualifying the three features as features you didn't need is an example of
>the gaming that I mentioned when referring to GE in an earlier post. So I
>will restate the same question with a few more definitives. If you give up
>three features that you really need right now, but don't have enough time or
>money to have pairs of programmers work on, how much quality do the
>pair-programmers have to generate to make up for those features?
Measure the time spent in debuggers. What if you could eliminate this
time and reallocate it to feature development? If, by pairing, and by
test driven development, you could reduce debugging time by a factor
of ten, how many more features could you get done?
My own anecdotal data tells me that I get more done when I pair, and
when I use TDD. Pairing alone without tests is useful to me, but lots
of time gets spent in debugging so it doesn't seem to pay off as well.
For example, my pair partner and I had a problem yesterday that cost
us three hours. (He had a spurious java.exe installed in a directory
that happened to be in the path, and it was getting executed in a
bizarre context). Having both of us working on that problem at the
same time was probably inefficient. On the other hand, when we were
programming together we were going very fast, and there were virtually
no bugs.
>Here is my latest data point (without the data and names so I won't offend
>anyone). In January, a pair of developers on our team (not me), who enjoy
>pair-programming and unit-testing, began pair-programming and unit-testing
>work on feature changes to a large enterprise application to accommodate
>some government regulation that take effect during mid-April. Mid February
>they stopped pair-programming and unit-testing because they weren't making
>enough progress and would not be able to deliver the feature set on time.
>After two more months of very intense, hard work individual-programming,
>they are delivering the feature set. It is obvious that they were right --
>they could not have delivered the features if they continued to
>pair-program.
Was it the same two guys working together for six weeks? Were they
writing their unit tests *first*?
I trust their decision. They're probably right that they wouldn't
have gotten done. I have found that when you pair two people long
term, things don't work out very well. At Object Mentor, we had two
programmers who started out pairing well, and then stopped pairing
altogether after a few weeks. On the other hand, when we brought some
summer interns in, the pairing went up dramatically, and so did
morale, and productivity.
The really good XP teams that I see nowadays pair at about 70% to 80%.
Pairings are short lived (a day or less), and programmers will often
pick certain tasks to work on alone.
>The question is:
>
>If the XP process lets two experienced developers get more done when
>pair-programming as compared to working on tasks in parallel, why did they
>feel they had to abandon the process to deliver the feature set?
>
>The answer is:
>
>The process doesn't let two experienced developers pair-program together for
>one hour (spending two man-hours) and yield two man hours worth of work
>product (code/features). That is just break even anyway, although it would
>be better if the code quality is better, which it probably would be better.
I think that's a simplistic answer. There's too much evidence to the
contrary. I have certainly seen cases where two programmers don't
work efficiently together. I have also seen (and experienced) cases
where pairing has led to remarkable efficiencies.
>I believe that there are some out there, who will start gaming this latest
>data-point to explain how these two developers are novices at the XP
>practices, genetically deficient, etc. Let me assure you that these are two
>of the most talented and knowledgeable developers on staff. Both are
>team-lead-level developers. They pair together quite well. It would have
>been nice for the company to spend the money to have both working on the
>same code, but real-world business did not allow for this luxury. This
>real-world data-point, I hope, gives you a better understanding of what I
>mean when I say that what is optimal for a couple of developers may not even
>be close to what is optimal for the corporation. I hope it also provides a
>real-world example of trading code quality for features and vice versa. In
>the end, the two developers did what was right for the corporation, even
>though many in the corporation were telling them to stick with
>pair-programming, which is what would have been most beneficial to them
>personally.
I believe they did what was right. I also believe that there might
have been other strategies to apply that could have more nearly
satisfied their goals, and the company's goals.
Shane Mingins
>
> Other practices that are frequent, but not as common are:
> Pair Programming
> Continuous Integration
> Acceptance Testing
> Metaphor
What do you see them replacing Acceptance Testing with? It's just that I
see automated acceptance testing as such an important part of XP and wonder
what other agile methods would use instead.
Cheers
Shane
--
"Dear Lord: The gods have been good to me. For the first time in my life,
everything is absolutely perfect just the way it is. So here's the deal: You
freeze everything the way it is, and I won't ask for anything more. If that
is OK, please give me absolutely no sign. OK, deal. In gratitude, I present
you this offering of cookies and milk. If you want me to eat them for you,
give me no sign. Thy will be done." - Homer Simpson
Robert C. Martin
I've already written an article about measurements of an older C++
project I worked on. An article that compares the two could be
interesting... I'll think on it. Good idea. Thanks!
Robert C. Martin
Prescient!
Isaac Gouy
> > It isn't worth debating things which can be measured.
>
> Agreed, and thanks for the example. The one you gave is of a situation
> where it's (apparently) possible to obtain the ideal of measurement:
> varying one parameter, "all other things being equal", and measuring the
> results on one relevant dimension.
>
> The rest of the time, we are faced with problems where all other things
> are never equal, and the results have more than one relevant dimension.
In that example we had one varying parameter, and results on multiple
dimensions - however the point of the anecdote was that, in general,
self-assessments are a waste of breath.
Back in the '20s the needs of agriculture drove the initial
development of multifactor experimental design and supporting
statistics - engineering has a varied and rich heritage.
> As per another part of this thread, some dimensions will be easy to
> measure (e.g. "faster" task performance in interaction design) and
> others less easy (e.g. retention of UI procedures or accuracy in
> performing the tasks). And the easy ones are often allowed to stand as
> the most important to optimize.
Is designing a measure that different to designing a test?
Laurent Bossavit
> > As per another part of this thread, some dimensions will be easy to
> > measure [...] the easy ones are often allowed to stand as
> > the most important to optimize.
>
> Is designing a measure that different to designing a test?
I don't understand the question, or how it relates to the part of my
post you were quoting. Can you please clarify ?
Robert C. Martin
<shanem...@yahoo.com.clothes> wrote:
>"Robert C. Martin" <uncl...@objectmentor.com> wrote in message
>news:4tvt705mk15jca92m...@4ax.com...
>>
>> Other practices that are frequent, but not as common are:
>> Pair Programming
>> Continuous Integration
>> Acceptance Testing
>> Metaphor
>
>What do you see them replacing Acceptance Testing with?
Manual tests (sigh).
>It's just that I
>see automated acceptance testing as such an important part of XP and wonder
>what other agile methods would use instead.
I quite agree. Manual tests are not an adequate replacement for
automated acceptance tests. Nobody should be building systems without
an automated acceptance test suite. And nobody should make excuses
about GUIs being too hard to test, or external systems being too hard
to tests, or "my special problem" is too hard to test. If you can
write a line of code, you can write another line of code to test it.