[
Lists Home |
Date Index |
Thread Index
]
Jeff Lowery wrote:
>Just be careful. Everytime I've been suckered into taking user requirements
>literally, I've built systems that are fragile and unextensible. And then
>the new requirements come in.
>
Most people here probably know this, sorry, but this is what Extreme
Programming is all about: keep the users involved throughout the whole
process, not just the beginning and end; release early and often so they
KNOW what they will get; and plan to be flexible because they are almost
certain to change their minds once they see their brain farts turned
into executable code (or the Next Big Thing hits the trade press, or
they see how cheaply they can upgrade their hardware, or whatever). I
can't personally vouch for whether XP actually works as advertised, but
all the other stuff like pair programming, "the tests are the real
specification," the discipline of refactoring, etc. are there to deal
with the reality that fixed specifications are obsolete when they come
off the printer in most organizations.
>
>
>Now, I could continue in another vein about my experiences of users not
>really knowing their business, although they may perform their day-to-day
>functions quite well. Teaser: they fail to have a complete conceptual
>business framework within which to see the full ramifications of their
>particular functional role.
>
Hmm, I think this is a consequence of "Bosworth's Law" (or at least Sean
credits it to Adam Bosworth in
http://www.idg.net/ic_1263729_9700_1-5062.html): people think about the
concrete information they need to know to do their jobs, and have a hard
time with abstractions. " every layer of abstraction costs you 50% of
your audience". That's the world we live in, and we have to deal with it.
In other words, things change all the time, and most people are not
comfortable dealing with the abstractions that might provide a unifying
perspective on how they change. What does this imply for XML practice?
If on one hand you ask the users how they do it or what they want and
bake that into code or a schema, you will get a fragile, unextensible
system. If you bring in a team of geeks to figure out useful
abstractions for what they do and what they want and bake those into
code or schema, you risk "running out of oxygen" as Joel Spolsky puts it
in his famous essay on "architecture astronauts"
http://www.joelonsoftware.com/articles/fog0000000018.html. "Sometimes
smart thinkers just don't know when to stop, and they create these
absurd, all-encompassing, high-level pictures of the universe that are
all good and fine, but don't actually mean anything at all. "
So, what's to be done? I don't pretend to have solid experience, but
maybe the ideas of "Extreme Programming" have a place here: figure out
the minimum amount of structure you MUST assume to be productive, get
constant feedback from the users to see if you are part of the solution
or part of the problem, and be ready to re-do it when things change, as
they inevitably will. Maybe ... focus on finding the appropriate level
of constraints (maybe on tag names) that remove more "noise" than
"signal", but don't obsess about finding just the right content mode for
all the elementsl; maybe use data types and validation where they really
matter (dates, money, measurement) but don't try to figure out universal
abstractions for things like addresses and phone numbers that vary
greatly and are going to be read by a human anyway; and think more about
extracting the information you need from the data people create than
trying to make people create data that fits your needs.
|
