" here is a PublishedInterface
discussed whether interfaces that arise from the RefactorMercilessly
practice of ExtremeProgramming
can create APIs that one can sell to end-user programmers.
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 TestDrivenDevelopment
, 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
First, get the best possible DomainExpert
(just like any other methodology [right?]).
The best possible domain expert will have experience delivering ApplicationProgrammingInterface
s to UserProgrammers?
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 UserStories
The team's job now is, for each US, is to help the OnsiteCustomer
criteria. "Help" generally means "challenge" here. Everyone's job is to challenge assumptions.
(CAT, from here on in) for an API feature is a small app using that feature the way a
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, ProgrammerTest
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
") as freely as ProductionCode
, 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
. So when the CATs pass, the OnsiteCustomer
takes the UserStory
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;
reateFileEx() 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.