I tend to think that everything is negotiable. It is just that some
things are more obviously good choices than others and as such require
little or nothing in the way of negotiation. "What, you say you're going
to actually test your code? , well, cool. Sounds good. Now what were
you saying about 100 servers again?"
I have seen far too much code to believe that the first class you
mention *isn't* negotiable, and there are myriad reasons why the code is
as bad as it is, and I would be willing to bet that one of the reasons
is that no one ever negotiated for it. Perhaps you mean that it isn't
negotiable for you, or that if push comes to shove and that type of
quality is on the chopping block, then you would walk away. I respect
that. The best negotiating tactic is recognizing the freedom to walk
away.
Jef Newsom | Improving Enterprises, LLC |
<|
Improving - It's what we do.
From: extremeprogramming (AT) yahoogroups (DOT) com
[mailto:extremeprogramming (AT) yahoogroups (DOT) com] Behalf
yahoogroups (AT) jhrothjr (DOT) com
Sent: Thursday, July 13, 2006 7:54 PM
To: extremeprogramming (AT) yahoogroups (DOT) com
Subject: Re: [XP] The Shadow of the Future
Message
From: "Jef L Newsom"
<@yahoogroups.at.jhrothjr.com
<%40yahoogroups.at.jhrothjr.com>
To: "extremeprogramming (AT) yahoogroups (DOT) com
<mailto:extremeprogramming%40yahoogroups.com"
<@yahoogroups.at.jhrothjr.com
<%40yahoogroups.at.jhrothjr.
com>
Sent: Thursday, July 13, 2006 5:57 PM
Subject: RE: [XP] The Shadow of the Future
To clarify, I was trying to say that not putting quality on the table
as
something that can be prioritized or traded off is nearing
passive-aggressive. I think it should be on the table. And I think
that
in 99.9% of the cases, once everything is sorted, it should be at or
near the top of the stack, because I believe that developers are a
truly
critical stakeholder.
It depends on what you mean by quality. I factor quality into
three buckets: first is the code quality that's required to maintain a
given
level of design goodness and a steady velocity.
The next level of code quality is that required to meet some kind
of domain or regulatory standard. A decent XP team will probably
be producing code to a satisfactory level for most commercial
uses, but most likely won't be producing code to a life or safety
critical standard. That will require additional practices.
The third piece is quality as seen by the user of the software.
Code quality is only one piece of that, and not the largest piece.
The first is not negotiable except under extraordinary circumstances.
Most customers expect that the software will continue to be
maintainable, and expect that the team will make progress at a
predictable rate. This level of quality is a given. Trying to reduce
it will produce software that is less and less maintainable, and
will produce steadily slowing velocity until progress grinds to
a halt.
Someone who thinks: "Well, they'll go faster if they don't do
all this stuff", is sadly mistaken.
The other two are something that the customer has to decide.
John Roth
Cheers,
Jef Newsom | Improving Enterprises, LLC |
<>
< <|
Improving - It's what we do.
[Non-text portions of this message have been removed]
To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com
To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*To visit your group on the web, go to:
<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com
<*Your use of Yahoo! Groups is subject to:

You are, I think, missing the point. This is the XP
mailing list. There are some things we understand
from experience, and one of them is that the basic
level of code quality directly corresponds to velocity.

If you think you can improve velocity by letting
go of quality, you are sadly mistaken, and
"everything is negotiable" has nothing whatever
to do with it.

See comments inline.

Message
From: "Jef L Newsom"
<@yahoogroups.at.jhrothjr.com>
To: "extremeprogramming (AT) yahoogroups (DOT) com"
<@yahoogroups.at.jhrothjr.com>
Sent: Thursday, July 13, 2006 8:09 PM
Subject: RE: [XP] The Shadow of the Future


>I tend to think that everything is negotiable. It is just that some
things are more obviously good choices than others and as such require
little or nothing in the way of negotiation. "What, you say you're going
to actually test your code? , well, cool. Sounds good. Now what were
you saying about 100 servers again?"

I have seen far too much code to believe that the first class you
mention *isn't* negotiable, and there are myriad reasons why the code is
as bad as it is, and I would be willing to bet that one of the reasons
is that no one ever negotiated for it.

