Extreme programming and interfaces.

[Uncle Bob (Robert C. Martin)]

"4Space" <4Space@NoSpam.com> might (or might not) have written this on
(or about) Tue, 10 Jun 2003 14:36:29 GMT, :
I'm hoping to get some opinions on this subject.One of the points of Extreme programming is that you should refactormercilessly. How does this apply with interfaces? I've read some XPresources that state you should not be afraid to change an interface (changeis the only constant in software etc), and some (admittedly not XPresources) that assert that interfaces, once published, should be immutable.For class libraries, I don't think it's feasible to alter design whilstguarunteeing that the interface will not change.

Published interfaces are hard to change. Therefore interfaces must be
pretty stable before you publish them. There are two schools of
thought on how to get the interfaces stable.

1. Lots of up front design and thought experiments.
2. Develop the interface in conjunction with a small but
representative population of programs that use it. Publish it once it
stabilizes for those users.

The second is the XP way.


Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[4Space]

> 1. Lots of up front design and thought experiments. 2. Develop the interface in conjunction with a small but representative population of programs that use it. Publish it once it stabilizes for those users. The second is the XP way.

Yeah, I think that number 2 is the way to go. The problem I came up against,
particularly from some developers was that they believed as soon as they
linked to an interface, it should be immutable. I guess we need to be able
to do more prototyping with the various internal customers to get an
interface hammered out, then publish it for testing, then when it appears
stable, decalre it immutable.

btw, I insisted that our team swear an oath by placing their right hands on
your 'Agile Software Development' book (well strictly speaking, it's my
book, but you get my meaning.) and declaring an allegiance to the agile
process. If this doesn't increase our productivity by 3000%, I may lose
their commitment.

Cheers,

4Space

[Daniel Parker]

"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o.b@objectmentor.com> wrote in
message news:vm8ffvcilieegka7aepcoremesqiu795b9@4ax.com... Published interfaces are hard to change. Therefore interfaces must be pretty stable before you publish them. There are two schools of thought on how to get the interfaces stable. 1. Lots of up front design and thought experiments. 2. Develop the interface in conjunction with a small but representative population of programs that use it. Publish it once it stabilizes for those users. The second is the XP way.
You don't need the representative population of programs, you need the use
cases, what the programs will require of the interface, and experience
surely suggests that it is possible to define that without actually building
the programs. Many interfaces suffer from being too much slanted to the
producer of the interface rather than the more numerous and later arriving
consumers, and it is hard to see how a code centric approach would improve
upon that. The "small but representative population of programs that use
it" is not likely to be all that representative in the early days; it is
hard to see how that could be the case unless you've done a considerable
amount of "up front design," or rather up front coding which to XP'ers often
seems to be the same thing.

Regards,
Daniel Parker

[4Space]

> You don't need the representative population of programs, you need the use cases, what the programs will require of the interface, and experience surely suggests that it is possible to define that without actually
building the programs. Many interfaces suffer from being too much slanted to the producer of the interface rather than the more numerous and later arriving consumers, and it is hard to see how a code centric approach would improve upon that. The "small but representative population of programs that use it" is not likely to be all that representative in the early days; it is hard to see how that could be the case unless you've done a considerable amount of "up front design," or rather up front coding which to XP'ers
often seems to be the same thing.

I think I'd contend that there would likely be a gap between the Use Cases
and the code, a gap that would be best bridged by prototyping and developing
in conjuntion with the representative client cross-section.

Cheers,

4Space.

[Christopher Barber]

"Daniel Parker" <danielaparker@windupbird.com> writes:
"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o.b@objectmentor.com> wrote in message news:vm8ffvcilieegka7aepcoremesqiu795b9@4ax.com... Published interfaces are hard to change. Therefore interfaces must be pretty stable before you publish them. There are two schools of thought on how to get the interfaces stable. 1. Lots of up front design and thought experiments. 2. Develop the interface in conjunction with a small but representative population of programs that use it. Publish it once it stabilizes for those users.
You don't need the representative population of programs, you need the use cases, what the programs will require of the interface, and experience surely suggests that it is possible to define that without actually building the programs.

No, experience suggests quite the opposite! It is extremely difficult to
correctly identify all of the relevant use cases without actually trying to
build something. On the other hand, prototyping will also not identify all of
the issues either. In practice, you really need to combine the two approaches
to design good interfaces.

- Christopher

[Uncle Bob (Robert C. Martin)]

