Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Extreme Schema-building and Query-writing (was Re: (data)mediu
 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
