Re: [xml-dev] [OT] Re: [xml-dev] Lessons learned from the XML experiment

[Ihe Onwuka <ihe.onwuka@gmail.com>]

Sod it.

This has always happened in IT. Before XML it was with something else.

In my view at it's root is the fact that

a) We are not a profession

b) Enterprises are unwilling to invest in training.

c) People are assumed to be competent by virtue of their position or
job title. It is not socially acceptable to tell someone they are not
a competent developer/analyst/architect or whatever. You don't have
this problem in Quantitative disciplines because people are quite
ready to admit their shortcomings. People will readily and proudly
tell you they are crap with figures - so if a role requires say a bit
of calculus they will readily self-exclude. Not so with IT. Everybody
that once upon a time managed to cobble together 5 lines of code to
automate some activity thinks they are a competent programmer and
nobody dare say otherwise. There are in-built mechanisms for ensuring
this - you show somebody something different that challenges his
comfort zone and he says it won't perform or is unreadable and points
to his 5 times bigger procedural monolith as the essence of
comprehensibility.

d) Enterprises are happy to employ and deploy such people to develop
software and will happily invest large sums of money in products and
methodologies that will allow such people to produce some form of
software that gives the outward appearance of being functional. They
fill up teams with such people and mediocrity becomes the barometer
for  being able to join or work on such teams. Genuinely talented
people are either put off, considered not a good fit or marginalised
in the team and ignored and reduced to hapless bystanders on the
project - (does that sound like Kurt's situation on the ACA project?).

e) You then have scenarios where the most valued skills on a project
are not genuinely talented programmers designers or analysts, but the
ability to tinker  with and patch badly designed, poorly written
software.

Basically this industry can afford a very comfortable living to alot
of people  who have never and never intend to master the technological
and domain knowledge demands of their position. Hence a primary design
technique is and will always be unnecessary and expedient compromise
and cut and paste.




On Sun, Nov 17, 2013 at 9:44 AM, Stephen Cameron
<steve.cameron.62@gmail.com> wrote:

>
> I have read a few introductory books on XML and dabbled with XSLT for a long
> time, for me an XML document is a tree of nodes that I can navigate via
> XPath, or which can be parsed and turned into a stream of events. XML
> Technologies are built on top of either of these two powerful approaches.
>
> My interpretation of what I obtain at the end of such an XPath, or with such
> a generated event  is a different issue, though obviously of major
> importance too.
>
> I have been interested for some years in the idea of an XML technologies
> based infrastructure that is very cost-efficient for data management in
> science. For me Hans-Juergen's papers at Balisage have expressed very well
> this general idea and a detailed analysis of what might be done to further
> it.
>
> However. in the IT circles I've move in there has been a major 'perspective'
> related barrier to achieving anything significant towards this vision, which
> is the OO programmers 'every thing is an object' perspective vs the XML
> 'every thing is parseable and navigable data' perspective. There is a
> related difference of perspective in the database world between the set
> (relation)  and the navigable graph based approaches it seems.
>
> I think that the recent posts by Kurt Cagle on the ACA implementation
> problems and his diagnosis of the causes have implicated this contrasting
> perspective, hence its importance as a topic for discussion [The OO
> perpective leading to the notion that objects can massage any parsed data
> into something useful, well possibly yes, but at what cost?]
>
> I think that such differences in perspective relate very much to tools
> (technologies), the tendancy for all of use to like/want/need to use the
> tools that we are familar with and as a result not question the assumptions
> on which the tools are based (If all you have is a hammer, everything looks
> like a nail), or, to be that interested in learning about alternative tools
> in any great depth, particularly when your boss is asking for a time
> estimate for task completion.
>
> Hans-Juergen seems to me to be mainly interested to tease appart this
> specific difference of perspective and I admire his efforts in this.
>
> Now. in his efforts there might be a deeper truth about markup missed (in a
> 'technological rush' maybe? ;) ), one that I too have missed and which I am
> happy to learn more of. But I am VERY interested to focus in on the ACA
> issue and what lessons the "XML Experiment" might hold, given that my
> analysis of its origin is valid.
>
> Many thanks for your insights.
> Steve Cameron
>