"4Space" <4Space@NoSpam.com> might (or might not) have written this on
(or about) Tue, 24 Jun 2003 10:31:11 GMT, :
1. Lots of up front design and thought experiments. 2. Develop the interface in conjunction with a small but representative population of programs that use it. Publish it once it stabilizes for those users. The second is the XP way.Yeah, I think that number 2 is the way to go. The problem I came up against,particularly from some developers was that they believed as soon as theylinked to an interface, it should be immutable. I guess we need to be ableto do more prototyping with the various internal customers to get aninterface hammered out, then publish it for testing, then when it appearsstable, decalre it immutable.

I would not use the word "immutable". Rather I would say that the
interface has an I metric approaching zero. It is heavily depended
upon, and is therefore very difficult to change. But it *can* be
changed if the need is great enough.btw, I insisted that our team swear an oath by placing their right hands onyour 'Agile Software Development' book (well strictly speaking, it's mybook, but you get my meaning.) and declaring an allegiance to the agileprocess. If this doesn't increase our productivity by 3000%, I may losetheir commitment.

I am honored! Perhaps you'll also find "UML for Java Programmers"
(www.objectmentor.com/UMLFJP) as useful.


Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Uncle Bob (Robert C. Martin)]

"Daniel Parker" <danielaparker@windupbird.com> might (or might not)
have written this on (or about) Tue, 24 Jun 2003 07:11:43 -0400, :
"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o.b@objectmentor.com> wrote inmessage news:vm8ffvcilieegka7aepcoremesqiu795b9@4ax.com... Published interfaces are hard to change. Therefore interfaces must be pretty stable before you publish them. There are two schools of thought on how to get the interfaces stable. 1. Lots of up front design and thought experiments. 2. Develop the interface in conjunction with a small but representative population of programs that use it. Publish it once it stabilizes for those users. The second is the XP way.You don't need the representative population of programs, you need the usecases, what the programs will require of the interface,

How do you know that the use cases are correct?
and experiencesurely suggests that it is possible to define that without actually buildingthe programs.

I think experience shows something more towards the center. In my
experience most interfaces that are designed before being built
require significant alteration once the rubber actually meets the
road.
Many interfaces suffer from being too much slanted to theproducer of the interface rather than the more numerous and later arrivingconsumers, and it is hard to see how a code centric approach would improveupon that.

Interfaces *are* code. An approach centered upon getting that code
correct by measuring that correctness and evolving it to be *more*
correct seems a reasonable approach. I've certainly seen it work.
The "small but representative population of programs that useit" is not likely to be all that representative in the early days; it ishard to see how that could be the case unless you've done a considerableamount of "up front design," or rather up front coding which to XP'ers oftenseems to be the same thing.

If you don't believe that you can apply enough up front thought to
select a representative batch of users, why do you think you can apply
enough up front thought to define the whole interface? I'm not trying
to say that you should *not* apply thought to the interface. I'm
trying to say that you should not depend upon thought alone. That you
won't truly know that the interface works until many people use it.



Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Daniel Parker]

"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o.b@objectmentor.com> wrote in
message news:5r8hfvsnidotr3s3r8hv6f6m28af2v0d10@4ax.com... Christopher Barber <cbarber@curl.com> might (or might not) have written this on (or about) 24 Jun 2003 11:06:01 -0400, :In practice, you really need to combine the two approachesto design good interfaces. That is a statement that I think everybody on this newsgroup (even Elliott) would agree with. All we are ever really arguing about is emphasis.
Oh, hell, you're trying to be reasonable. I hate it when people try to be
reasonable. I'd prefer that they take an extreme position, perhaps with the
disclaimer that the views expressed are not necessarily held by the authors.

Regards,
Daniel Parker

[Daniel Parker]