Was any of that code produced by an XP team that was
maintaining a constant velocity and decent design quality?

If not, your comment is irrelevant to this discussion.

Perhaps you mean that it isn't
negotiable for you, or that if push comes to shove and that type of
quality is on the chopping block, then you would walk away. I respect
that. The best negotiating tactic is recognizing the freedom to walk
away.

Absolutely. However, that's not the issue here.

John Roth

>
>
>
Jef Newsom | Improving Enterprises, LLC |
<|
Improving - It's what we do.
>
>
>

From: extremeprogramming (AT) yahoogroups (DOT) com
[mailto:extremeprogramming (AT) yahoogroups (DOT) com] Behalf
yahoogroups (AT) jhrothjr (DOT) com
Sent: Thursday, July 13, 2006 7:54 PM
To: extremeprogramming (AT) yahoogroups (DOT) com
Subject: Re: [XP] The Shadow of the Future
>
>
>
>
Message
From: "Jef L Newsom"
<@yahoogroups.at.jhrothjr.com
<%40yahoogroups.at.jhrothjr.com>
To: "extremeprogramming (AT) yahoogroups (DOT) com
<mailto:extremeprogramming%40yahoogroups.com"
<@yahoogroups.at.jhrothjr.com
<%40yahoogroups.at.jhrothjr.
com>
Sent: Thursday, July 13, 2006 5:57 PM
Subject: RE: [XP] The Shadow of the Future
>
>To clarify, I was trying to say that not putting quality on the table
as
>something that can be prioritized or traded off is nearing
>passive-aggressive. I think it should be on the table. And I think
that
>in 99.9% of the cases, once everything is sorted, it should be at or
>near the top of the stack, because I believe that developers are a
truly
>critical stakeholder.
>
It depends on what you mean by quality. I factor quality into
three buckets: first is the code quality that's required to maintain a
given
level of design goodness and a steady velocity.

The next level of code quality is that required to meet some kind
of domain or regulatory standard. A decent XP team will probably
be producing code to a satisfactory level for most commercial
uses, but most likely won't be producing code to a life or safety
critical standard. That will require additional practices.

The third piece is quality as seen by the user of the software.
Code quality is only one piece of that, and not the largest piece.

The first is not negotiable except under extraordinary circumstances.
Most customers expect that the software will continue to be
maintainable, and expect that the team will make progress at a
predictable rate. This level of quality is a given. Trying to reduce
it will produce software that is less and less maintainable, and
will produce steadily slowing velocity until progress grinds to
a halt.

Someone who thinks: "Well, they'll go faster if they don't do
all this stuff", is sadly mistaken.

The other two are something that the customer has to decide.

John Roth
>
>Cheers,
>>
>Jef Newsom | Improving Enterprises, LLC |
><>
< <|
>Improving - It's what we do.
>>
>
>
>
>
>
[Non-text portions of this message have been removed]

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

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

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

yahoogroups (AT) jhrothjr (DOT) com wrote:
You are, I think, missing the point. This is the XP
mailing list. There are some things we understand
from experience, and one of them is that the basic
level of code quality directly corresponds to velocity.

If you think you can improve velocity by letting
go of quality, you are sadly mistaken, and
"everything is negotiable" has nothing whatever
to do with it.

I don't think that's entirely the case. I agree it's true with some
types of code quality. Writing new buggy code, for example, is a big
productivity killer immediately. But I don't think bad design is as big
a problem in the short term.

Many teams are productive with poorly factored systems because they know
where the bodies are buried. The costs of a bad broad design are more
long term: new developers will have a hard time getting up to speed,
people will tend to specialize because it's hard to get into unfamiliar
areas of code, truck factor can be a big risk, and the system may resist
unnecessarily certain new kinds of change. But in the short and possibly
the medium term, cutting back on refactoring may not be an insane
business decision -- if you can and will pay the debt later, and the
business win can pay for the increased cost in delayed cleanup.

