On Friday, July 29, 2005, at 7:59:30 PM, William Pietri wrote:

> Ron Jeffries wrote:

>>What I'm trying to understand is "How could they NOT see that they
>>are NOT doing what is written down." I would really like to
>>understand that.
>>

> Hi, Ron! I'm not Paul, of course, let alone the people he's describing.
> But I can pass along a story from somebody I met at the conference.

> He mentioned to me that they were doing something pretty much like XP
> for the last six month, and loved it except for the pair programming,
> which they hated. With further questioning, it became clear that they
> were doing something I wouldn't call pair programming.

> The computer was in the corner of an L-shaped desk, so one person would
> drive for hours while the other person leaned around and watched. If the
> person behind had something to contribute, the person at the keyboard
> would take dictation.  It's no wonder they hated it. They must have been
> extraordinarily patient and persistent to stick with it that long.

Yes, one does wonder. I also wonder whether it helped, despite being
boring and painful.

> In the 18 months I lived in Australia, I must have tried every allegedly
> Mexican restaurant on the continent, and they were all wrong, wrong,
> wrong. The chefs weren't untalented, and I'm sure that to somebody who
> had never tasted Mexican food, it would have seemed great. But because
> they learned it from books, what seemed like minor, reasonable
> accommodations to local conditions were actually fundamental mistakes.

Yes ... if what they're doing differently seems "minor" to them.
From what Paul has said so far, it's hard to see how their changes
could seem minor -- which is why I'm asking.

Where are these people? If I'm passing through, I could drop in on
them.

> I think people are especially prone to the this problem when they're
> used to things running poorly. Perhaps Paul's pal's team feels their
> current situation is an improvement, even if it fills the rest of us
> with horror. As the country song goes, "I been down so long, it looks
> like up to me."

But from what Paul said, it sounds like these people aren't even
trying a number of the practices. I don't recall whether he's said
whether they're experiencing anything like improvement over their
previous situation, or otherwise having fun. His overtones of
concerns from himself and their manager made me think not, but that
could be wrong.

I'd think that the things he /has/ mentioned would be red flags. I'd
really like to see the checklist of which practices they are doing.

Where's that radar chart of Bill Wake's? They could fill that out.

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

The unfortunate thing is that most evidence that pair programming is
effective is anecdotal. That can be a hard pill to swallow when the
conventional wisdom shows that immediate cost of pair programming is 2 *
(cost of programmers).

Perhaps a more rigourous approach would help to convince a larger audience
that agile techniques are cost-beneficial.

Chris.

On 7/29/05, Ian Hobson <ian@...> wrote:
>
> In message <7a3fe2020507271455494b6164@...>, Chris Wheeler
> <christopher.wheeler@...> writes
> >Make a simple definition of 'effective': One pair should deliver at
> >least the same number of features as two individual programmers in the
> >same amount of time. The defect rate of these two programmers should be
> >less than the rate of two individual programmers.
>
> There is a lot of things hidden in that "should". I suspect that....
>
> Each programmer will pick up bugs and situations liable to result in
> bugs, that the other cannot see.
>
> Debating about the code and approach, will pick up bugs and potential
> bugs that neither would have seen alone.
>
> Pairing makes adherence to standards more natural and thus reduces
> support costs in the future.
>
> Pairing makes for better - or at least no worse - coverage by the test
> cases.
>
> Pairing spreads knowledge about the code into two brains at each edit,
> thus spreading it deeper and wider in the team than solo programming.
> Resulting in lower future costs.
>
> All in all, two people can produce a good deal LESS raw lines of code
> pairing than working as two solo programmers and the project can still
> come out ahead in value for money terms. What does a bug cost? What does
> a reputation for rock solid code gain you in your market place? What
> does easy maintenance gain you?
>
> To the OP - Please measure as best you can and report back. I doubt you
> can measure all the factors.
>
> Regards
>
> Ian
> --
>
>
>
> To Post a message, send it to: extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com <http://objectmentor.com>
> Yahoo! Groups Links
>
>
>
>
>
>
>


--
---------------------
Chris Wheeler
Extreme Programmer & Coach
Visit my new site! http://www.agilelectric.com


[Non-text portions of this message have been removed]

>>> http://f6.grp.yahoofs.com/v1/8NPp[...]Yrh/Are%
>>> 20You%20Getting%20XPd%20On.pdf

--- Ron Jeffries:
>> That URL, even reassembled, doesn't go anywhere for me, and I
can't
>> find the file on my hard drive. So a tinyurl or other link would
be
>> handy if anyone has it.

--- "Ken Boucher" <yahoo@n...> wrote:
> I found a working link at
> http://groups.yahoo.com/group/extremeprogramming/files/

