Extreme Programming For Fixed Interfaces

A "FixedInterface?" here is a PublishedInterface for sale.

news:comp.object discussed whether interfaces that arise from the RefactorMercilessly practice of ExtremeProgramming can create APIs that one can sell to end-user programmers.

DanielParker? 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 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 happens.

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

The best possible domain expert will have experience delivering ApplicationProgrammingInterfaces 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 requesting APIs.

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

The CustomerAcceptanceTest (CAT, from here on in) 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, ProgrammerTest, 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 ("FunctionalTest") 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 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