I also think the situation can be different when the existing design is
hard to test. I have certainly worked on projects on large legacy code
bases where getting any useful test coverage was slow and arduous, and
at first didn't even make much impact on bug rates, as the bugs were
mainly from legacy code. In that case the right long-term thing to do is
to suck it up and clean up or rewrite existing code. But I think it's a
legitimate business choice to say, "Now is not the right time to cut our
productivity in half, even though the long-term gains will be substantial."

course, I still will vigorously question the desire to delay paying
down code debt. When people say "later", they often mean "let's ignore
that". But sometimes they really mean it and really have the discipline
to pull it off.

William

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

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

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

From: "William Pietri" <william.at.scissor.com (AT) yahoogroups (DOT) at.jhrothjr.com>
To: "extremeprogramming (AT) yahoogroups (DOT) com"
<@yahoogroups.at.jhrothjr.com>
Sent: Thursday, July 13, 2006 10:40 PM
Subject: Re: [XP] The Shadow of the Future

yahoogroups (AT) jhrothjr (DOT) com wrote:
>You are, I think, missing the point. This is the XP
>mailing list. There are some things we understand
>from experience, and one of them is that the basic
>level of code quality directly corresponds to velocity.
>>
>If you think you can improve velocity by letting
>go of quality, you are sadly mistaken, and
>"everything is negotiable" has nothing whatever
>to do with it.
>>
>
I don't think that's entirely the case.

Well, yes. There are nuances. I'm coming from a
viewpoint where any specific developer, or team,
has a process at a specific point in time that will
maintain a given level of code quality and velocity.
In other words, they're just trucking along, doing
whatever they've done in the recent past.

I regard this as the normal situation with a
reasonably well disciplined team: they've got
a process, whatever it is, and they're sticking
with it until they decide explicitly to change it.

If you want to change something, that's going to
have both short and long term effects to quality,
velocity and cost.

As you point out below, and as the examples
at the start of this thread point out, there are
times when you don't want to take the short-term
hit to gain the long term benefit. At least in the
short term.

However, that's quite different from simply
coming in and telling a dev team that they
can move faster if they drop quality. I can
get started faster if I don't take the time to
tie my shoelaces, but I'm not going to get
very far.

It's too broad a suggestion, and it carries
the assumption that somehow having
more defects will let one develop faster.
As the saying goes, if it doesn't have to
work, I can have it for you tomorrow.

In most situations I've seen where the
customer needs something out right
away (for any reason), it's far better
to cut scope than to cut quality.

I agree it's true with some
types of code quality. Writing new buggy code, for example, is a big
productivity killer immediately. But I don't think bad design is as big
a problem in the short term.

Many teams are productive with poorly factored systems because they know
where the bodies are buried. The costs of a bad broad design are more
long term: new developers will have a hard time getting up to speed,
people will tend to specialize because it's hard to get into unfamiliar
areas of code, truck factor can be a big risk, and the system may resist
unnecessarily certain new kinds of change. But in the short and possibly
the medium term, cutting back on refactoring may not be an insane
business decision -- if you can and will pay the debt later, and the
business win can pay for the increased cost in delayed cleanup.

Minor terminology nit here. I don't use the term "refactoring"
for major code restructuring. It's too confusing. Cutting back on
refactoring, in the sense of the code cleanup you do in the TDD loop,
will kill you quickly. Defering major restructurings may make good
business sense, as long as they aren't defered indefinitely.

I also think the situation can be different when the existing design is
hard to test. I have certainly worked on projects on large legacy code
bases where getting any useful test coverage was slow and arduous, and
at first didn't even make much impact on bug rates, as the bugs were
mainly from legacy code. In that case the right long-term thing to do is
to suck it up and clean up or rewrite existing code. But I think it's a
legitimate business choice to say, "Now is not the right time to cut our
productivity in half, even though the long-term gains will be
substantial."

I've usually noted that getting code under test has a pretty
immediate payoff: it's faster for me to make a change, even
with writing a bunch of tests, than it is to hack it in and then
deal with trying to debug the resulting mess.

It may not, of course, have an immediately observable
effect on overall defect rates. That requires getting a
substantial amount of code under test.

course, I still will vigorously question the desire to delay paying
down code debt. When people say "later", they often mean "let's ignore
that". But sometimes they really mean it and really have the discipline
to pull it off.