Yes:
http://groups.yahoo.com/group/extremeprogramming/files/Are%20You%
20Getting%20XPd%20On.pdf
-or-
http://tinyurl.com/e2vxj

It's Kent Beck's "Are You Getting XP'd On?" article.

The ".../f6.grp.yahoofs.com/..." stuff seems to be part of the login
protocol for this group.

>> --- Chris Wheeler <christopher.wheeler@g...> writes
>>> Make a simple definition of 'effective': One pair should
>>> deliver at least the same number of features as two
>>> individual programmers in the same amount of time. The
>>> defect rate of these two programmers should be less
>>> than the rate of two individual programmers.

Yes.  Good definition.  And this assertion has been "scientifically
verfied" by Laurie Williams in her "An Alternative: The
Collaborative Software Process (CSP)" paper:

http://collaboration.csc.ncsu.edu/laurie/Papers/CSP.pdf

"A formal experiment with the CSP was performed with advanced
undergraduates at the University of Utah in 1999. The results showed
that pairs were able to complete their programs in about half the
time of individuals and that the pairs produced programs of
statistically significantly higher quality [3, 4, 7, 11]."

However, other papers have shown higher and lower productivity
numbers.  It appears to me that your results will vary based on your
people, and probably your approach.  ;->

See Laurie Williams' site:
http://www.pairprogramming.com/


> --- Ian Hobson <ian@i...> wrote:
>> There is a lot of things hidden in that "should". [...]

Good point.

>> I suspect that....
>>
>> Each programmer will pick up bugs and situations liable
>> to result in bugs, that the other cannot see.
>> [...]
>>
>> All in all, two people can produce a good deal LESS raw
>> lines of code pairing than working as two solo programmers
>> and the project can still come out ahead in value for money
>> terms. [...]

A very good and important idea.

--- Chris Wheeler <christopher.wheeler@g...> wrote:
> The unfortunate thing is that most evidence that pair
> programming is effective is anecdotal. That can be a
> hard pill to swallow when the conventional wisdom shows
> that immediate cost of pair programming is
> 2 * (cost of programmers).

Yes!  There has been remarkably little measurement or reporting of
the costs and benefits of any of the XP techniques, including pair
programming.  Nor is there much information available about any of
the alternatives, in any of the other software development
approaches.  It is an unfortunate state of affairs in our industry,
that there is so little gathering and sharing of information so
critical to making informed decisions.

But, for a ray of light in the darkness, see Laurie Williams' study,
referenced at the top of this note.

Hi Ron,

--- In extremeprogramming@yahoogroups.com, Ron Jeffries <ronjeffries@X...>
wrote:
>
> There's a recent thread on the Scrum list about how an executive
> or highly-placed manager could get Agile going. I've been one of
> those guys, and I know a bit about Agile, and here's how I'd
> proceed. First, focus management attention on cyclic delivery of
> running tested software. Second, provide the resources to learn
> how to do that.

Great article - very clear and succinct. Thanks!

However (you knew that was coming), I have a couple of questions:

First, introducing throughput accounting (ie. measuring success by volume of
product) is notoriously difficult, as anyone in the Theory-of-Constraints or
Lean communities will attest. Have you seen this measure accepted
universally, or resisted by bean-counters?

Second, in a shop that's already running with legacy code and product, I
would expect a productivity /dip/ while the 'running' and 'tested' parets of
the RTF equation take hold. Do you find that? If not, how did you avoid it?

Thanks,
Kevin
--
http://silkandspinach.net
http://agilenorth.org.uk


[Non-text portions of this message have been removed]

Guys... Try the XPJobs group for the Want Ads...

  Amir Kolsky
XP& Software


