headers
William Pietri | 1 Sep 2005 01:22
Favicon
Gravatar

Re: Re: When to refactor?

On Wed, 2005-08-31 at 17:07 -0400, Ron Jeffries wrote:

> i tell them that it means
> that the first one they pick will take 10, the rest 1 each. [...]
> Some years ago, in Raleigh, I believe, Ann Anderson asked Kent Beck
> whether this was a good thing to do. He said, and I quote as closely
> as possible from memory: "If you're doing it that way, you're doing
> it wrong."

Heh. I was standing right there for that, and I may have been the one
that asked Ann. Kent's answer dumbfounded me at the time, but I must
confess that of the kinds of issues I was thinking about, I'd say 70% of
them I now could solve.

One good way is your "do it in 4" approach. For me that usually involves
the first one being somewhat lame, with additional improvements across
the three features coming over time.

Another way I deal with this is to change the story breakdown in a way
that may be cheating. For example: I'll throw in, "User views home page"
on a web app, or "User launches application" for a desktop app. Although
it's not something that would get asked for normally, once they're in
the pile, stories like that logically have to go first. They give me a
place to put a lot of the infrastructure needed to get something up and
going.

But still, for perhaps 30% of the cases, I still don't see how to do it.
E.g., with an ATM, suppose it's 5 points for a keyboard interface and 1
point each for "enter PIN", "pick account", and "enter amount". I don't
yet see how to make that other than 6, 1, and 1, no matter the order.
(Continue reading)

Permalink | Reply | 1 comment |
headers
William Pietri | 1 Sep 2005 01:52
Favicon
Gravatar

Re: When to refactor?

On Wed, 2005-08-31 at 14:06 -0400, Ron Jeffries wrote:
> On Wednesday, August 31, 2005, at 1:51:38 PM, William Pietri wrote:
> > I think there are other returns on the refactoring investment that
> > change this balance a little.
> 
> A little ... yes ...

Indeed. I think we're talking about relatively small deviations from
optimum. A few percentage points either way.

> > For example, having well-factored code
> > makes it easier to add team members and to work anywhere in the code
> > base.
> 
> Yes. And pair programming makes it MUCH easier to add team members,
> and I would suppose that we wouldn't work anywhere in the code base
> //except where there's a story//.

Well, yes and no. Perhaps you have a broader definition of working where
the story is. Working on a particular story, I sometimes miss broader
design issues. That, or I'll see a refactoring that might be a good idea
globally, but certainly isn't worth is for the particular story I'm on.
Perhaps you're more inclined to pursue those immediately?

> > It also makes estimates more reliable.
> 
> Mmmm ... I suppose so, because it keeps stories smaller, in effect.

I think it's more than that. If there are items of debt in random
locations in the code base, then stories that happen to touch those will
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ron Jeffries | 1 Sep 2005 02:26
Favicon

Re: RE: When to refactor

On Wednesday, August 31, 2005, at 6:35:00 PM, Logan, Patrick D wrote:

> "One thing that I do, when the first from a set of stories will take
> longer than the others, is estimate them as 10/1 10/1 10/1 ...
> the customer asks what that means, and i tell them that it means
> that the first one they pick will take 10, the rest 1 each.

> This is easy to understand."

> Are there customers concerned overly much that a story is done on day 3
> vs. day 2 within an iteration? I have not seen this. If the three
> stories have been selected and the total task estimates fit in the
> iteration then the customer knows that these stories will be tested
> sometime later in the iteration.

Rarely, I'd think. I could imagine an important demo or something
...

But in the cases I'm thinking about, the plan wasn't to schedule all
three, but only one in this iteration. If all three are scheduled,
it's easier, we can just call it 12 for the batch. But when
estimating for release ... we need to do something to express that
there's infrastructure to be done.

> If the customer wants to throw out the first story because it is a 10,
> then the answer is simply, "Well, now we have to do some of the same
> tasks for another story which otherwise would have been completed
> already with this first story."

> I am wondering if the customer is getting too deep into the task details
(Continue reading)

Permalink | Reply | 501 comments |
headers
Ron Jeffries | 1 Sep 2005 02:31
Favicon

Re: Re: When to refactor?

On Wednesday, August 31, 2005, at 7:22:36 PM, William Pietri wrote:

> But still, for perhaps 30% of the cases, I still don't see how to do it.
> E.g., with an ATM, suppose it's 5 points for a keyboard interface and 1
> point each for "enter PIN", "pick account", and "enter amount". I don't
> yet see how to make that other than 6, 1, and 1, no matter the order.

Yes ... and in my experience, it works just fine. The customers
understand it and can schedule as needed.

But I do think it's kind of a smell when it happens. In some way, we
weren't prepared. I'll be keeping alert for the next time it happens
near me, so I can look into it in that way that I have.

Regards,

Ron Jeffries
www.XProgramming.com
Speak the affirmative; emphasize your choice
by utterly ignoring all that you reject. -- Ralph Waldo Emerson

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ron Jeffries | 1 Sep 2005 02:47
Favicon

Re: When to refactor?

On Wednesday, August 31, 2005, at 7:52:10 PM, William Pietri wrote:

> On Wed, 2005-08-31 at 14:06 -0400, Ron Jeffries wrote:
>> On Wednesday, August 31, 2005, at 1:51:38 PM, William Pietri wrote:
>> > I think there are other returns on the refactoring investment that
>> > change this balance a little.
>> 
>> A little ... yes ...

> Indeed. I think we're talking about relatively small deviations from
> optimum. A few percentage points either way.

>> > For example, having well-factored code
>> > makes it easier to add team members and to work anywhere in the code
>> > base.
>> 
>> Yes. And pair programming makes it MUCH easier to add team members,
>> and I would suppose that we wouldn't work anywhere in the code base
>> //except where there's a story//.