It would be nice if that happened with some frequency.

John Roth
--
William

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

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

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Friday, July 14, 2006, at 12:40:06 AM, William Pietri wrote:

Many teams are productive with poorly factored systems because they know
where the bodies are buried. The costs of a bad broad design are more
long term: new developers will have a hard time getting up to speed,
people will tend to specialize because it's hard to get into unfamiliar
areas of code, truck factor can be a big risk, and the system may resist
unnecessarily certain new kinds of change. But in the short and possibly
the medium term, cutting back on refactoring may not be an insane
business decision -- if you can and will pay the debt later, and the
business win can pay for the increased cost in delayed cleanup.

I don't recall ever seeing that actually happen have you?

More importantly, I can tell within two days that poorly designed
code is slowing me down. My somewhat educated guess is that it's
harmful even in the near term.

I also think the situation can be different when the existing design is
hard to test. I have certainly worked on projects on large legacy code
bases where getting any useful test coverage was slow and arduous, and
at first didn't even make much impact on bug rates, as the bugs were
mainly from legacy code. In that case the right long-term thing to do is
to suck it up and clean up or rewrite existing code. But I think it's a
legitimate business choice to say, "Now is not the right time to cut our
productivity in half, even though the long-term gains will be substantial."

I'm not sure how this fits into the tradeoff against quality
question. Are you saying that in this situation you would not try to
hold quality at least steady?

course, I still will vigorously question the desire to delay paying
down code debt. When people say "later", they often mean "let's ignore
that". But sometimes they really mean it and really have the discipline
to pull it off.

Really? Tell me of the times you've seen this, please.

Ron Jeffries
www.XProgramming.com
I cannot find my duck.

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

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

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Ron Jeffries wrote:
>But in the short and possibly
>the medium term, cutting back on refactoring may not be an insane
>business decision -- if you can and will pay the debt later, and the
>business win can pay for the increased cost in delayed cleanup.
>
>
I don't recall ever seeing that actually happen have you?

Sure. I have personally deferred big refactorings until after
time-critical releases.

I don't think that sort of behavior is uncommon or necessarily bad. When
evaluating one team of my acquaintance I asked each developer about
their behaviors relating to debt and cleanup. They said that whenever
their managers asked them to rush something, once the deadline was past
the developers could happily ask for a couple of days to tidy things up
properly, and they felt that was enough to keep things on an even keel.

However, I still generally advise people to avoid that. Taking on debt
is a risky thing, and a lot of businesses are run as a continuous series
of crises, each one of which seems like a reasonable cause for taking on
a bit more debt.

More importantly, I can tell within two days that poorly designed
code is slowing me down. My somewhat educated guess is that it's
harmful even in the near term.

I don't think whether it's slowing you down is the exact issue. It's
whether the cost of cleanup is greater than the cost of not cleaning up
over some period of time. For any cleanup, there's a sufficiently short
time horizon that makes the cleanup the wrong choice. And given infinite
time, all cleanups make sense.


>I also think the situation can be different when the existing design is
>hard to test. I have certainly worked on projects on large legacy code
>bases where getting any useful test coverage was slow and arduous, and
>at first didn't even make much impact on bug rates, as the bugs were
>mainly from legacy code. In that case the right long-term thing to do is
>to suck it up and clean up or rewrite existing code. But I think it's a
>legitimate business choice to say, "Now is not the right time to cut our
>productivity in half, even though the long-term gains will be substantial."
>
>
I'm not sure how this fits into the tradeoff against quality
question. Are you saying that in this situation you would not try to
hold quality at least steady?

I'd try to hold quality steady, but I don't believe that can really be
done without automated tests. I'd do what automated testing I could. But
when dealing with large, poorly factored, highly coupled code bases,
I've been in situations where usefully testing new code was very
expensive, far more expensive than the short-term benefit. If money in
the future is significantly cheaper than money today, the rational
response is to add new code within the existing infrastructure, thus
increasing debt.

I firmly believe that in the long run, getting the code base under test
is the right choice, though.


>course, I still will vigorously question the desire to delay paying
>down code debt. When people say "later", they often mean "let's ignore
>that". But sometimes they really mean it and really have the discipline
>to pull it off.
>
>
Really? Tell me of the times you've seen this, please.

