Re: [xsl] metrics for evaluating xsl-t?

["bryan rasmussen" <rasmussen.bryan@xxxxxxxxx>]

> >Think of XSLT as a specification language. Does anyone ever
> >quantify/estimate the resources required to maintain office documents?

I think accountants do that. This is what allowed the Danish
government to estimate how much money would be saved by moving from
paper based invoices to UBL.
> >Seriously, this idea of metrics is fraught with the risk of illogical
> derivations.

Sure,  but that does not necessarily mean that any searching after
metrics must inevitably lead to illogical derivations.

> First, the bulk of the effort is in understanding the problem (see
> above). People who don't understand it are doomed to keep solving it.
> How do you quantify business analysis? Are there metrics for meetings?

There may well be. There have been various research efforts done to
understand the cost and effect of meetings on modern business.

> Second, the kinds of hands-off managers who ask these sorts of questions
> are usually the same ones who solve the same problems over & over.
> Usually, their measure is 'completion' of a project regardless of
> whether it solves the *business* problem or not. Metrics should be
> *business* metrics not of lines of code, e.g. what does it matter how
> many loc are used if a one-off automation P saves N people X hours per day?

I at any rate don't believe in lines of code metrics. But I am willing
to consider types of syntax metrics, and to raise warnings to look at
the code - look at, not disallow out of hand.

>  In addition,
> good programmers will often *not* maintain poor code, they will more
> likely throw it away and start over, i.e. see #1 and #2.

I agree with everything you said in point 3 and 4 up to here. I agree
with this point too, but I have heard people complain often that
developers tend to throw away and rewrite XSL-T way too much for it
just to be good/bad code problems. I am not sure I agree with that
observation, but it could be.


> Beware of idiot middle managers who try to hogtie you with artificial
> metrics which learned at business school. Michael wrote earlier about a
> project manager confused by the programmers who produced negative lines
> of code.

I've heard this story elsewhere as well, maybe from Michael some other
time. At any rate while it is amusing I think the programmer also
sounds something of an ass (unless his behavior was enforced by a CVS
or other application from which he had to draw his numbers) - Why?

Well, nobody writes negative lines. What he evidently did was find
code that had too many lines, remove those lines, rewrite code with
less lines. So he reported his efforts as:

-34 lines
+7 lines
= 27 lines.

This is really only one of several ways to think of this process. He
could just as easily report:

I wrote 7 lines.

Or even better count all numbers of lines of code that he interacted
with as possible:

34 + 7 = 41.

If he had followed this way he could probably have explained it
reasonably well to his project manager. It might have been that the 34
lines deleted should be counted as less work than writing so many
lines (although not in my book since to delete you must understand why
you should delete) but the point is that while it may be that the
project manager was stupid, the programmer also seems like one of
those guys who doesn't want to try to communicate (some would say this
is the pot calling the kettle black here).

At any rate there are two types of metrics, one is the metrics of how
to determine how complex a stylesheet or number of stylesheets is, the
other are metrics for determining possible complexity of a
transformation task before it is done, especially as it pertains to
integrating transformations that must be integrated into a
transformation based solution.




Cheers,
Bryan Rasmussen

> Tony Graham wrote:
>
> >"bryan rasmussen" <rasmussen.bryan@xxxxxxxxx> writes:
> >
> >
> >>The other thing is determining the complexity of the transformation
> >>task, pertinent to the individual transformation and its place within
> >>a transformation framework.
> >>
> >>With that kind of metric one can then determine the amount of time for
> >>writing transform etc.
> >>
> >>
> >
> >I got onto the metric idea from the other end: determining what it
> >would take to understand and maintain an existing stylesheet if I got
> >work where there are stylesheets already in use.
> >
> >
> <snip/>
>
> >>of course, as noted, this is different than analysing the complexity
> >>of an actual transform.
> >>
> >>
> >>don't think there's anything like that. Although Sean McGrath had a
> >>blog post once about the true cost of XML, cost includes the number of
> >>namespaces to be understood etc.
> >>
> >>I think we all have a builtin metric for saying how complex we feel a
> >>particular transform likely will be.
> >>
> >>
> >
> >I'd like a simple measure of how complex a particular transform was.
> >
> >For the record, I got started on the XSLT metric idea after reading
> >about Rick Jelliffe's XML complexity metric:
> >
> >http://www.oreillynet.com/xml/blog/2006/05/metrics_for_xml_projects_5_str_1.html
> >
> >The future conference paper that I'd like to see (and present) is the
> >one with lots of manager-friendly graphs relating schema complexity
> >and XSLT complexity from a survey of real projects.  If that existed,
> >it would be easier to explain to your manager why a new stylesheet for
> >a new, complex schema could take longer than a week to write.
> >
> >Regards,
> >
> >
> >Tony.