>-----Original Message-----
>From: extremeprogramming@yahoogroups.com
>[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Alfredo Ch?vez
>Sent: Saturday, July 30, 2005 1:54 AM
>To: extremeprogramming@yahoogroups.com
>Subject: [XP] Re: Developers Wanted
>
>I'll relocate!! If I could only get a green card... *sigh*
>
>--- In extremeprogramming@yahoogroups.com, "David Roberts"
><droberts@i...> wrote:
>> Sorry no. Due to my preference for co-located teams, security,
>etc... I'd prefer that people relocate to sunny San Diego.
>>
>> David Roberts
>> InnovaSystems Intl
>> (619) 955-5864
>
>
>
>
>To Post a message, send it to:   extremeprogramming@eGroups.com
>
>To Unsubscribe, send a blank message to:
>extremeprogramming-unsubscribe@eGroups.com
>
>ad-free courtesy of objectmentor.com
>Yahoo! Groups Links
>
>
>
>
>
>

On Saturday, July 30, 2005, at 5:13:21 PM, Kevin Rutherford wrote:

> However (you knew that was coming), I have a couple of questions:

> First, introducing throughput accounting (ie. measuring success by volume of
> product) is notoriously difficult, as anyone in the Theory-of-Constraints or
> Lean communities will attest.

Unless I miss my guess, most product companies measure number of
products shipped, do they not? What's hard about that?

And anyway, I'm not proposing changing accounting, I'm proposing the
executive telling his reports what he cares about, and what will
make him happy: Features. It won't take a reorganization of the
whole company to do that: software projects are already /supposed/
to ship stuff. They just don't do so very often.

> Have you seen this measure accepted
> universally, or resisted by bean-counters?

Neither, none of the above. But it's not hard, and not unknown: XP
teams and Scrum teams, for example, measure velocity all the time.

And again, we're not trying to change the bean-counters. They can
count whatever they want to. Meanwhile, what counts in development,
and in the eyes of its managers, should be getting stuff done.

Offhand, I'd expect that to improve most any existing financial
measure. (Although there may be some interesting issues relating to
capitalization.)

> Second, in a shop that's already running with legacy code and product, I
> would expect a productivity /dip/ while the 'running' and 'tested' parets of
> the RTF equation take hold. Do you find that? If not, how did you avoid it?

Yes, you have to slow down to turn. On the other hand, since most
non-Agile projects typically have zero features delivered in any
given month, one feature would be an improvement. So even though
overall progress /might/ slow, successful feature delivery could
quite possibly start early on.

And when the teams figure out that they have to be Agile, they'll
likely go faster very quickly. Scrum and XP teams are, anecdotally
at least, about twice as productive as the same team was before they
started doing the Agile thing.

Ron Jeffries
www.XProgramming.com
How do I know what I think until I hear what I say? --  E M Forster

Literate programming is a program that reads like a story. Tests can be part
of literate programs.

I found my experience of programming changed dramatically when I wrote my
first few literate programs. What I thought was squeeky clean code wasn't.
It was easier to continue refining the code than it was to try to explain
why it wasn't clean. I also became aware of just how much there was to
communicate when describing code.

Sincerely yours,

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
> bena@...
> Sent: Sunday, July 24, 2005 7:08 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] literate programming
>
>
> TDD is literate programming with runnable comments?
>
>         Regards, Ben

Norman,

On my current development contract I invoice monthly for the time I have
spent programming in that month. This is a time-and-materials contract. The
principle I can think of that I would try to apply is mutual benefit. When
the customer concretely benefited from my efforts, I would like to also
benefit. I can easily imagine this resulting in an invoice once a month too.

Sincerely yours,

Kent Beck
Three Rivers Consulting, Inc.

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Norman Sasono
> Sent: Thursday, July 28, 2005 3:54 AM
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] How to invoice clients in XP projects
>
> Dear XPers,
>
> Maybe it’s a ‘naïve’ question and has been asked before…
> sorry if it’s true…
>
> How do you guys usually charge (invoice) your client in an XP project
> (Iterative-Agile method in general)? Where they hire your team (your
> consulting firm) to develop software for them & you’re using XP
> (Iterative-Agile)?
>
> In Waterfall processes it’s easy. Each milestone (phase) has ‘distinct
> deliverables’ and sign-offs for that ‘deliverables’. Based on these
> ‘deliverables’ and sign-offs we can invoice the customer. In
> XP project,
> what would be the basis for invoicing our clients? What would be the
> ‘milestone’?
>
> XP promotes ‘ship software early’, so do you invoice when 25%
> of features
> are built, then when it reaches 50% and so on? How do you
> measure 25%, 50%
> anyway? It means you should get all the scope up-front then?

All,

While at Agile 2005 this week I answered several questions of the form, "How
much is different in the second edition?" For the benefit of all those who
have this question and haven't asked it, the answer is that the text is a
complete re-write. The only words I copied and pasted were from the Learning
to Drive chapter. Everything else was written from scratch from my
five-years-later perspective. The same technical content is there (towards
the end we went through the first edition paragraph-by-paragraph and made
sure all the same concepts were covered), but the tone and perspective are
more inclusive and inviting.

To all the people who complimented Cynthia or I on the book, thank you very
much. I would appreciate it if you would post comments on Amazon. Most of
the reviews there are from the first edition.

Take care,

Kent Beck
Three Rivers Institute

Please send me some material on XP.

Thank you ,


                         Mehul






---------------------------------
How much free photo storage do you get? Store your friends n family photos for
FREE with Yahoo! Photos.
  http://in.photos.yahoo.com

[Non-text portions of this message have been removed]

Hi, Mehui,

Go to http://www.xprogramming.com or Google for XP. Or search Amazon.com for
"Extreme Programming."

Kay Pentecost

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Mehul Wani
> Sent: Sunday, July 31, 2005 8:54 AM
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] For some ebooks and material on XP
>
>
> Please send me some material on XP.
>
> Thank you ,
>
>
>                         Mehul
>