"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o.b@objectmentor.com> wrote in
message news:458hfv81i2503g88ftm57t6minq1ffim9s@4ax.com... "Daniel Parker" <danielaparker@windupbird.com> might (or might not) have written this on (or about) Tue, 24 Jun 2003 07:11:43 -0400, :"Uncle Bob (Robert C. Martin)" <u.n.c.l.e.b.o.b@objectmentor.com> wrote
inmessage news:vm8ffvcilieegka7aepcoremesqiu795b9@4ax.com... Published interfaces are hard to change. Therefore interfaces must be pretty stable before you publish them. There are two schools of thought on how to get the interfaces stable. 1. Lots of up front design and thought experiments. 2. Develop the interface in conjunction with a small but representative population of programs that use it. Publish it once it stabilizes for those users. The second is the XP way.The "small but representative population of programs that useit" is not likely to be all that representative in the early days; it ishard to see how that could be the case unless you've done a considerableamount of "up front design," or rather up front coding which to XP'ers
oftenseems to be the same thing. If you don't believe that you can apply enough up front thought to select a representative batch of users, why do you think you can apply enough up front thought to define the whole interface? I'm not trying to say that you should *not* apply thought to the interface. I'm trying to say that you should not depend upon thought alone. That you won't truly know that the interface works until many people use it.
You don't need to define the whole interface. Some things about an
interface are easy to change. But other things are hard, once other
components are using it. It's helpful to get the basic abstractions right
early. If something is expensive to change later, it pays to put more
thought into it now. For that matter, the extendibilty of anything often
depends on how much thought you put into it at the beginning. Extendibility
needs to be designed for. I seem to recall that you've written some things
on that subject.

Keep in mind that you have to go pretty deep into Beck's TDD before you will
find code that even remotely approximates what someone with a little domain
knowledge and some understanding of software principles would write, given a
little time to reflect. There is absolutely no point in having core
interfaces between components go through those kind of iterations.

But hey, there have been threads where XP'ers were loath to make any
concessions about the expense of refactoring interfaces. In one of them,
after many exchanges, the estimable Mr Jefferies finally allowed that OK, if
you were talking about _libraries_, then maybe, just maybe...That reminded
me of a very thick IBM FORTRAN manual I once used that had a very short
section on functions. The function, it said, was something you wouldn't
likely use very often, but if you did happen to have a lot of repeating
code, you could use it.

Regards,
Daniel Parker

[Phlip]

[It seems news:comp.object is fated to have a single, eternal, rolling TDD
thread these years, under various titles... ;-]

Daniel Parker wrote:
Keep in mind that you have to go pretty deep into Beck's TDD before you
will find code that even remotely approximates what someone with a little
domain knowledge and some understanding of software principles would write, given
a little time to reflect. There is absolutely no point in having core interfaces between components go through those kind of iterations.

KB's TDD book covers TDD, not XP, and assumes a customer who wants money
(hence his money example). Not interfaces.

On a team selling interfaces, let's follow XP's core principles and see what
happens.

First, get the best possible domain expert (just like any other methodology
[right?]).

The best possible domain expert will have experience delivering APIs to
user-programmers with fixed interfaces. (We can also work this with a lame
domain expert, too.)

We appoint them to the OnsiteCustomer role, and then they write some User
Stories requesting APIs.

The team's job now is, for each US, is to help the OnsiteCustomer specify
Customer Acceptance Test criteria. "Help" generally means "challenge" here.
Everyone's job is to challenge assumptions.

The CAT for an API feature is a small app using that feature the way a
user-programmer would.

The developers challenge the OC to make each CAT as different as possible.
Customers will Accept our API when they find it solves their problem their
way.

(We may also envision USs that state "the API returns the correct error
message if it is used wrong". We have all experienced APIs that failed this
one!)

This situation is the same as for any UserStory and its CAT; where the whole
team reviews the CAT criteria to make sure nobody can improve it. (Recall
the criteria is just on paper so far.) But this means even if the
OnsiteCustomer is not the >best< domain expert possible, they are not the
bottleneck in the system.

Now the team starts converting UserStories into real CATs, unit tests, and
code.

When the time comes to refactor, they refactor mercilessly. Except the CATs.

The White Book clearly states that the element of a check-in is production
code and "unit" test code. You are not allowed to change the CAT
("functional test") as freely as production code, because when you check-in
all tests must pass, but other programmers might be working against a given
CAT, so it might not pass yet, so you can't use it to determine if your most
recent edit broke anything.

Refactoring stops at the CAT.

The unit test code gates the production code, but the CATs gates the
UserStory. So when the CATs pass, the OnsiteCustomer takes the UserStory
card back.

If the CATs specify fixed interfaces, the team delivers fixed interfaces.

Nobody expects fixed interfaces (or anything else an end-user needs) to
spontaneously emerge from refactoring!

If development encounters any problem with the specifications, they will
perforce already have source code demonstrating the problem. So they can
submit this to the OC, who can change the specifications, upgrade the CAT
criteria, and re-start its UserStory.

If end-users request an upgrade, the OC can request a new function,
CreateFileEx() as usual.

Because there are many CATs, the team satisfies the principle "build an API
by building more than three client applications."
But hey, there have been threads where XP'ers were loath to make any concessions about the expense of refactoring interfaces.