If you look at people dealing with their finances, it happens all the
time. People get into debt then slowly dig their way out later. I see it
happen in software, too. Not often enough, but I see it happen.

A good example is a client of mine that brought me in to do a
mid-project evaluation on the product of an outsourcing team. They had
gone with the outsourcer because they didn't initially have development
staff, and because they had a fixed external deadline by which they had
promised the product. (Think of it as a major trade show, but one that
only comes every few years. Missing the deadline would mean the end of
the project.) Their goal was to get the first version out and then bring
the work back in house, with a smaller team than the outsourcer, one
that matched the expected long-term workload.

The plan sounded reasonable, but as you'd expect, the outsourcing firm
produced code that was mostly functional, but pretty much
unmaintainable. After all, none of them had really ever maintained code;
why would they know how to write for maintenance? When I told my client
that their net cheapest option was to tear it down and start again with
either a better team or after extensive retraining of the one they had,
they were naturally unhappy. Given the time constraints, starting fresh
would mean no chance of hitting their deadline. the other hand,
staying the course would mean a different kind of disaster after 1.0.

In the end, we compromised. The strategy was to get something minimal
but satisfactory out the door by the deadline, but devote all extra
resources to training and cleanup. Then, after the crisis was past, the
majority of development time would be spent on cleanup. Five months on,
they're sticking to the plan: they have consistently devoted resources
to improving practices, and now that the product is approaching beta,
they are actively paying down the accumulated debt, scheduling story
cards for chunks of cleanup. But I think it's only recently that they've
moved deficit to surplus, and it will be a while before they're down to
a safe level of debt.

In this case, I'm pretty sure they'll stick with it. The brush with
death scared them, sort of like a major health problem can scare
somebody into getting in shape.

William

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

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

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Saturday, July 15, 2006, at 4:16:51 AM, William Pietri wrote:

Ron Jeffries wrote:
But in the short and possibly
the medium term, cutting back on refactoring may not be an insane
business decision -- if you can and will pay the debt later, and the
business win can pay for the increased cost in delayed cleanup.

>>
>I don't recall ever seeing that actually happen have you?
>

Sure. I have personally deferred big refactorings until after
time-critical releases.

I can see that a sufficiently expert, and sufficiently "quality"
oriented person might do such a thing. But did you do that by
putting quality "on the table", or by making the determination
somehow internally?

Now I'm not a fan of big refactorings in general, and usually think
that they are in fact evidence that we haven't been keeping up on
quality, and probably also evidence that we haven't figured out how
to do refactorings more incrementally. But certainly I wouldn't go
so far as to reduce productivity by taking on massive rework or
testing efforts.

I don't think that sort of behavior is uncommon or necessarily bad. When
evaluating one team of my acquaintance I asked each developer about
their behaviors relating to debt and cleanup. They said that whenever
their managers asked them to rush something, once the deadline was past
the developers could happily ask for a couple of days to tidy things up
properly, and they felt that was enough to keep things on an even keel.

That would be a very unusual organization in my experience. And even
with those guys, I kind of wish there was a magical metric that we
could use to see whether they're really keeping up. My best is that
they're falling behind.

However, I still generally advise people to avoid that. Taking on debt
is a risky thing, and a lot of businesses are run as a continuous series
of crises, each one of which seems like a reasonable cause for taking on
a bit more debt.

Yep. That's my view as well.

>More importantly, I can tell within two days that poorly designed
>code is slowing me down. My somewhat educated guess is that it's
>harmful even in the near term.

I don't think whether it's slowing you down is the exact issue. It's
whether the cost of cleanup is greater than the cost of not cleaning up
over some period of time. For any cleanup, there's a sufficiently short
time horizon that makes the cleanup the wrong choice. And given infinite
time, all cleanups make sense.

True, but the trend is what's important. We'll surely go in some
kind of pulsing mode, sometimes catching up on cleanup, sometimes
falling behind. Falling behind as a matter of policy, by offering up
our technical quality concerns to people who can't really understand
them, troubles me.

