RE: RE: Test-driven XSLT development?

> -----Original Message-----
> From: Andrew Welch [mailto:andrew.j.welch@xxxxxxxxx]
> Not only that, but also all the various ways to count days:
>
> http://en.wikipedia.org/wiki/Day_count_convention
>
> I've had the joy of writing a bond interest calculator...
>

I know we've strayed a bit outside the list's bailiwick here, but it may be
unto general edification to add that day counting is a very good example of
why disconnects arise between a "commonsense" (which, alas, often means
"superficial and ignorant") view of software and the realities of building the
stuff.

<dramatization>

User: To calculate the interest, you just multiply the nominal interest rate
by the fraction of the year represented by the interest period. So if the
interest pays quarterly, just multiply by 1/4! Now get to work and I need it
tomorrow.

... Next day:

Programmer: What if you pay off the debt before the period is over?

User: Well, just count the days, and use them to come up with the fraction of
the year. When will it be finished?

... Three hours later:

Programmer: If the period is in a leap year, what do I use as the
denominator?

User: 366, I guess. Why do you have to complicate everything so much?

... An hour later:

Programmer: What if the period starts in a non-leap year and ends in a leap
year?

User: For Pete's sake, will you leave me alone and just get the job done!?!

Programmer: I hope it's not impertinent to say that you haven't really defined
the job for me, and I can't get it done if I don't know what it is.

User: Yes, that is impertinent. Go look it up.

... Ten minutes and a Wikipedia article or two later:

Programmer: OK, I think I've got it now. Which daycount convention do we use?

User: I don't care. Just use your fingers to count the days if you have to.

Programmer: No, is it 30/360, actual/actual, actual/365? ISMA? [blah, blah,
blah, blah, blah]

User: OK, that's it. You're fired. If you can't follow simple instructions,
I'll find someone else to do my coding.

... Fortunately, this part of our story has a happy ending, because our
programmer aces his first interview at a Wall Street firm and gets a job
paying twice as much. Everyone is so impressed that someone with such slight
financial experience has heard of day-count conventions!

But meanwhile, back at the ranch, nine months later...

User, looking crazed, backing up across the conference room toward the door,
holding his fingers in the shape of a cross in front of him: Don't even ask
the question! I can tell by the look on your face that you want to ask me
about THAT SUBJECT! Just get out of here. You're all the same, aren't you? Do
they teach you all in college how to drive us crazy? Is it COMP SCI 102, User
Psychology and How to Exploit It? Just go away, and don't come back. [Reaches
the door and bolts, screaming "They're here, they're here."]

Programmer4, to shocked innocent bystander: What's eating him? I just wanted
to know how to book company holidays in the project management system. [Ba
dump bump]

</dramatization>

For those of us who are blessed to work with business analysts who have heard
of this stuff, this is all just a dim memory from some earlier consulting gig.
But for many software developers, we have to be both the programmer and the
subject matter expert, because the process of software construction often
requires education beyond what is known or even cared about by the users we
work with and report to.

I suspect that basic fact of life extends into the XSL/XML world as much as
any other programming subculture, but I'd be curious to know if you XSL/XMLers
haven't had that experience.

Norm