Frankly, our technology has not caught up with us. Databases, ORBs & GUIs
were all invented to permit a few kinds of testing and refactoring while
hindering others. I suspect databases still exist that prevent one from
adding a column freely, without copying table contents around.

In future, such APIs will be written with Agile teams in mind.

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

[Uncle Bob (Robert C. Martin)]

"Daniel Parker" <danielaparker@windupbird.com> might (or might not)
have written this on (or about) Wed, 25 Jun 2003 08:43:08 -0400, :
You don't need to define the whole interface. Some things about aninterface are easy to change. But other things are hard, once othercomponents are using it. It's helpful to get the basic abstractions rightearly. If something is expensive to change later, it pays to put morethought into it now.

All true. However I would add something to that last sentence.
"...it pays to put more thought and experiment into it now."
For that matter, the extendibilty of anything oftendepends on how much thought you put into it at the beginning.

I would amend that to read "...thought and experiment..." too.
Extendibilityneeds to be designed for. I seem to recall that you've written some thingson that subject.

Yes, I've written quite a bit about that. However, I have never
written that pure thought is enough. Aristotle thought that you could
derive the structure of the Universe through pure thought. He
disdained experiment. Aristotle was wrong. Thought is necessary, but
so is experiment. Extendibility needs to be designed for -- but
design involves thought *and* experiment.
Keep in mind that you have to go pretty deep into Beck's TDD before you willfind code that even remotely approximates what someone with a little domainknowledge and some understanding of software principles would write, given alittle time to reflect. There is absolutely no point in having coreinterfaces between components go through those kind of iterations.

If each iteration is viewed as an experiment that has results that
help us build subsequent theory and subsequent experiments, then there
is a strong point to them. It may be that what we need is far simpler
than what "a little domain knowledge and some understanding of
software principles" would create.

I am always astounded by the Bowling Game example. Time after time I
give that problem to developers, and time after time they create
designs with Frame classes and TenthFrame derivatives, and linked
lists of Frame objects, when all they need is an array, a 'for' loop,
and two 'if' statements.
But hey, there have been threads where XP'ers were loath to make anyconcessions about the expense of refactoring interfaces. In one of them,after many exchanges, the estimable Mr Jefferies finally allowed that OK, ifyou were talking about _libraries_, then maybe, just maybe...

Ron knows full well that if Sun were to significantly change the
signature of the String class, they'd have open revolt to contend
with. The stability of an interface is a function of the number of
users. When the number of users is very high, then it's very hard to
change the interface. Therefore, during the early development of the
interface we try to keep the number of users manageable.
That remindedme of a very thick IBM FORTRAN manual I once used that had a very shortsection on functions.

Daniel D. McCracken?
The function, it said, was something you wouldn'tlikely use very often, but if you did happen to have a lot of repeatingcode, you could use it.

We live, we learn -- we love, we learn -- we cry, we learn.


Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

[Bill Burris]

> Perhaps you'll also find "UML for Java Programmers" (www.objectmentor.com/UMLFJP) as useful.


Where is the UML for C# Programmers and UML for C++ Programmers books?

Why would you make this book Java specific? Why not write it so that it is
usable by any programmer using an OO language.

I don't mind reading Java code, but saying that the book is for Java
Programmers makes me suspisious that the book has a lot of material that is
not usable in other languages.

I have your Agile Software Development book, and will likely read it as soon
as I am finished reading "Object-Oriented Multithreading Using C++" by
Cameron & Tracey Hughes.

Bill

[Uncle Bob (Robert C. Martin)]

"Bill Burris" <wburris@ualbera.ca> might (or might not) have written
this on (or about) Thu, 7 Aug 2003 17:03:01 -0600, :
Perhaps you'll also find "UML for Java Programmers" (www.objectmentor.com/UMLFJP) as useful.Where is the UML for C# Programmers and UML for C++ Programmers books?

They are coming. The publisher is waiting to see how the Java book
sells.
Why would you make this book Java specific?

That was the intent.
Why not write it so that it isusable by any programmer using an OO language.

I have already written a book like that. It is: Agile Software
Development: Principles, Patterns, and Practices.
I don't mind reading Java code, but saying that the book is for JavaProgrammers makes me suspisious that the book has a lot of material that isnot usable in other languages.

The book does cover some things that are specific to Java, and it
ignores certain things that are specific to languages like C++
(templates for example)


Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |