The politics of finding errors Was:XML

From: Laconic2 <laconic2_at_comcast.net>
Date: Fri, 8 Oct 2004 08:21:20 -0400
Message-ID: <fMWdnUgCSOLJG_vcRVn-hA_at_comcast.com>


"Lemming" <thiswillbounce_at_bumblbee.demon.co.uk> wrote in message news:a2jcm015pihgtvd6ivne489or1ges4vsf2_at_4ax.com...
> On Thu, 07 Oct 2004 21:57:16 GMT, Bernard Peek <bap_at_shrdlu.com> wrote:
>
> >In message <cjsldr$vui$1_at_news.netins.net>, Dawn M. Wolthuis
> ><dwolt_at_tincat-group.comREMOVE> writes
> >
> >
> >>XML isn't brain surgery, but it is likely to make a significant impact
that
> >>really does advance the state of B2B software
> >
> >I've used XML in a situation where it did provide real benefits. When
> >the received data failed to validate it got bounced by the machine and
> >never even reached a human. At a stroke that ended most of the arguments
> >about whose job it was to fix malformed data files.
>
> There shouldn't really be an argument about it. If the data file is
> invalid (whatever format it's in) it's the responsibility of the
> creator of the file to fix it. A receiving system can't reasonably be
> expected to guess what the data should have said.
>
> Having said that, I guess it's easier to spot certain types of
> malformed XML, simply because the structure of the data is made
> explicit in the file in the form of tags. OTOH the malformation is in
> XML itself; If the XML validates, that says nothing about the quality
> of the data within it. The point is you still have to write exactly
> the same validation routines that you would have had to write if the
> file was delivered in a flat file, csv or even in a deck of cards, but
> with the additional overhead that when using XML you also have to
> validate the delivery medium.
>
> Lemming
> --
> Curiosity *may* have killed Schrodinger's cat.

There is something in the above exchange that deserves a discussion of its own.

The fact that XML ended some arguments about whatever. Lemming's response was logical.

The thing is: in an IT shop, a logical argument seldom carries the day. You would think that, since we all practice logic in our craft all the time, a concisely stated solid argument would end the discussion. If you've ever been through ongoing battles about whose fault it really is, you KNOW that it's not true. I don't have to prove it to you.

Back when I was consulting, I was called in when the people were having problems with their database. At most shops, there was plenty of local talent, mostly full time employees. Most of these people were earning their pay, and were definitely worth keeping on board. But they had problems that they could not fix. And, with one or two exceptions, the problems were real.

The idea that managers simply hire consultants to CYA when things are going south, and that the problems are just as bad when the consultant leaves as they were when the consultant arrives, just doesn't match my own experience. And it doesn't match what Joe Celko has said in here about fixing up people's databases either. Maybe that's the current industry trend, and maybe that's why I'm not as successful as I once was. If so, I'd rather drive a truck.

As far my work was concerned, the EASY part was figuring out what was wrong inside the database. The HARD part was effecting change within the shop's culture. If you just fix the database and leave, you've added very little value, although you may have guaranteed some repeat business. If you just point out all the mistakes that were made, in a way that makes everybody embarrassed and angry, you won't even get the repeat business, and your fix will not be implemented.

To really change things, you have to change the people. And that's HARD WORK. Even if it looks easy to those of you who watch a consultant breeze in, make a huge fee, and leave after just making a few key recommendations. If XML helps stop arguments about where the fault lies, that alone is a selling point for XML. Received on Fri Oct 08 2004 - 14:21:20 CEST

Original text of this message