Subject: Re: [xsl] metrics for evaluating xsl-t?|
From: "bryan rasmussen" <rasmussen.bryan@xxxxxxxxx>
Date: Thu, 24 Aug 2006 09:29:29 +0200
>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:
Or even better count all numbers of lines of code that he interacted with as possible:
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.