jhrothjr wrote:

>The only thing on Sunday was the two intro sessions. I hit the
>Engineering Practices session, which was very well attended. There
>were four talks, covering stories, planning, innovtion and Fit. Except
>for the last, I'm not at all sure I'd call any of them engineering
>practices - they're more in the project management space from where I sit.
>
>However, there were some really nice tidbits.
>
>I'm coming around to the idea of renaming "Executable Acceptance Test"
>to "Executable Story Test". The tests are tied to the stories, and it
>gets one more piece of terminology out of the confusion zone with
>classical testing and QA practice.
>
>
Glad to hear that.  One minor suggestion -- we actually call them
"storytests" -- no space between story and test.   (The new FIT got it
right in some places and wrong in others.  Rick and Ward assure me
they'll fix it in later printings of their book).

--
best regards,
jk

----
I n d u s t r i a l   L o g i c ,  I n c .
Joshua Kerievsky
Founder, Industrial XP Coach
http://industriallogic.com
http://industrialxp.org
866-540-8336 (toll free)
510-540-8336 (phone)
Berkeley, California

Paul -- I documented nearly 50 XP pathologies in our XP Playing Cards.
It took years to complete the deck to my satisfaction, as I wanted to
make sure I descirbed problems that occured in more than one XP
environment.  See http://industriallogic.com/games/eppc.html.    --jk

Paul Butcher wrote:

>Hi - I'm hoping that the group can offer me some help with the
>following:
>
>I am looking for an article which describes "XP Pathologies".
>Specifically, I'm looking for a list of ways to tell that your local
>implementation of XP is broken and needs remedial action.
>
>I've had a hunt through the various XP books and websites, but can't
>find quite what I'm after - I can't believe that it isn't out there
>though!
>
>Background:
>
>I've recently been contacted by an ex-colleague who knows that I
>have run an XP team in the past. Her organisation has recently moved
>to XP (or at least they *think* that they have). She has described a
>set of pathological behaviour to me which is frankly scary:
>
>- No well defined customer
>- Customer not involved because they "don't have time"
>- "Stories" defined at a technical level, rather than something
>which is meaningful to the customer
>- Developers scheduling stories rather than the customer
>- No planning at all beyond the current iteration
>- No agreed units for story estimates
>- No "coach" role
>- etc. etc. etc.
>
>Before they can even begin to address all of these issues, they need
>to accept that they have a problem. The best way to do this would be
>if there was a website or book that she could point to and
>say "look - it says in here that if you're not doing <foo>, then
>you're not doing XP", or better yet "look - it says in here that if
>you experience symptom <bar> then you need to take remedial action
><baz>".
>
>I know that this kind of thing is distributed throughout the XP
>literature, but what I'm ideally looking for is a single collection
>of XP pathologies which they can look at (my guess is that they're
>hitting a large proportion of them!).
>
>Thanks in advance for your help,
>
>paul.butcher->msgCount++
>
>Snetterton, Castle Combe, Cadwell Park...
>Who says I have a one track mind?
>
>
>
>
>
>
>
>
>To Post a message, send it to:   extremeprogramming@eGroups.com
>
>To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
>ad-free courtesy of objectmentor.com
>Yahoo! Groups Links
>
>
>
>
>
>
>
>


--
best regards,
jk

----
I n d u s t r i a l   L o g i c ,  I n c .
Joshua Kerievsky
Founder, Industrial XP Coach
http://industriallogic.com
http://industrialxp.org
866-540-8336 (toll free)
510-540-8336 (phone)
Berkeley, California

On Sunday, July 31, 2005, at 6:56:12 PM, Joshua Kerievsky wrote:

> Glad to hear that.  One minor suggestion -- we actually call them
> "storytests" -- no space between story and test.   (The new FIT got it
> right in some places and wrong in others.  Rick and Ward assure me
> they'll fix it in later printings of their book).

Hmm. "Storytests". A new word. I can think of some advantages to
that, I guess ...

Ron Jeffries
www.XProgramming.com
If it is more than you need, it is waste. -- Andy Seidl

Hi, Everybody,

I've been thinking a lot about new bugs that appear when old bugs are fixed.


I know those of us who do Test-Driven Development, or Behaviour-Driven
Development -- see http://daveastels.com/index.php?p=5 don't write
bugs,<grin> but for those of use who are battling legacy code (and if you
are, check out Mike Feather's awesome book Working Effectively With Legacy
Code at
http://www.amazon.com/exec/obidos/tg/detail/-/0131177052/qid=1122854904/sr=1
-1/ref=sr_1_1/103-3896569-0190225?v=glance&s=books) creating new bugs or
uncovering old, undiscovered bugs, is a way of life.

And I've heard the original coder accuse the new guy/gal of adding 20 bugs
when they fix one, however, it seems to me that in most cases, the new guy
has just uncovered bugs that were hidden by the original bug.

Thinking about it, it seems to me that it's really pretty difficult to add
even one bug when fixing a bug in well-structured code... and that being
able to add bugs when fixing an old bug is a sign that the system really
isn't very robust.

Any thoughts on this?

Kay Pentecost

On Sunday, July 31, 2005, at 8:25:46 PM, Kay A. Pentecost wrote:

> And I've heard the original coder accuse the new guy/gal of adding 20 bugs
> when they fix one, however, it seems to me that in most cases, the new guy
> has just uncovered bugs that were hidden by the original bug.

> Thinking about it, it seems to me that it's really pretty difficult to add
> even one bug when fixing a bug in well-structured code... and that being
> able to add bugs when fixing an old bug is a sign that the system really
> isn't very robust.

> Any thoughts on this?

Well, Kay, what you say is the way to bet. However, if the code
works, then we change one line, then ten tests (which may or may not
exist) break ... we just inserted ten bugs into the system ...
didn't we?

Ron Jeffries
www.XProgramming.com
Fatalism is born of the fear of failure, for we all believe that we carry
success in our own hands, and we suspect that our hands are weak. -- Conrad

Kay A. Pentecost wrote:

>Hi, Everybody,
>
>I've been thinking a lot about new bugs that appear when old bugs are fixed.
>
>
>I know those of us who do Test-Driven Development, or Behaviour-Driven
>Development -- see http://daveastels.com/index.php?p=5 don't write
>bugs,<grin> but for those of use who are battling legacy code (and if you
>are, check out Mike Feather's awesome book Working Effectively With Legacy
>Code at
>http://www.amazon.com/exec/obidos/tg/detail/-/0131177052/qid=1122854904/sr=1
>-1/ref=sr_1_1/103-3896569-0190225?v=glance&s=books) creating new bugs or
>uncovering old, undiscovered bugs, is a way of life.
>
>And I've heard the original coder accuse the new guy/gal of adding 20 bugs
>when they fix one, however, it seems to me that in most cases, the new guy
>has just uncovered bugs that were hidden by the original bug.
>
>Thinking about it, it seems to me that it's really pretty difficult to add
>even one bug when fixing a bug in well-structured code... and that being
>able to add bugs when fixing an old bug is a sign that the system really
>isn't very robust.
>
>Any thoughts on this?
>
>
>
The code may be robust, but if you change the behaviour of a key
component while fixing a bug, all bets are off.

That's often the case where someone doesn't fully understand how the
code works and it's best prevented by adding tests, which express your
understanding of the code, before changing it.

Cheers,

Ian

Hi,

We are looking for senior Q&P engineer to work on process development
and software project quality management. We particularly want your
experience in iterative and incremental software development to help us
bring more agility into our large product development, while at the
same time, still keep the necessary discipline.

This position is located in Hangzhou, China.

http://careers.nokia.com/nokia/hr/recrsyst.nsf/WB2RR/7664DE169F99B624C22
57031003E5FB1?OpenDocument&Lang=Global

I have the passion to make dramatic changes, if you do as well, please
contact me.:-)

Sorry for possible disturbance!
Br, yi

Most Amazing and Attention Getting Line should be first in a program,
told as a story.

Leastways, that's what people who tell me how to right stories say.


On Sat, 30 Jul 2005, Kent Beck wrote:

> Literate programming is a program that reads like a story.
>
> Tests can be part of literate programs.

Who is the narrator and are your objects characters (actors) or characters
(strings of ASCII)?

> I found my experience of programming changed dramatically when I wrote my
> first few literate programs. What I thought was squeeky clean code wasn't.

Which dirty bits did your literary ramblings uncover?

(Was it a murder mystery "The Controller did it in the Driver with a
BitStream", or juicier than that..?)

> It was easier to continue refining the code than it was to try to explain
> why it wasn't clean.

What are you saying? "Don't describe, clean?" Xor "Describe to find what
you need to clean, clean, then carry on describing?"

> I also became aware of just how much there was to
> communicate when describing code.

Were you simply describing the implementation, or writing the requirement
spec, high level design, detailed design, use cases, program, reference
manual and user guide etc. etc. in one document?



John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@...
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

Kay A. Pentecost wrote:

> Thinking about it, it seems to me that it's really pretty difficult to add
> even one bug when fixing a bug in well-structured code... and that being
> able to add bugs when fixing an old bug is a sign that the system really
> isn't very robust.

I think that I'd like you to say a bit more about this.

My own experience is that it's really *easy* to add a bug to a system -
it only takes *one* character in *one* line of code - and I can easily
do that by accident. Besides, I know for a rather tiresome fact that
every single bug in the code I've written was put there by one person -
me. Granted, if I'm "doing XP" as defined in _Extreme Programming
Installed_, I can blame Chet for the bugs (because, after all,
*everything* is Chet's fault). Even then, though, *someone* has to fix
the bugs, and I've yet to get Chet to do that for me. (Presumably he's
too busy being to blame for everyone *else's* bugs.)

All kidding aside, I've found it *awfully* easy to put bugs into code.
That's why I like to have lots of automated things to help me find the
bugs before they escape my desktop.

So could you say something more about how you find it difficult to add
bugs?

Hi, Ian,

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Ian Collins
> Sent: Sunday, July 31, 2005 9:34 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Creating new bugs when fixing old ones...

> The code may be robust, but if you change the behaviour of a key
> component while fixing a bug, all bets are off.

Granted.  But if one changes the behavior of a key component doesn't it
usually become obvious when you run the system to make sure that hasn't
happened before checking in the code?

>
> That's often the case where someone doesn't fully understand how the
> code works and it's best prevented by adding tests, which
> express your
> understanding of the code, before changing it.

Yes, makes sense.  The problem happens when the tests express the bug
fixer's understanding of the code, but not the original coders understanding
of the code, doesn't it?

Kay

>

Hi, Ron,

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Ron Jeffries
> Sent: Sunday, July 31, 2005 9:11 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Creating new bugs when fixing old ones...
>
> On Sunday, July 31, 2005, at 8:25:46 PM, Kay A. Pentecost wrote:
>
> > And I've heard the original coder accuse the new guy/gal of
> adding 20 bugs
> > when they fix one, however, it seems to me that in most
> cases, the new guy
> > has just uncovered bugs that were hidden by the original bug.
>
> > Thinking about it, it seems to me that it's really pretty
> difficult to add
> > even one bug when fixing a bug in well-structured code...
> and that being
> > able to add bugs when fixing an old bug is a sign that the
> system really
> > isn't very robust.
>
> > Any thoughts on this?
>
> Well, Kay, what you say is the way to bet. However, if the code
> works, then we change one line, then ten tests (which may or may not
> exist) break ... we just inserted ten bugs into the system ...
> didn't we?

Well, I don't know.  Do we count bugs by broken tests, or by problems that
actually get to "testing"?

Maybe I wasn't clear.  Suppose I make one fix, which supposedly fixes the
bug I was supposed to fix,
and 10, or even 20 tests break.

Since I never check in code that has broken tests, I fix the code that broke
the tests.  When the new code runs and all the tests pass correctly, and
I've done the build in my sandbox to make sure, I check in my code.  The
system goes to testing, if there's a testing person or department, and they
verify that the bug I was assigned was fixed.

Now suppose that the bug I fixed was in step 1 of a three step process.
Nobody's been able to do or test step 2 because of the bug in step 1. Now
they find a bug in step 2.  The original programmer claims that the person
who fixed the bug in step 1 created it.  While that's *possible* it's not as
likely as the fact that the first bug hid the second.

When there's no existing tests, there's nothing to alert the bug-fixer than
something else has been broken.

Kay

Hi, Edmund,

> -----Original Message-----
> From: extremeprogramming@yahoogroups.com
> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
> Edmund Schweppe
> Sent: Sunday, July 31, 2005 10:08 PM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Creating new bugs when fixing old ones...
>
> Kay A. Pentecost wrote:
>
> > Thinking about it, it seems to me that it's really pretty
> difficult to add
> > even one bug when fixing a bug in well-structured code...
> and that being
> > able to add bugs when fixing an old bug is a sign that the
> system really
> > isn't very robust.
>
> I think that I'd like you to say a bit more about this.
>
> My own experience is that it's really *easy* to add a bug to
> a system -
> it only takes *one* character in *one* line of code - and I
> can easily
> do that by accident. Besides, I know for a rather tiresome fact that
> every single bug in the code I've written was put there by
> one person -
> me.

Agreed.  Totally agreed. I take full responsibility for every bug I've
written.

>Granted, if I'm "doing XP" as defined in _Extreme Programming
> Installed_, I can blame Chet for the bugs (because, after all,
> *everything* is Chet's fault). Even then, though, *someone*
> has to fix
> the bugs, and I've yet to get Chet to do that for me.
> (Presumably he's
> too busy being to blame for everyone *else's* bugs.)

LOL. Yes.

>
> All kidding aside, I've found it *awfully* easy to put bugs
> into code.
> That's why I like to have lots of automated things to help me
> find the
> bugs before they escape my desktop.
>
> So could you say something more about how you find it
> difficult to add
> bugs?

I don't think so, now, after what you've said. <grin>  Thank you.

Yes, it's easy to add bugs, and yes, that's why I do TDD so that I will add
as few as possible, and that's why I really test what I've written by
running the system before I check in so that bugs don't escape *my* desktop.

So let me take another pass at what I'm trying to find out.

A programmer is blamed for "fixing one bug and introducing 10 more,"  when
really he fixed one bug and *uncovered* 10 (or 20 more) that were not
discovered in QC because the tester couldn't get passed the reported bug.

We're assuming here that we are not an XP team, have no programmer tests to
alert us that the bugs were there.

I've been on this subject before, from the viewpoint of why is the senior
programmer blaming someone for "adding" bugs when the senior wrote her own
bugs that just now became visible.  There's a lot of sociopathic blaming and
accepting of blame and other touchy-feely subjects happening there, but I'm
not really interested in those currents right now.

So on the subject of robust code, if the bug-fixer fixes the bug in an
intelligent manner, grepping for any other calls to the function, and not
modifying key functionality, isn't there a good chance, or, maybe, *is*
there a chance, that it's easier to uncover existing defects than breaking
other parts of the system??

hmmm.

Yes, I think I said what I meant.  Huh?

Kay

John Carter wrote:
> Most Amazing and Attention Getting Line should be first in a program,
> told as a story.

Oh, so *that's* why Unix shell scripts always start with a bang!

Kay A. Pentecost wrote:

>Hi, Ian,
>
>
>
>>-----Original Message-----
>>From: extremeprogramming@yahoogroups.com
>>[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Ian Collins
>>Sent: Sunday, July 31, 2005 9:34 PM
>>To: extremeprogramming@yahoogroups.com
>>Subject: Re: [XP] Creating new bugs when fixing old ones...
>>
>>
>
>
>
>>The code may be robust, but if you change the behaviour of a key
>>component while fixing a bug, all bets are off.
>>
>>
>
>Granted.  But if one changes the behavior of a key component doesn't it
>usually become obvious when you run the system to make sure that hasn't
>happened before checking in the code?
>
>
>
True, but what did type of bug were you referring to, hidden ones of
obvious ones?

>>That's often the case where someone doesn't fully understand how the
>>code works and it's best prevented by adding tests, which
>>express your
>>understanding of the code, before changing it.
>>
>>
>
>Yes, makes sense.  The problem happens when the tests express the bug
>fixer's understanding of the code, but not the original coders understanding
>of the code, doesn't it?
>
>
>
It does.  But if all the tests pass without expressing the original
coders understanding, they can't cover much of the code.

Ian

On Sunday, July 31, 2005, at 10:13:59 PM, Kay A. Pentecost wrote:

>> Well, Kay, what you say is the way to bet. However, if the code
>> works, then we change one line, then ten tests (which may or may not
>> exist) break ... we just inserted ten bugs into the system ...
>> didn't we?

> Well, I don't know.  Do we count bugs by broken tests, or by problems that
> actually get to "testing"?

Well, I believe that the tree really falls, and that the program is
really broken whether anyone knows it or not ...

> Maybe I wasn't clear.  Suppose I make one fix, which supposedly fixes the
> bug I was supposed to fix,
> and 10, or even 20 tests break.

> Since I never check in code that has broken tests, I fix the code that broke
> the tests.  When the new code runs and all the tests pass correctly, and
> I've done the build in my sandbox to make sure, I check in my code.  The
> system goes to testing, if there's a testing person or department, and they
> verify that the bug I was assigned was fixed.

Yes ... if we have tests that is what we'd do.

> Now suppose that the bug I fixed was in step 1 of a three step process.
> Nobody's been able to do or test step 2 because of the bug in step 1. Now
> they find a bug in step 2.  The original programmer claims that the person
> who fixed the bug in step 1 created it.  While that's *possible* it's not as
> likely as the fact that the first bug hid the second.

I'm not sure which is more likely. Certainly we could write code
such that one bug hid the others. But we could also write code such
that fixing one bug made another one appear.

> When there's no existing tests, there's nothing to alert the bug-fixer than
> something else has been broken.

True. And we'd surely like to have those tests. Still ... it's not
hard to see how the situation is at first blush indistinguishable
from fixing one thing and breaking ten.

Now how could we tell those cases apart?

Ron Jeffries
www.XProgramming.com
You can observe a lot by watching. --Yogi Berra

From: "Kay A. Pentecost" <kayp.at.ix.netcom.com@...>
To: "extremeprogramming@yahoogroups.com"
<extremeprogramming.at.yahoogroups.com@...>
Sent: Sunday, July 31, 2005 6:25 PM
Subject: [XP] Creating new bugs when fixing old ones...


> Hi, Everybody,
>
> I've been thinking a lot about new bugs that appear when old bugs are
> fixed.
>
>
> I know those of us who do Test-Driven Development, or Behaviour-Driven
> Development -- see http://daveastels.com/index.php?p=5 don't write
> bugs,<grin> but for those of use who are battling legacy code (and if you
> are, check out Mike Feather's awesome book Working Effectively With Legacy
> Code at
> http://www.amazon.com/exec/obidos/tg/detail/-/0131177052/qid=1122854904/sr=1
> -1/ref=sr_1_1/103-3896569-0190225?v=glance&s=books) creating new bugs or
> uncovering old, undiscovered bugs, is a way of life.
>
> And I've heard the original coder accuse the new guy/gal of adding 20 bugs
> when they fix one, however, it seems to me that in most cases, the new guy
> has just uncovered bugs that were hidden by the original bug.

When people are playing the blame game, then they are playing
the blame game, and there isn't a lot you can do technically about
it.

The only strategy that I've found to work is to make the blamer
discover that the blame game doesn't work on you. After a few
go-arounds they usually learn  better.

Think of it as behavior modification - how do you want
them to behave, taking the environment into account?

John Roth

> Kay Pentecost

In case this helps, I bill at the end of an iteration with net 30 terms.
The idea being that by the end of an iteration, I've dealt with
everything the client signed off on, and because I'm doing vertical
slices (of course) the client can see the results of the time I'm
billing for.

Works for me, and my clients couldn't be more delighted.

Biggest problem I had was that I couldn't sell some of them agile and
scrum... now I simply tell them "this is how it will work" and if they
don't like it, I don't take them on.

Being organized is a must though... if your not good at it, try a good
tool like XPlanner... not ideal for a billing contractor, but it does
the trick (you have to do a little translation to get the time sheets
into you invoice format).

- Brill

Kent Beck wrote:
> Norman,
>
> On my current development contract I invoice monthly for the time I have
> spent programming in that month. This is a time-and-materials contract. The
> principle I can think of that I would try to apply is mutual benefit. When
> the customer concretely benefited from my efforts, I would like to also
> benefit. I can easily imagine this resulting in an invoice once a month too.
>
> Sincerely yours,
>
> Kent Beck
> Three Rivers Consulting, Inc.
>
>
>>-----Original Message-----
>>From: extremeprogramming@yahoogroups.com
>>[mailto:extremeprogramming@yahoogroups.com] On Behalf Of Norman Sasono
>>Sent: Thursday, July 28, 2005 3:54 AM
>>To: extremeprogramming@yahoogroups.com
>>Subject: [XP] How to invoice clients in XP projects
>>
>>Dear XPers,
>>
>>Maybe it’s a ‘naïve’ question and has been asked before…
>>sorry if it’s true…
>>
>>How do you guys usually charge (invoice) your client in an XP project
>>(Iterative-Agile method in general)? Where they hire your team (your
>>consulting firm) to develop software for them & you’re using XP
>>(Iterative-Agile)?
>>
>>In Waterfall processes it’s easy. Each milestone (phase) has ‘distinct
>>deliverables’ and sign-offs for that ‘deliverables’. Based on these
>>‘deliverables’ and sign-offs we can invoice the customer. In
>>XP project,
>>what would be the basis for invoicing our clients? What would be the
>>‘milestone’?
>>
>>XP promotes ‘ship software early’, so do you invoice when 25%
>>of features
>>are built, then when it reaches 50% and so on? How do you
>>measure 25%, 50%
>>anyway? It means you should get all the scope up-front then?
>
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

Phlip wrote:
> Tim Haughton wrote:
[...]
> If you are playing The Contractor Game, the kind where you meter your
> phone and charge extra for each minute on the phone, then you are a
> parasite draining away your host's health and werewithal to sustain
> you.

I'd have to agree, if you have to resort to that to survive, then your
doing something wrong... if you do it because your greedy, then good
luck keeping your clients. You have to care about them (your client) to
do good work for them.

I never bill for the things that take a moment to do, I *only* bill for
stories in the iteration.
I also don't bill for bugs I introduce... I'm good at not introducing
them in the first place, but some do slip by, so I simply fix them and
keep going. If the "bug" is the result of something I'm not directly
responsible for, then it becomes a story and is dealt with in the normal
way.

What this means is that I take a small hit on the little time wasters,
but it makes my clients happier and really gives them the feeling that
I'm working in their best interest, which means they keep coming back.

Occasionally you do get that a client that tries to weasel free work out
of you, but that can be dealt with in a firm but polite way... if they
get so upset about it that they claim they will walk, let them, you
don't need the hassle, and both of you know your work is good.

In my case, it's good work and showing results that keep my existing
clients coming back, and allows me to get new clients. Often just the
detail inherent in producing a good backlog and good iterations is
enough to impress them as most companies have had nothing but nightmares
from contractors.

my 2 cents.

- Brill Pappin