I do think, and maybe this is all that Jef meant, that we should
discuss any extra investments we're making in "quality". If we have
been doing some extra refactoring, or extra testing, I can see
dialing that back down a bit. I think that not testing what we write
right now, for example, would likely be a Bad Idea.

I also think the situation can be different when the existing design is
hard to test. I have certainly worked on projects on large legacy code
bases where getting any useful test coverage was slow and arduous, and
at first didn't even make much impact on bug rates, as the bugs were
mainly from legacy code. In that case the right long-term thing to do is
to suck it up and clean up or rewrite existing code. But I think it's a
legitimate business choice to say, "Now is not the right time to cut our
productivity in half, even though the long-term gains will be substantial."

I don't favor the big refactoring or rewrite, with rare exceptions.
I think that it encourages the behavior of building up big debt, and
that a team that got itself into such a situation got there by what
they did every day, not by something they should have done for one
week a quarter.

I'm not suggesting cutting productivity. I'm suggesting that a very
strong focus on quality in the current work is a key part of being
productive, and that putting that on the table for tradeoff simply
does not work.

It's becoming clear that we need to deal here with more specific
examples, because some of us are envisioning being asked to drop
TDD, while others are envisioning being asked not to do some huge
productivity-killing refactoring.
>>
>I'm not sure how this fits into the tradeoff against quality
>question. Are you saying that in this situation you would not try to
>hold quality at least steady?

I'd try to hold quality steady, but I don't believe that can really be
done without automated tests. I'd do what automated testing I could. But
when dealing with large, poorly factored, highly coupled code bases,
I've been in situations where usefully testing new code was very
expensive, far more expensive than the short-term benefit. If money in
the future is significantly cheaper than money today, the rational
response is to add new code within the existing infrastructure, thus
increasing debt.

Before we take a salary advance, we should consider very seriously
whether we will pay it back. I think the same is true when we
consider taking out an advance on our refactoring.

I firmly believe that in the long run, getting the code base under test
is the right choice, though.

Yup. And I'm talking more about steady state than you are.

course, I still will vigorously question the desire to delay paying
down code debt. When people say "later", they often mean "let's ignore
that". But sometimes they really mean it and really have the discipline
to pull it off.

>>
>Really? Tell me of the times you've seen this, please.
>

If you look at people dealing with their finances, it happens all the
time. People get into debt then slowly dig their way out later. I see it
happen in software, too. Not often enough, but I see it happen.

I suppose that it does happen. I don't think it's the way to bet. I
see teams who don't even understand how to tell that they are deep
in debt. They think it's normal to have to eat like a raccoon in the
city.

In this case, I'm pretty sure they'll stick with it. The brush with
death scared them, sort of like a major health problem can scare
somebody into getting in shape.

I hope so. They're lucky to have someone they trust to advise them.
Even so, it'll be hard to stick with the regimen.

Ron Jeffries
www.XProgramming.com
Logic is overrated as a system of thought.

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

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

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to:

Ron Jeffries wrote:
Before we take a salary advance, we should consider very seriously
whether we will pay it back. I think the same is true when we
consider taking out an advance on our refactoring.

, I agree completely. For teams new to agile methods, I am always
vigorous in telling them to avoid consciously adding debt, as that is
where rewrites are born. That's what
made me bring up this situation: for once, somebody had legitimate
business circumstances that made taking on debt a plausible strategy. I
still doubt that I'll recommend the approach, but I may push them less
hard on cleaning up their current debt than I otherwise would.


>If you look at people dealing with their finances, it happens all the
>time. People get into debt then slowly dig their way out later. I see it
>happen in software, too. Not often enough, but I see it happen.
>
>
I suppose that it does happen. I don't think it's the way to bet. I
see teams who don't even understand how to tell that they are deep
in debt. They think it's normal to have to eat like a raccoon in the
city.

Heh. That's completely true, and a great image.

William

To Post a message, send it to: extremeprogramming (AT) eGroups (DOT) com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe (AT) eGroups (DOT) com

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

<*To visit your group on the web, go to:

<*To unsubscribe from this group, send an email to:
extremeprogramming-unsubscribe (AT) yahoogroups (DOT) com

<*Your use of Yahoo! Groups is subject to: