> -----Original Message-----
> From: Jonas Karlsson [mailto:karlsson@...]

> I get the impression that despite "You aren't going to need it",  in
> order to refactor effectively, some judgements about what is likely to
> change in the future must be made.

There are two things to think about here.  There is the general need to
keep code flexible, and there is the anticipation of new features or
changes.  The two are fundamentally different.

In an XP project we refactor to:
1. Make the code as simple as possible.
2. Eliminate any duplication.
3. Make the code as clear as possible.
4. Enhance the flexibility of the code.

But we do not write code in anticipation of anticipated feature changes.

Point four above is the one you are worried about.  What are the
principles that are employed to create flexible code?  The answer is
that they are the same principles of dependency management that we have
always employed in object oriented design.

This does not mean that you go off generalizing your code and building
frameworks that aren't explicitly needed.  It does however mean that you
pay close attention to Dependency Inversion, Interface Segregation,
Substitutability, etc.  The principles of OOD (See the publications
section of http://www.objectmentor.com) still apply in XP.

Indeed, the principles apply all the more in XP because refactoring is
so critically important.  If the code is not flexible it is difficult to
refactor.  The dependency management principles keep the code as
flexible as possible so that it can be refactored when new features and
new generalities are needed.


Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

> -----Original Message-----
> From: Jonas Karlsson [mailto:karlsson@...]

>
>
> Hi,
>  We're trying to introduce XP practices on a fairly small
> project (3-5 developers).  I think Bob Martin wrote that he couldn't
> think of a case where using XP on a project would add risk

(blush) I should have couched that statement in a lot more context than
I did.  The orignial poster was suggesting that XP was riskier if you
had developed that kind of app before, and if the requirements were
stable.  My statement should have read:  "I can't think of any reason
why XP adds risk if you have pre-knowledge, or stability of
requirements."

Certainly XP has not been tried for all project types, and there is
therefore risk.  Most importantly, XP has not been tried for very large
projects.  While I am confident that some XP-related approach will work
in the large, there is certainly risk.


Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

> -----Original Message-----
> From: Patrick Logan [mailto:patrickdlogan@...]

> Robert C. Martin writes:
>  >
>  > It astounds me how often I get asked this question.  People have
>  > this very odd view of XP.  They think that it eliminates all good
>  > design and prevents any kind of intelligent thought about software
>  > structure.
>  >
>  > Of course I have not given up any of the things you mention.  Look
>  > at the way I wrote my book.  How many times did I create designs
>  > and write code, only to back away and say "ick!", and then refactor
>  > the designs and the code into something better?  That was the
>  > fudamental pattern throughout the book!  it is also one of the
>  > fundamental patterns of XP.
>
> I think this is a fundamental issue with XP worth broadcasting far and
> wide. People, including myself, would benefit from seeing how an XP
> product evolves test-by-test.

I hope you can come to the next XP Immersion, 2/28/00 in Santa Cruz.  In
one of the sessions, we spend about two hours having Kent and a partner
refactor, with tests, a small program; displaying their actions on the
big screen.  It's a *very* enlightening presentation.  Of course then
you get to spend several hours trying it with a few different pair
partners, as you develop the application your are working on for the
class.


Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

> -----Original Message-----
> From: Dave Thomas [mailto:Dave@...]

> "Robert C. Martin" <rmartin@...> writes:
>
> > Dave Thomas <Dave@...> wrote in message
> > > So I'm only allowed to add a nightly job to back up the repository
> > >only after we've had a disk crash and lost all the source?
> >
> > If your customer has not made nightly backups a priority, then they
> > must be willing to lose all the source.
>
>
> Well, most of my customers frankly aren't interested in source code,
> version control, logging and the like. They're things that are below
> the horizon for them, but vital for the process that delivers what
> they *do* want.

Right.  And as I said in another message, *you* are the customer of the
development environment, and therefore get to specify what features it
has.  If you think it needs nightly backups, then you put it in.
However, if your customer does not demand that you back up the master
database of his system every night, even after you have warned him of
the consequences, then you don't do it.


Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

> -----Original Message-----
> From: Dave Thomas [mailto:Dave@...]

> Sometimes, though, tracing is what you do to find out _why_ a unit
> test failed. Adding tracing retroactively when a particular
> test fails
> way down the development pike may be far more expensive that asking
> for it as you go along.

In a large system, trace logs become invaluable when problems occurr. In
small systems, or systems that are not particularly prone to error, they
are not particularly useful.  In the past, I have grown the system
without trace logs until I felt they were necessary; and then I went
back and added them to the modules that were the least stable.  In a few
instances, I added them throughout the system.

Adding trace statements later is not much more expensive than adding
them at first.  Adding them selectively saves both time and effort.
Adding them after the fact allows me to be selective.

BTW, I presume that the extensive unit testing of XP (which has to be
seen to be believed) will push back the threshold on the need for
tracing quite a ways.

Finally, trace statements make life easier for engineers.  Given certain
failure modes, the engineers can use the trace logs to determine what
went wrong.  But does this add value to the customer?  In certain
circumstances it certainly does.  In others, it's not so clear.  Does
MS-Word create a trace log for example?  Do the zillions of consumers
ever send that trace log into Microsoft when MS-Word fails?

Thus, I would suggest that even the creation of a trace log is something
that the customer should agree to.  Engineers may propose it as a story:
"increase speed and accuracy of problem diagnosis".  But if the
customers don't view this as an important problem to solve, they have a
right to prevent you from expending their money on it.


Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

> -----Original Message-----
> From: Patrick Logan [mailto:patrickdlogan@...]

> That said, I have not read much about how to apply XP to complex
> multi-user systems. Are functional tests where multi-user testing is
> to take place? Is there ever anything a functional test
> should include
> that a unit test does not?

Functional tests are defined by the customer.  They are a kind of
restatement of the user stories in very formal terms.  They provide
certain stimuli to the system, and expect certain outputs.

If there are user stories that demand multi-user behavior, then there
should be functional tests that prove that the multi-user behavior
exists.  I presume, however, that no customer is going to understand the
insidious nature of multi-user problems; and that the multi-user
functional tests will therefore be a bit naive.  I'd be looking closely
at them and augmenting them to make sure they cover as many boundary
conditions as feasible.

Unit tests can test multi-threaded stuff.  A single unit test can create
multiple tasks and provide the stimuli that make them interact.
Programmers will want to create unit tests that stress the interactions
between tasks.  Still, it's difficult to find the nasty reentrancy
problems that way.  Sometimes the best approach is just a monte-carlo
test with random timings.


Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

Kent,

These are encouraging words for us old dogs.  This particular aspect of
things is a tough one to deal with on a personal level - I'm in the throes
of it myself.  Thanks.

- Ed

----- Original Message -----
>From: "Kent Beck" <kentbeck@...>
To: <extremeprogramming@egroups.com>
Sent: Tuesday, January 04, 2000 1:11 AM
Subject: [extremeprogramming] Re: You Aren't Gonna Need It Again


> "Who knows, I may be happy to fling my foresight to the four winds?"
>
> Trade it, rather, for greater focus, less stress, simpler designs, and
> faster development. That's what I did about five years ago, trying to
> emulate what Ward does naturally.
>
> Just because you don't guess about tomorrow's requirements doesn't mean
that
> experience is any less important. The experienced programmer can see
> problems and solutions much sooner than a newbie. The experienced extreme
> programmer simply leaves tomorrow problems until tomorrow.
>
> For example, I know 10-12 tricks to implementing multi-currency
> calculations. No one system has ever needed more than half of them.
However,
> I have absolute confidence that when the time comes I will see the need
for
> a trick and I will know how to retrofit it. If in the meantime I discover
a
> new trick, I won't have a bunch of might-be-useful stuff getting in the
way.
>
> That said, giving up my own need to "guess and be right" about design was
> personally painful. Now I'm happy that I made the switch. You'll have to
> decide for yourself whether the pain might be worth it. I suggest you
> shorten your design horizon a little at a time, or try a little project
with
> completely evolutionary design.
>
> Kent
>
>
>
> ------------------------------------------------------------------------
> To Post a message, send it to:   extremeprogramming@eGroups.com
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ------------------------------------------------------------------------
> Want to send money instantly to anyone, anywhere, anytime?
> You can today at X.com - and we'll give you $20 to try it!  Sign
> up today at X.com.  It's quick, free, & there's no obligation!
> http://click.egroups.com/1/332/0/_/263270/_/946966421
>
> -- Talk to your group with your own voice!
> -- http://www.egroups.com/VoiceChatPage?listName=extremeprogramming&m=1
>
>
>

"Who knows, I may be happy to fling my foresight to the four winds?"

Trade it, rather, for greater focus, less stress, simpler designs, and
faster development. That's what I did about five years ago, trying to
emulate what Ward does naturally.

Just because you don't guess about tomorrow's requirements doesn't mean that
experience is any less important. The experienced programmer can see
problems and solutions much sooner than a newbie. The experienced extreme
programmer simply leaves tomorrow problems until tomorrow.

For example, I know 10-12 tricks to implementing multi-currency
calculations. No one system has ever needed more than half of them. However,
I have absolute confidence that when the time comes I will see the need for
a trick and I will know how to retrofit it. If in the meantime I discover a
new trick, I won't have a bunch of might-be-useful stuff getting in the way.

That said, giving up my own need to "guess and be right" about design was
personally painful. Now I'm happy that I made the switch. You'll have to
decide for yourself whether the pain might be worth it. I suggest you
shorten your design horizon a little at a time, or try a little project with
completely evolutionary design.

Kent

Dave Thomas writes:
  > >
  > > (1) What kind of tracing is *that* expensive?
  >
  > Just the effort of adding the calls to the hundreds of potential
  > sites across the code...

Bringing this back to XP, this problem seems to be addressed by
OnceAndOnlyOnce. Instead of direct variable access, you would use
getters and setters. There is one place to trace the setting of a
variable.

--
Patrick Logan    patrickdlogan@...

Patrick Logan <patrickdlogan@...> writes:

> Used to be we were discussing XP in a programming forum. Now we're
> discussing programming in an XP forum. Turn-about is fair play? 8^/
>
> Dave Thomas writes:
>  >
>  > Sometimes, though, tracing is what you do to find out _why_ a unit
>  > test failed. Adding tracing retroactively when a particular test
>  > fails way down the development pike may be far more expensive that
>  > asking for it as you go along.
>
> (1) What kind of tracing is *that* expensive?

Just the effort of adding the calls to the hundreds of potential sites
across the code...

> I don't know about Ruby or AOP, so I am not sure what you mean by
> adding tracing "orthogonally".

In Ruby, you define a class using something like:

   class Person

     attr :age, writable
     attr :sex

     <method definitions etc...>
   end

'class Person' declares a class. The 'attr's declare two attributes
(externally accessible object state), the first one mutable. I could
change Dave's age using

    dave = person.new('Male')
    dave.age = 137  # seems like it some days

Now, say I was having a problem with someone, somewhere, setting Dave's
age wrongly. I can override the mutator for the object 'dave'. I can
do this without touching the original definition of class Person-this
changes the definition for just this instance of a Person:

    def dave.age=(newAge) {
       trace "Age changed from #{@age} to #{newAge}"
       @age = newAge
    end

All assignments to dave.age now get traced.

Alternatively, I could write code that changes the meaning of 'attr'
for all Person objects, so every assignment to any Person attribute
will get logged. I could even change the system so that every
assignment to every attribute in any object gets traced.

It's orthogonal because I can do all this without changing the files
containing the class definitions themselves - the tracing is
orthogonal to the application.

Ruby is like Smalltalk, in that it lets you get to get guts of the
language. It supports meta-classes, so you can effectively change the
semantics of the language if you need to. Andy and I are currently
looking to see if we can implement DbC for Ruby exclusively in Ruby
(the jury's still out).


AOP is a different way of inserting code at certain spots throughout a
system. Again, the code to insert, and the patterns defining where to
insert it, is outside the body of the application.


Regards

Dave


--
Thomas Consulting.
Innovative and successful developments with Unix, Java, C, and C++.

Now in bookstores:
  The Pragmatic Programmer.  www.pragmaticprogrammer.com/ppbook/

At 04:01 PM 1/3/2000 -0800, you wrote:
>I think this is a fundamental issue with XP worth broadcasting far and
>wide. People, including myself, would benefit from seeing how an XP
>product evolves test-by-test.

In eXtreme Programming Installed, scheduled to reach AWL in March, we are
experimenting with showing a small product in evolution. No promises yet,
but your interest encourages us to try.

Regards,

Ron Jeffries
Extreme Programming Training and Consultation
ronjeffries@...
web pages: http://www.XProgramming.com, http://www.armaties.com
pgp key: http://www.armaties.com/pgpkey.htm

Used to be we were discussing XP in a programming forum. Now we're
discussing programming in an XP forum. Turn-about is fair play? 8^/

Dave Thomas writes:
  >
  > Sometimes, though, tracing is what you do to find out _why_ a unit
  > test failed. Adding tracing retroactively when a particular test
  > fails way down the development pike may be far more expensive that
  > asking for it as you go along.

(1) What kind of tracing is *that* expensive?

(2) After you develop some good tracing utilities, isn't the cost
     reduced?

  > Of course, the ideal solution here is AOP, or features such as those
  > in Ruby that let you add tracing orthogonally to the source.

I don't know about Ruby or AOP, so I am not sure what you mean by
adding tracing "orthogonally".

--
Patrick Logan    patrickdlogan@...

Patrick Logan <patrickdlogan@...> writes:

> Dave Thomas writes:
>  >
>  > Same with something like logging or tracing. Often, this is a
>  > facility that's useful to the development team, not the business
>  > users. So I'd normally add it without consultation.
>
> Tracing is something I do to solve complex, primarily hundreds++
> multi-user, problems. Maybe it could be said that if I wrote unit
> tests well enough, then I would not need to trace complex multi-user
> scenarios. I hope some day that is true! I can tell you though I am
> (1) either not smart enough to hold so many ideas in my head; or (2)
> not diligent enough to find out that I am smart enough; or (3) too
> embarrassed to ask my friends to help me find out.
>
> So I would expect to add tracing to a system as soon as one of these
> kinds of problems reared its ugly head.

Sometimes, though, tracing is what you do to find out _why_ a unit
test failed. Adding tracing retroactively when a particular test fails
way down the development pike may be far more expensive that asking
for it as you go along.

Of course, the ideal solution here is AOP, or features such as those
in Ruby that let you add tracing orthogonally to the source.

Regards

Dave


--
Thomas Consulting.
Innovative and successful developments with Unix, Java, C, and C++.

Now in bookstores:
  The Pragmatic Programmer.  www.pragmaticprogrammer.com/ppbook/

The following message is a courtesy copy of an article
that has been posted to comp.object,comp.software-eng as well.

Patrick Logan <patrick@...> writes:

> In comp.object Dave Thomas <Dave@...> wrote:
>
> : Does XP recommend that developers read ad study stuff they're not
> : currently working on, or do they wait until they have a particular
> : need, and then find the most focused book available?
>
> I don't see where XP says anything about skill development outside of
> the specific project. XP is a project management technique. Do any
> other approaches to developing software mention these concerns? Is
> there some reason they should? Or does that concern get addressed
> elsewhere?

Sorry, I was being obtuse. I keep coming back to the concept that
JustInTime design and coding seems to encourage developers to work
only up the end-of-the-day horizon. SeeingFurther has always been
important to me, and I'm struggling mightily with the idea of giving
it up. So, I was using the patently ridiculous idea of not bothering
to read or study until you have a concrete requirement to further
illustrate problems I feel with a jit approach.

However, I'm really not speaking from a position of authority--I've
not yet experienced a strict XP regime. Who knows, I may be happy to
fling my foresight to the four winds?

Dave


--
Thomas Consulting.
Innovative and successful developments with Unix, Java, C, and C++.

Now in bookstores:
  The Pragmatic Programmer.  www.pragmaticprogrammer.com/ppbook/

Robert C. Martin writes:
  >
  > It astounds me how often I get asked this question.  People have
  > this very odd view of XP.  They think that it eliminates all good
  > design and prevents any kind of intelligent thought about software
  > structure.
  >
  > Of course I have not given up any of the things you mention.  Look
  > at the way I wrote my book.  How many times did I create designs
  > and write code, only to back away and say "ick!", and then refactor
  > the designs and the code into something better?  That was the
  > fudamental pattern throughout the book!  it is also one of the
  > fundamental patterns of XP.

I think this is a fundamental issue with XP worth broadcasting far and
wide. People, including myself, would benefit from seeing how an XP
product evolves test-by-test.

--
Patrick Logan    patrickdlogan@...

Dave Thomas writes:
  >
  > Same with something like logging or tracing. Often, this is a
  > facility that's useful to the development team, not the business
  > users. So I'd normally add it without consultation.

Tracing is something I do to solve complex, primarily hundreds++
multi-user, problems. Maybe it could be said that if I wrote unit
tests well enough, then I would not need to trace complex multi-user
scenarios. I hope some day that is true! I can tell you though I am
(1) either not smart enough to hold so many ideas in my head; or (2)
not diligent enough to find out that I am smart enough; or (3) too
embarrassed to ask my friends to help me find out.

So I would expect to add tracing to a system as soon as one of these
kinds of problems reared its ugly head.

That said, I have not read much about how to apply XP to complex
multi-user systems. Are functional tests where multi-user testing is
to take place? Is there ever anything a functional test should include
that a unit test does not?

--
Patrick Logan    patrickdlogan@...

"Robert C. Martin" <rmartin@...> writes:

> Dave Thomas <Dave@...> wrote in message
> > So I'm only allowed to add a nightly job to back up the repository
> >only after we've had a disk crash and lost all the source?
>
> If your customer has not made nightly backups a priority, then they
> must be willing to lose all the source.


Well, most of my customers frankly aren't interested in source code,
version control, logging and the like. They're things that are below
the horizon for them, but vital for the process that delivers what
they *do* want. Customers don't want to micro-manage the
developers--nor do developers want to be micro-managed. So I don't
think I'd even mention the fact I was taking backups to my
clients--I'm sure they either assume I am, or they haven't thought of
the possibility of losing the source. Either way, taking them is part
of the service I provide--providing a low-risk path to delivering
against their objective.

Same with something like logging or tracing. Often, this is a facility
that's useful to the development team, not the business users. So I'd
normally add it without consultation.

I suspect this is not a discussion we'll get resolved until I find an
opportunity to be integrated into a successful XP team that'll show me
the errors of my ways ;-)

Regards


Dave


--
Thomas Consulting.
Innovative and successful developments with Unix, Java, C, and C++.

Now in bookstores:
  The Pragmatic Programmer.  www.pragmaticprogrammer.com/ppbook/

<toddhoff@...> wrote in message
news:84qr22$jnh$1@....
> In article <ho3c4.2822$h3.77804@...>,
>   "Robert C. Martin" <rmartin@...> wrote:
> > I can't imagine a scenario in which XP adds risk.  I consider the
> risk of
> > building the wrong infrastructure up-front to be greater than the
> risk of
> > waiting until the need for the infrastructure is demonstrable.
>
> Given this would it be safe to assume you nolonger use
> templates, abstract base classes, visitors, factories,
> worry about dependency inversions, etc? Having read your posts for
> several years i'd find this hard to believe, but at the same time
> these practices would seem to have very little place in XP as they
> are all future considerations of problems yet to appear.
>

It astounds me how often I get asked this question.  People have this
very
odd view of XP.  They think that it eliminates all good design and
prevents
any kind of intelligent thought about software structure.

Of course I have not given up any of the things you mention.  Look at
the
way I wrote my book.  How many times did I create designs and write
code,
only to back away and say "ick!", and then refactor the designs and the
code
into something better?  That was the fudamental pattern throughout the
book!
it is also one of the fundamental patterns of XP.

XPers don't code blindly.  They *design*.  But they use code as a design
tool; just as I did in my book.  XPers *do* add infrastructure, but only
when the existing code could benefit from it.  Again, you see this
frequently in my book.

I find it odd that I must justify my affinity to XP.  The most
consistent
compliment I get regarding my papers and my books is that I show my
train of
thought through the design process, and show the errors I make and how I
correct them.  Yet when XP formalizes this very approach, it is
interpreted
as a repudiation of design.

Make no mistake, XP is *heavily* design oriented.  But it does not allow
you
to build castles in the air.  If you want to use a visitor, you'd better
be
able to show how the code will improve.  If you want to invert
dependencies,
you'd better be able to show that it solves some existing problem, or
makes
the structure of the code more flexible.

XP does not represent a change in my thinking.  Though it wasn't
described
as well as Kent had described it, you will see many of the basic
concepts of
XP in my books and writings over the last half decade.


--

Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

Dave Thomas <Dave@...> wrote in message
news:m24scvaz2c.fsf@....
> "Robert C. Martin" <rmartin@...> writes:
>
> > > So, my problem is that XP as espoused doesn't allow me to use my
> > > experience to reduce risk.
> >
> > Yes it does.  It just asks you to wait until the risk is actually
manifest.
> > As you work in an XP project, you will find all kinds of
opportunities
for
> > adding infrastructure.  But you wait, rather than immediately adding
it.
> > You wait until its clear that the infrastructure is really needed.
>
> So I'm only allowed to add a nightly job to back up the repository
> only after we've had a disk crash and lost all the source?

If your customer has not made nightly backups a priority, then they must
be
willing to lose all the source.  Clearly you want to make sure the
customer
knows what they are risking.  But if they prioritize other features
above
the nightly backup, you have no business building the nightly backup
first.
It's their nickel, after all.

> That's not as facetious a question as it sounds at first.

Nor did I interpret it facetiously.  Indeed, it is right to the point.
There are things that make a tremendous amount of engineering sense that
may
make no business sense.  We, as engineers, have a tough time
understanding
this.  Still, we exist to serve the business.  When the business
countermands our engineering instincts, the business wins.

This doesn't mean we sacrifice on quality.  Those features that business
tells us to create, we create with the best of our skills.  But we do
not
add features that business has not made a priority.

> My experience tells me it's good to take backups. I set them up on all
> new projects. I don't wait until I bump into the real-world need
> before doing it.

And since you, as the software engineer, are the customer of the
development
environment, you have that right.  But you don't have that right with
customer features.  If the customer does not want you to back up the
employee database every night, even after you have warned him of the
risk,
then you don't back it up.

> Why is this different to saying 'my experience tells me we'll need an
> logging and tracing facility for everyone to use. Let's code one up
> front"?

If that statement is true, then at least two people in the first
iteration
will need it.  That need will be identified early on, either before any
code
is written, or before too much code is written.

It works like this.  Bill and Bob pair up to work on feature X.  They
realize that they will have to emit messages and write them to a private
log
file.  A few hours later, Bill pairs with Jim.  Bill sees that Jim has
also
been writing to a log file.  Bill, Jim, and Bob realize that there is
duplication in their efforts.  They quickly poll the team to see if
others
have faced this need.  If so, the team quickly convenes to design a
logging
facility.  Everybody changes their code (only a few hours worth have
been
written) and they go on from there.

This scenario repeats often because pairs change frequently.  By the end
of
the first few days of an XP project, everybody has seen all the code and
is
familiar with the basic design of the system.  They have also found
commonalities and refactored them into abstractions and infrastructure.

Is there rework?  Certainly.  But it is minimal.  And the benefit is
that
the abstractions, once created, are based upon something very real.
Many is
the time I've had to rework large chunks of code because others had
written
to my bad abstractions that were based upon what I *thought* would be
needed.


--

Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

----- Original Message -----
From: Jonas Karlsson <karlsson@...>
To: <extremeprogramming@egroups.com>
Sent: Monday, January 03, 2000 4:56 PM
Subject: [extremeprogramming] When does refactoring become framework
building
> Fowler states that refactoring should be done where "code smells" can
> be found.  At first I thought he said that refactoring is done when
> needed to make implementation of a new task easier.  Then he seemed to
> add that refactoring should be done all the time, whenever bad smells
> were encountered.  I love designing general purpose, reusable
> frameworks, but my co-developers have forced me to compromise on many
> occasions, saying that it adds complexity that is not needed at this
> point in time.    Can I now go and sneak in my general purpose
> framework under the guise of refactoring ("Oh, I'll just split an
> interface here, create an abstraction layer there, push some methods
> down, and others up.. Then in February, I'll start on my assigned
> tasks!")?

To me, the most important way of avoiding this is to make
sure that all of your code is being used.  If you are not using
a particular hook function, for instance, it is not necessary.
If you have an abstract class with only one subclass and
it isn't there to break a dependency, ditto.

There are a couple of things that will keep you away
from framework building.  First of all, if you write your
test cases first, you'll probably find creating things you
don't immediately need tedious.  Secondly, if you
are making estimates and sticking to them as part of
a team, and the rest of them are churning out correct
tested code like mad, I doubt they'll give you until
February to join in. :-)

There is a really bright side, however.  If you get a
kick out of building generality into code, you'll
probably be amazed at how your code evolves
into both specific and general things over time,
without a lot of up front planning.

> I get the impression that despite "You aren't going to need it",  in
> order to refactor effectively, some judgements about what is likely to
> change in the future must be made.

Following Kent's lead, I've tried some experiments, delaying
those judgements and it has worked out well.  Just paying
attention to the clarity of your code and duplication works.
When your code can't be made any more understandable
and you do not have duplication, you are at a stable point.
The potential for movement in any direction is maximized.

Michael

---------------------------------------------------
Michael Feathers  mfeathers@...
Object Mentor Inc.  www.objectmentor.com
Training/Mentoring/Development
-----------------------------------------------------
"You think you know when you can learn, are more sure when
you can write, even more when you can teach, but certain when
you can program. " - Alan Perlis

At 04:56 PM 1/3/2000 -0500, Jonas Karlsson wrote:
>I think a case where significant risk is added is when the people trying to
>switch over to XP don't know what they're doing.  To reduce this risk,
>I'll try and get some help from this list.

Also consider getting a coach to come and help out. A little goes a long
way ...

>I've just read Fowler's refactoring book, so I'll start there.
>
>Fowler states that refactoring should be done where "code smells" can
>be found.

Yes, refactoring is incremental and should be done all the time. When going
gets tough, no one will have time or inclination to clean things up. So
keep your room clean all the time, just like Mom said.

>I love designing general purpose, reusable frameworks, but my
>co-developers have forced me to compromise on many occasions, saying that
>it adds complexity that is not needed at this
>point in time.    Can I now go and sneak in my general purpose framework
>under the guise of refactoring

Not only no, but hell no. Extreme programmers remove code that isn't used.
They don't put it in. See the rules for code in Beck's book, p 109. Run the
tests; Communicate everything needed; No duplicate code; minimal number of
classes and methods. Doesn't say anything about excess abstraction. Sorry.

>I get the impression that despite "You aren't going to need it",  in
>order to refactor effectively, some judgements about what is likely to
>change in the future must be made.

No, none. Make the code perfect for today. Then stop.

Regards,

Ron Jeffries
Extreme Programming Training and Consultation
ronjeffries@...
web pages: http://www.XProgramming.com, http://www.armaties.com
pgp key: http://www.armaties.com/pgpkey.htm

<brougham2@...> wrote in message
news:3871a37a.321644360@....

> If you've already solved a problem before so that you already know
what
you
> need to do, I don't see any benefit to XP's incremental development.
Might
> as well develop the infrastructure you *know* you will need via a
waterfall
> model, and then switch over to XP after that.

I look at it differently than that.  If I already knew the domain cold,
I
would still use XP simply because XP will give me the simplest design
that
could possibly work.  I might be *sure* about all the infrastructure
I'll
need, but XP will only let me add it if its truly needed.  And there can
be
a big difference between what I'm sure will be needed, and what really
is
needed.

> I think what XP is saying is that if you aren't experienced enough in
the
> problem domain to know everything before hand, you will probably be
better
> off by deferring as many decisions as possible.

I'd amend that to simply: "You are always better off deferring as many
decisions as possible."

> Incremental development isn't necessarily the best solution for *all*
> problems.

True.  If the cost of change is very high, then we don't want to
iterate.
But if we can keep the cost of change low, through unit tests,
refactoring,
pair programming, and simplicity, then iteration is probably the best
approach.


--

Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

Hi,
	 We're trying to introduce XP practices on a fairly small
project (3-5 developers).  I think Bob Martin wrote that he couldn't
think of a case where using XP on a project would add risk -- I think
a case where significant risk is added is when the people trying to
switch over to XP don't know what they're doing.  To reduce this risk,
I'll try and get some help from this list.

I've just read Fowler's refactoring book, so I'll start there.

Fowler states that refactoring should be done where "code smells" can
be found.  At first I thought he said that refactoring is done when
needed to make implementation of a new task easier.  Then he seemed to
add that refactoring should be done all the time, whenever bad smells
were encountered.  I love designing general purpose, reusable
frameworks, but my co-developers have forced me to compromise on many
occasions, saying that it adds complexity that is not needed at this
point in time.    Can I now go and sneak in my general purpose
framework under the guise of refactoring ("Oh, I'll just split an
interface here, create an abstraction layer there, push some methods
down, and others up.. Then in February, I'll start on my assigned
tasks!")?

I get the impression that despite "You aren't going to need it",  in
order to refactor effectively, some judgements about what is likely to
change in the future must be made.

_jonas

Ell <universe@...> wrote in message
news:3874fb00.5166829@....
> Panu Viljamaa <panu@...> wrote:
>
> #I'd like to compare this to playing chess: You can simply 'solve one
problem' at a
> #time OR you can have a strategy for winning the game, perhaps
sacrificing
some pawns
> #along the way.  The latter is possible only if you are a master
chess-player.
>
> No way.  It is the chess rookies who are going piece meal, who react
bit
by
> bit to every new event.  It is the masters who build frameworks for
victory.
> Who use forethought and anticipation to their advantage.  That is a
major
> reason why the XP bit by bit, piece meal strategy is such a criminal
fraud.

When you play chess against someone who is very good, you can't simply
depend upon a well thought through strategy.  Your opponent will think
it
through with you and know how to defend against it.  Rather you must put
pressure on your opponent by creating several credible threats while
remaining as nimble as possible to take advantage of any small error or
oversight he might make.  Advantage is slowly accumulated by whittling
away
at the opponent.

The point is that neither player can predict how the game will go from
the
outset.  The game will evolve; just as any project evolves.  The trick
is to
stay nimble enough to view project evolution as an advantage rather than
a
liability.


--

Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

Hans Wegener <hans.wegener@...> wrote in message
news:38707FEB.EF168122@....
> "Robert C. Martin" wrote:
>
> > XP resolves the dilemma by saying: Pay only for what you know you
need
now,
> > pay for generality now, when you need the generality now.
>
> I don't see how XP really resolves anything if you mean the dilemma:
"Will
this
> feature pay off or not?" People are notoriously bad at predicting
that.
The
> principle merely puts tention in the decision to go meta, as you said
it,
and
> that's a very good thing to do. Yet, as I read your words you mean to
say
that
> you are only willing to pay for what you need right now. IMHO that's
another
> word for shortsightedness. This is not to say XPers are shortsighted
persons -
> not at all. But the principle doesn't aid you in becoming more
farsighted,
and
> from time to time this is really what you need.

XP defines shortsighted to mean:  "you got caught a third time."  In
other
words, if it happens once, you pay for it.  If it happens twice you
figure
it'll happen again, and you generalize it.  If you find yourself paying
a
third time, you screwed up.

> The problem becomes less fuzzy when you take a look at project size
and
domain
> complexity: lack of domain knowledge and sheer complexity are major
reasons for
> running over budget etc. We all have heard, read or even witnessed
these
> stories. Starting small and releasing early and often is one of the
best
> countermeasures. In such situations a wrong decision (on average) has
also
a
> comparatively small effect. Go YAGNI. But if I knew the beast well and
had
> things under control I would be foolish not to start and think big.
Here
YAGNI
> would (again on average) be more expensive.

I'm not convinced of that.  The overall cost of building the project
*might*
be higher; however there is another factor.  If you work only on those
things that are most important to the customer, the customer starts to
get
benefit early.  That benefit starts to pay for the cost of the project
before the project is complete.  Thus the net cost may be lower.

XP says: "Generate value for the customer every day.  Generate the
greatest
value early.  Don't invest in infrastructure until you are damned sure
that
it will help you generate more value for the customer *sooner* rather
than
later."
>
> Wrapping up, you have to relate things to the problem at hand. In some
> situations XP really makes perfect sense. But there are many others
where
XP
> adds to the risk instead of reducing it. The art is to tell where the
borderline
> is, and that is still a matter of experience, not of process.

I can't imagine a scenario in which XP adds risk.  I consider the risk
of
building the wrong infrastructure up-front to be greater than the risk
of
waiting until the need for the infrastructure is demonstrable.

--

Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

Dave Thomas <Dave@...> wrote in message
news:m266xbzofr.fsf@....
> "Robert C. Martin" <rmartin@...> writes:
>
> > XP is not anti-meta.  XP simply puts tention in the decision to go
meta.
> > You go meta only if you know you must.
> >
> > Dave:
> > > So I feel that YAGNI is too simplistic--there are times where a
bit of
> > > up-front investment will be rewarded many times over.
> >
> > The problem is predicting those times in advance.  I have been the
> > beneficiary of such up front investment -- and if feels good to know
you
> > guessed right.  But I've also been burned by investing too much in
> > generality that wasn't needed.
>
> But it's more than 'feeling good' and 'getting burned', isn't it? In
> the XP risk model, the 'feeling good' actually represents cost
> savings. In my experience, the right underlying structure can make
> these substantial--the cost of adding new functions is halved or
> better. The 'burn' is increased cost--you bet up-front and lost.

Yes, the right underlying structure can make the savings substantial.
As
you say, the cost of adding functions can be halved.  In XP, however, we
won't create this structure until the we have two functions that would
have
benefitted.  When we see the second function, we refactor the existing
design until the second function is easy to add.  All subsequent
functions
then benefit from this.

Thus, we aren't abandoning the right underlying structure, we are just
demanding that the code show us that it's absolutely needed.  We also
wait
until the code shows us exactly what that structure should be.

> My belief is that for an experienced developer, we're looking at the
> venture capital success formula here: arithmetic losses, geometric
> gains. You invest n days up front, on the basis that you're pretty
> certain to see returns of 10n down the road.

But at what failure rate?  The majority of startups don't experience the
geometric growth.  Their up front guesses were wrong.  They struggle
over
years to make a small incremental gain on the initial investment, and
then
fold or are absorbed.  Investors still find the model useful because the
occasional geometric success swamps the preponderance of failures.

Can we afford this model in building software projects?  Does the
occasional
geometric success really provide enough benefit to overcome the times we
guess wrong?  It seems to me that project failure due to overengineering
is
not all that uncommon.

How do many startup companies really succeed?  They stay nimble.  They
change when the market changes.  They try not to invest too much into an
approach until the market begins to pull that solution from them.  Then
they
invest like crazy.  i.e. they are market driven.

How can a software project succeed using this formula.  By not investing
in
unproven infrsstructure.  By doing the things that the customer thinks
are
most important, and then optimizing the design within that context.
When
duplication arises because of a lack of infrastructure, add the
infrastructure and kill the duplication.
>
> Elsewhere, people have argued that you add this infrastructure when
> you see the need--effectively when the second example of it's use
> occurs. My experience is that often that would be an expensive
> proposition--the kind of design I'm talking about here is structural,
> not just procedural. We're talking about refactoring the metaphor, not
> just the code.

Yes, there is certainly rework involved.  But since the rework is done
on
the *second* instance, it just not that much rework.  Yes, there will be
times when some good idea is missed, and a larger refactoring is
necessary.
We live with that.  We count it better to have the code force us into a
better infrastructure than to force that infrastructure on a project
that
doesn't need it.

> So, my problem is that XP as espoused doesn't allow me to use my
> experience to reduce risk.

Yes it does.  It just asks you to wait until the risk is actually
manifest.
As you work in an XP project, you will find all kinds of opportunities
for
adding infrastructure.  But you wait, rather than immediately adding it.
You wait until its clear that the infrastructure is really needed.

This isn't asking a lot.  It is reasonble to ask that you avoid extra
infrastructure that you aren't sure you need.

> It says 'add it when you need it', 'the
> first use only pays what it must'. I'd just like to see a tad more
> flexibility there, allowing me to say "well, I can't guarantee it, but
> I strongly suspect we'll need XYZ, and if I'm right, it'll pay for
> itself 10 times over. Implementing it now will n days, but adding it
> retroactively will affect everything written to that date, and will
> cost at least 3n days. If I'm right 50% of the time, it pays more to
> do it now".

That's a lot of 'ifs'.  How certain are you that they are correct?  How
confident are you in the 10X benefit, or the 3X cost, or the 50%
accuracy?
In effect you are gambling with a lot of variables; and this increases
your
variance.  Now, what does your customer want?  Does the customer want
variability, or predictability?  Consider these two options (forgive the
inappropriate use of a normal distribution):

1.  Mean = 2 man years.    Sigma= 2 man years.
2.  Mean = 3 man years.    Sigma= 1 man years.

Which will the customer be more interested in?  In my experience, the
customer will go for option 2.  He'll be willing to pay a higher average
cost for more predictability.

> I think this is probably a somewhat academic argument. My guess is
> that in real life, common sense over wins out over the strict letter
> of the method. After all, I suspect XP coders use a manifest constant
> the first time they need a fixed value, not the second. I just get
> nervous when I read the somewhat extreme and absolute tone of some
> of the writings.

I think you should stay nervous.  Using XP, a program is built from one
failing test case to the next.  And the granularity of those test cases
is
remarkably small -- on the order of a few dozen lines of code.  Don't
presume that XPers actually still add all the infrastructure up front
that
"common sense" would dictate -- they don't.  Instead, they make each
failing
test case pass, one at a time.  After each test case passes (or before
they
write the next test case) they refactor to remove duplication and
simplify
the design.  The absolute tone of the writings reflects the behavior of
the
XPers.  Infrastructure is added after the fact by refactoring something
that
already exists.

--

Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

If you already knew about rules, what is the probability that you wouldn't
create dialing rules the second time you wrote dialing-oriented logic?

XP is pro-meta, it just happens the second time you encounter the logic, not
before the first.

Kent

Dave Thomas <Dave@...> wrote in message
news:m2iu1cyluc.fsf@....
> schuerig@... (Michael Schuerig) writes:
>
> > I, too, feel a bit uncomfortable with Dave's use of the
"meta"-prefix. I
> > don't think it's wrong, but it is different from what people who
have
> > read stuff such as "The Art of the Metaobject Protocol" expect. I
for
> > one expect something that's not specific to any particular domain.
In
> > contrast, my understanding of the approach that Dave (together with
Andy
> > Hunt in "The Pragmatic Programmer") advocates is such that I'd
rather
> > call it "Separate Mechanism From Policy". Only mechanism, that which
is
> > needed by any application in the domain, is hard-coded; the specific
> > application is a malleable layer on top of that.
>
> That's a great characterization. Build nuggets of domain-specific
> code, and knit them together to build the application you need at the
> time. The only qualification I'd make is that often the lower level
> ends up being domain independent. We've been dragging the same trace
> routines around with us now for 5 years.
>
> I guess on reflection it _is_ a kind of YAGNI--we're saying defer the
> anything application specific as long as possible, and then make it
> easy to change. So in spirit we're XPers, we just bend the rules...

Building software in this way is often a good solution.  But not always.
Sometimes, perhaps even often, the best cost/benefit trade off is the
more
direct solution.  Unfortunately, the problem is not simply a binary
decision.  One cannot simply decide to go meta or not.  Rather,
individual
portions of projects may benefit from a meta approach, while others may
not.

For example, Twenty years ago I worked on one of the very first voice
mail
systems.  We had to be able to dial phone numbers to deliver voice mail
messages.  Dialling numbers is very tricky.  The number you dial depends
upon a whole set of complex criteria including:  Your area code, the
target
area code, whether you are behind a PBX, whether the target is an
extension
of that PBX, whether the target is on a different part of that PBX,
whether
there are special prefixes for certain exchanges, etc, etc, etc.  There
was
no way we could hard code all these rules.  To make matters worse, the
rules
were different for every installation.  So we created a nice little
meta-language that let us write scripts for dialling numbers.

Most complex systems are hybrids of meta and non-meta designs.  We go
meta
when we need the flexibility and can afford the cost of the meta-design.
We
avoid meta when the rules don't change often.

XP is not anti-meta.  It just puts a lot of tension in the decision.


--

Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

<brougham2@...> wrote in message
news:g9tvOEuL+JwgdytR6VTasnqHZLeH@....
> "Phlip" <new_email@...> wrote:
>
> >BTW IS ANYONE GONNA ANSWER THE ACTUAL QUESTION??? ("Should software
> >dev run in 3 shifts if you actually need a little speed, and if so
> >will XP grease the system or hurt it?")
>
> I had assumed the question was facetious.  I see no advantage in using
three
> shifts.  Just triple the number of people working during the day.
> Obviously, if one woman takes nine months to bear a child, three women
can
> get the job done in three months.

The advantage is that you need one third the resources, i.e. space,
desks,
computers, licenses, etc.

> If you're constantly having to document unfinished work at the end of
each
> shift, and then having to review what went on without your knowledge
at
the
> beginning, I can easily see a highly efficient programmer losing 25%
of
his
> time just on the extra overhead of difficult communications.  So
having
> three shifts might double your production.  And that's assuming
everybody
is
> communicating effectively.

If you are pair programming, and if your shifts overlap by 50%, then the
communications overhead should be minimal.  At shift change only one
member
of each pair changes.  Thus, continuity can be preserved.

Of course I've never tried this, or seen it tried, so its speculation on
my
part.


--

Robert C. Martin    | OO Mentoring             | Training Courses:
Object Mentor Inc.  | rmartin@... | OOD, Patterns, C++,
Java,
PO Box 85           | Tel: (800) 338-6716      | Extreme Programming.
Grayslake IL 60030  | Fax: (847) 548-6853      |
http://www.objectmentor.com

"One of the great commandments of science is:
     'Mistrust arguments from authority.'" -- Carl Sagan

Hi,

I have created an email discussion group for XP and put you guys in it.  I hope
you don't mind.

Discussion of Extreme Programming practices and principles (English)

Cheers,

Robert C. Martin