Subject: RE: [xsl] RE: Test-driven XSLT development?
From: Norm Birkett <Norm.Birkett@xxxxxxxxx>
Date: Thu, 29 Mar 2012 15:37:30 +0000
> -----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