On 29/08/2012, Kurt Cagle <
kurt.cagle@gmail.com> wrote:
> Roger,
>
> 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
>
kurt.cagle@gmail.com
>
443-837-8725
>
>
>
>
> 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
>>
>> Thoughts?
>>
>> /Roger
>>
>> _______________________________________________________________________
>>
>> 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
>>
>>
>
_______________________________________________________________________
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