> Well, yes and no. Perhaps you have a broader definition of working where
> the story is. Working on a particular story, I sometimes miss broader
> design issues. That, or I'll see a refactoring that might be a good idea
> globally, but certainly isn't worth is for the particular story I'm on.
> Perhaps you're more inclined to pursue those immediately?

Well, if we miss them, then we miss them. Not an issue, I'd think.

As for working "where the story is", my meaning is roughly this:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edmund Schweppe | 1 Sep 2005 02:17

Re: Re: Resistance to XP (was : New blog entry: The XP Oath )

dingbat99999 wrote:

> The interesting question is: why do a few measurements that illustrate
> how the team is performing (which might be "good" or "bad") all of the
> sudden result in people being "unhappy". 

If the team ends up being managed based on the metrics - rather than on 
whether or not the team is delivering - there's a great danger of the 
team being driven to do useless or wasteful things in order to make the 
metrics look better. Even when the metrics are as "obviously" good as 
reducing cycle time or reported defects per iteration.

--

-- 
Edmund Schweppe
President, Firepool Consulting, Inc.
(978) 233-5404 - http://www.firepoolconsulting.com

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
    extremeprogramming-unsubscribe <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim King | 1 Sep 2005 04:38
Gravatar

Test-Code Duplication

My friend and colleague Tom Metro (not here, but listening from a 
distance) asked me these questions about duplication between tests and code.

> Doesn't it strike you as poor for maintenance to have a bunch of things
> that might need to change in the test suite as a result of something
> changing in the code under test?
> 
> Here's a contrived scenario:
> 
> You have a class that includes a method for writing a complex record
> structure to disk, another for reading it back, and then several that
> perform operations on those records.
> 
> So if you write "pure" tests, your test for the record writing method
> will duplicate your record reading method. Your test for the record
> reading method will duplicate your record writing method. This level of
> duplication may be acceptable.
> 
> But now you've got a dozen tests that exercise the secondary processing
> (reporting) functions. If you're going to keep your tests "pure," you'll
> again replicate your record writing method.
> 
> What happens if your data structure on disk changes? All those places
> you've duplicated your record writing method will need to be updated,
> even though they weren't directly involved in testing the basic
> read/write methods.
> 
> You could certainly split out that write code into a helper function in
> your test suite, but have you really gained anything by implementing
> your write method twice in two different files?
(Continue reading)

Permalink | Reply | 582 comments |
headers
Ken Boucher | 1 Sep 2005 04:49

Re: Refactor with mercy.

--- In extremeprogramming <at> yahoogroups.com, "Phlip" <phlip2005 <at> g...> wrote:
> Ken Boucher wrote:
> 
> >> Refactor without mercy to improve the communicative ability of the
> > code.
> >
> > Or realize the code is, truly, good enough and add a new feature
> > instead.
> 
> Dude, the city of New Orleans is under about 20 feet of water right now.
> 
> Ordinarily it's only a few inches below average sea level. Either way the 
> situation is no longer tenable.

And anyone who refactored the city a month ago was clearly wasting their time.

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
    extremeprogramming-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
(Continue reading)

Permalink | Reply | 46 comments |
headers
Phlip | 1 Sep 2005 04:57
Picon
Gravatar

Re: Test-Code Duplication

Tim King wrote:

> My friend and colleague Tom Metro (not here, but listening from a
> distance) asked me these questions about duplication between tests and 
> code.

>> So if you write "pure" tests, your test for the record writing method
>> will duplicate your record reading method. Your test for the record
>> reading method will duplicate your record writing method. This level of
>> duplication may be acceptable.

Yup. They call it "Twice and Only Twice".

(I think They are Martin Fowler. Google his blog.)

>> But now you've got a dozen tests that exercise the secondary processing
>> (reporting) functions. If you're going to keep your tests "pure," you'll
>> again replicate your record writing method.
>>
>> What happens if your data structure on disk changes? All those places
>> you've duplicated your record writing method will need to be updated,
>> even though they weren't directly involved in testing the basic
>> read/write methods.

Tests are also subject to the requirement to refactor for clarity. So - in 
theory - they will merge their common code into reusable and replaceable 
modules. These will be less productized than the production modules, and 
they will self-document

Further, when the data structure on disk changes, the system should use
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Boucher | 1 Sep 2005 05:03

Re: Resistance to XP (was : New blog entry: The XP Oath )

>>> If you track 2 metrics - how fast do you implement a feature
>>> (cycle time) and how many defects come back in an iteration
>>> (defect rate) and always strive to shorten cycle time and
>>> reduce defect rates - what else matters?
> 
>> 1) What's a 'feature'? Is is a card? A unit test? An acceptance
>> test?
>> Is a new screen that breaks down totals by region a feature?
>> Is changing the CSS for a custom look for a customer a feature?
>> Are they comparable?
> 
> Well, what if a "feature" is anything the customer asked for in the
> iteration planning meeting, requiring no more than, oh, three days'
> work for one pair?

So if we do a lot of half day cards one iteration and a couple three
day cards in our next iteration, how do we adjust the metric?
If we base our metric on peds, what happens when we learn more
and adjust the estimate on tasks we've gotten good at downward?

>> 2) I've witnessed an organization that reduces defects
>> by making it difficult to implement anything. The developers spend
>> immense amounts of time filling out forms (ie. not writing code).
>> They've become very good at reducing defects per  iteration.

> I'm thinking that the features metric John just suggested would look
> pretty bad in this environment.

yeah, but that defect score is great. And if we just went from 3 day
cards to half day cards then the features don't look as bad. We may
(Continue reading)

Permalink | Reply | 1 comment |

Gmane