OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] The Rise of Worse is Better


First - I wanted to say again how much a pleasure it was to finally meet you at Balisage. I only regret that I was not able to stay for the full conference.

There is an old cantrip to the effect that Perfection is the Enemy of the Good. It is used to justify a great number of sins in programming as elsewhere, and I'd argue that while there is benefit to this position, there's also a point where Mediocrity is just as much the enemy of the Good, and in many respects far more dangerous.

I can give a good example of this from my own work. I am working on, among other things, trying to develop an ontology for data interchange in a Federal insurance program.  It is a project that suffers from vendoritis - the project is time constrained, and the vendors and primary contractors on the project, eager to start billing hours, started programming long before requirements were fleshed out, before data models were even understood, and before larger stage planning had fully been accomplished. This meant that a lot of schemas were surfaced that consisted primarily of attributes taken out of a relational database table or a screen-scraped form and thrown into a flat XML structure. Given that there were dozens of participants in this particular process, each of which had a need to talk to one another (but that weren't doing it just yet), what eventually emerged were dozens of different approaches to handle the same process. As a consequence, much of the code that has been written to date built around a web services framework now suffers from Babel syndrome, and XSLT transformations are put into overtime work to try to keep communication going just between two parties. Because of performance issues, fully 2/3 of this code will likely have to be thrown out.

I've been pushing to get a NIEM based standard in place, but it's been a real uphill slog, not least of which because NIEM itself is a complex schema that Java developers especially tend to dislike because they have to cross namespaces, which adds complexity to their JAXB code. So why NIEM? Partially because it does a reasonably good job (once you understand what you're doing) in modeling a lot of the core objects that this kind of application tends to have, it establishes a formal discipline on naming conditions and rules that multiple distributed partners can work with, and it has a known development and distribution process. It's also something that other Federal agencies are moving towards for the kind of people management exercise found in this project.

So in many respects the worse is not better than "good". The more integral a piece of software is to a system, the more that flawed code, poor design and interface decisions, and a lack of consideration for broader architecture will impact upon the ecosystem that evolves around that product. In an ecosystem starved for alternatives, the "poor" might actually gain some traction because the alternative is the "none" but any more, the ecosystem is generally far from starved. There is a case for not trying to go to perfection, of course - business requirements change, which in turn force changes into technical specifications, so perfectly tailored solutions will eventually get out of sync, but I think its a case where what you should be striving for is flexibility and balance - sacrificing more development time and perhaps some performance in order to make a component sufficiently flexible to meet the business needs for a longer period of time, and hence allow for a some redundancy in the system. 

Kurt Cagle
Invited Expert, XForms Working Group, W3C
Managing Editor, XMLToday.org

On Wed, Aug 29, 2012 at 7:13 AM, Costello, Roger L. <costello@mitre.org> wrote:
Folks, Hello,

I just read an interesting article titled, The Rise of Worse is Better.

    The lesson to be learned from this is that it is often undesirable
    to go for the right thing first. It is better to get half of the right
    thing available so that it spreads like a virus. Once people are
    hooked on it, take the time to improve it to 90% of the right thing.

I think this lesson applies to XML as well. Rather than developing a data model (e.g., XML Schema) that tries to do everything, create a simple data model that spreads like a virus and then take the time to improve it.

More ... http://www.dreamsongs.com/RiseOfWorseIsBetter.html




XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS