Footpaths and schemas

I'm sure there are dozens of versions of this story, but I heard it from Larry Wall, the father of Perl, and it goes like this. Instead of laying down sidewalks, the builders of a new university campus waited for footpaths to emerge on the lawns. Then they paved the footpaths. Perl's design was informed by this idea of structure emerging from use, but that was an unusual case. We typically lay down the sidewalks first, and when footpaths emerge we profess surprise or try to ignore them.
Of course it's easy to criticize information systems that fail to embrace sloppiness. It's much harder to explain how they should. Sloppiness is only a means to an end. In order to make things work and get things done, we need to codify patterns of use. It's a Catch-22, though. The right patterns don't emerge from systems that people won't use. How we reconcile specification with emergence isn't an engineering discipline, but it probably should be. [Full story at]

This column includes a nice anecdote from John Schneider about military messaging in the pre-XML era. He is, by the way, one of the many bright minds appearing at InfoWorld's SOA forum tomorrow (Thursday) here in San Jose. In a follow-on email conversation about the role of schemas he proposed the following strategy. Describe your domain of discourse as well as you can, because shared context makes communication more efficient. But don't assume that your schemas are completely accurate or that they define the entire domain of discourse. Systems must be "dynamic enough to extend and refine their context through experience -- i.e., they must learn".

Good advice for a loosely-coupled world, though following it is easier said than done.

Former URL: