Home > Archive > Extreme Programming > July 2005 > Agility for APIs and data documents
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Agility for APIs and data documents
|
|
| Steve Jorgensen 2005-07-29, 4:00 am |
| Hi all,
With Agile code writing, one of the main concepts is to avoid thinking ahead,
or doing things because you might need them later (YAGNI), but I'm having some
trouble where code engineering intersects with published APIs and data
document design.
With XML documents, for instance, one of the common pieces of advice (right or
wrong) is that data lives longer than applications, so for instance, even if
only one of the first 2 applications that will use a document schema knows
anything about act actual dates, one might want to include optional actual
date attributes in the spec., and have applications write the data if they
have it to write.
Also, we know of course that any kind of API spec will have to change later,
so one must think ahead to what "you might gonna need" in terms API must be
flexibility so later changes are unlikely to break apps still based on the
older API or require big internal code changes.
I'm assuming someone here will tell me in some convincing way that I'm making
mountains out of molehills. Fire away :)
- Steve J.
| |
|
| Steve Jorgensen wrote:
> With Agile code writing, one of the main concepts is to avoid thinking
ahead,
> or doing things because you might need them later (YAGNI), but I'm having
some
> trouble where code engineering intersects with published APIs and data
> document design.
To use an interface beyond the current project, write at least 3 sample
projects, of different types, that depend on it.
In this situation, the Onsite Customer role requests interfaces as user
stories. They are indeed _user_ stories because they face potential clients
of your program.
So, put by putting the simple XP rules together correctly, you get a
loophole thru YAGNI and DoSimpleThings to produce irrefactorable APIs, and
interfaces wider than application-specific.
--
Phlip
[url]http://www.c2.com/cgi/wiki?Z Land[/url]
| |
| John Roth 2005-07-29, 9:03 am |
| "Steve Jorgensen" <nospam@nospam.nospam> wrote in message
news:45nje153o8u0fffolnm00bqppcmojivr0r@
4ax.com...
> Hi all,
>
> With Agile code writing, one of the main concepts is to avoid thinking
> ahead,
> or doing things because you might need them later (YAGNI), but I'm having
> some
> trouble where code engineering intersects with published APIs and data
> document design.
Oops! Avoiding thinking ahead is _not_ one of the main concepts.
Writing code before you actually need it is.
> With XML documents, for instance, one of the common pieces of advice
> (right or
> wrong) is that data lives longer than applications, so for instance, even
> if
> only one of the first 2 applications that will use a document schema knows
> anything about act actual dates, one might want to include optional actual
> date attributes in the spec., and have applications write the data if they
> have it to write.
I see a fair amount of commentary on XML lists that say that this is
simply wrong. An XML format should be designed to be extensible,
but B&D validation isn't as useful as people think. The people
advocating this viewpoint state that, unless the purpose of your applicaton
is validation, it should take what it needs from the XML stream and
ignore the rest. That's the "be strict in what you create and liberal in
what you accept" philosophy.
> Also, we know of course that any kind of API spec will have to change
> later,
> so one must think ahead to what "you might gonna need" in terms API must
> be
> flexibility so later changes are unlikely to break apps still based on the
> older API or require big internal code changes.
If you're going to version an API, then version the API. If
"distimTheGaloshes"
needs an extra parameter, then "distimTheGaloshes2" may look hokey, but
it avoids all kinds of problems.
> I'm assuming someone here will tell me in some convincing way that I'm
> making
> mountains out of molehills. Fire away :)
I don't think these are molehills. Too many people are making the same
mistakes, and a large part of it is either poorly presented or simply wrong
published advice.
The fact is that there is no way you're going to avoid having to change
things as you learn more or the environment or requirements change. Thinking
ahead is good. Implementing ahead has a real poor track record.
John Roth
>
> - Steve J.
|
|
|
|
|