Re: [xml-dev] Re: XML As Fall Guy

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

On Wed, Nov 27, 2013 at 10:34 PM, John Cowan <johnwcowan@gmail.com> wrote:

On Wed, Nov 27, 2013 at 4:06 PM, Ihe Onwuka <ihe.onwuka@gmail.com> wrote:

Having people on the project that possess the necessary skills is also cast as a threat (won't be able to maintain it or replace their skills).

Running the project with people that lack the necessary skills - somebody once looked me straight in the eye and said "Can't you see we're mitigating risk by doing it this way".

I'm sure he *was* mitigating his own risk.  For people like that, the risk is not that the project tanks, but that their career does.  If they can't be blamed for the fiasco, all is good.

This kind of person is what's called a Sociopath in the McLeod organizational model, which divides employees into Sociopaths, Clueless, and Losers.  It's the Clueless who want projects (or companies) to succeed, which is why they make good middle managers who can be tossed like used latex gloves.

 

The end client had  bought Altova MapForce . Mapforce describes itself as a Graphical Data Mapping gives you an interface for generating transformations much like the Query By Example interface to MS Access but underneath the XSLT code it generates is spaghetti procedural.

I was placed on to the project by the consultant firm they had hired. The first thing the client did was to ask me to fix the performance of  a slow running transformation. I looked under the hood and found that MapForce translates lookups into code that calls the document function (and therefore does file I/O) EVERY TIME something is looked up.

The performance fix is to cache the looked up file with xsl:key, but xsl:key is not part of the subset of XSLT code that Mapforce generates (checked this with the vendor). So I told the client I would have to hand code that particular transform and was told by the team lead that everything had to be done with MapForce. When I said that was the only way to fix the performance of that transform I was told "Can't you see we are mitigating risk this way".

It was a philosophy the whole team had bought into - I spoke about it to another team member and he said

"It's the 80/20" rule. We can get 80% of the transformations we need this way"

I asked him how they were going to finish 100% of the project and he started looking intently at the screen.

Mapforce also generates C++, C# and Java - since the whole team is convinced that XSLT development is a risk, why choose the option that generates spaghetti procedural XSLT? In the MapForce/QBE analogy, XML schemas play the role of relational tables. So by choosing this path they had traded their fear of transformation code for an obligation to write/provide XML schemas. MapForce have a tool that auto generates schemas from an instance. Oh goody. All Mapforce users have to do now is figure out how to construct a super instance that encapsulates 100% of the use cases for the relevant content model(s) and they are golden.

For the rates * the number of consultants they had brought to pursue this methodology  they could have had a proper team