Re: Function to count workdays
- From: mike@xxxxxxxxxxxxxxxxxxx
- Date: 24 Aug 2005 07:15:34 -0700
On 22 Aug 2005 11:33:27 -0700, jimfortune@xxxxxxxxxxxxx wrote:
[snip]
>> That's half the story. The problem, in case you've forgotten, is that
>> I got a compile error, but you didn't. Did you solve *that* problem?
>
>I changed the file and uploaded it.
There's your problem. Your release procedure doesn't require you to
even compile code before moving it to production, let alone test it.
>I'm usually more careful.
You might be. We don't know "usually"; we just know what you posted.
>> My first recommendation was "Store business data in tables, not in
>> code." It still applies. Storing part of your business data in tables
>> and part of it in code is almost as bad as storing all of it in code.
>> Maybe worse.
>
>I see what you mean by business data now. I prefer handling holidays
>separately.
Everyone has preferences, but not all preferences are created equal.
*Why* do you prefer handling holidays separately? What advantage do
you see to calculating some of the days when some people don't work?
[snip]
>> If you can write good tests, you should find the problems pretty
>> quickly. IMHO, if you can't figure out how to test code, you shouldn't
>> release it.
>
>Yes, a simple compile would have found the problem.
But you didn't do a simple compile.
And although compiling finds most syntactic mistakes, but it doesn't
find any other kind. That's why experienced programmers write tests.
(In Access, compiling might not even find syntactic mistakes. Think
"conditional compilation" and "corrupt project" for two examples.)
>The reason for not
>doing a compile was that the code is being used daily and the
>replacement IsEaster function, which ironically came about from months
>of testing and verification, should have been a simple deletion of the
>'2.'
There's no irony here.
The odds are that you didn't compile your code because you believed
"This change won't break anything." No programmer with more than a
week of experience believes that.
Researching and recording the dates of Easter in a table would not
likely take months, even if you assigned the job to a high-school
freshman and asked for all the Easters for the next 500 years. Is it
really a wise use of time and money?
[snip]
>> Oh, I think "Store business data in tables, not in code" is the best
>> point so far.
>
>Err.., the tables don't run themselves. Getz' solution required code
>also.
Yes. But I don't use a holiday table. I use calendar tables. Getz
didn't calculate holidays either.
Simple SQL statements do all the counting. Sometimes I need the result
in code. But the code that runs a query and extracts the only value in
the only row it returns is simple and commonplace. The system is
internally consistent--every day is treated the same; it's just a row
in a table. It's completely transparent; even noobs can see what's
going on, and tell immediately if something's wrong.
Calendar tables are useful in ways I didn't have to anticipate. The
last question I got was, "Can I get a report of all the months that
have five Fridays?"
You seem to think you have some significant insight that more
experienced programmers lack. I'd like to know what it is.
(Experienced programmers don't give much weight to "preference".)
>> >> Code that calculates work days has trouble coping with uncommon events,
>> >> like terrorist attacks, utility failures, worker strikes, and natural
>> >> disasters. Calendar tables handle these kinds of things easily.
>> >
>> >Good point. My function is mainly for the future rather than the past.
>>
>> That might be what you intended. It's not what you coded.
>
>What I mean is that the application I use the functions in is looking
>at future capacity, so terrorist attacks, strikes and other exceptions
>did not have to be dealt with.
Your application *might* know that, but your code doesn't. (And it
doesn't work that way, either.)
>This point you made is what convinced
>me that a table to handle exceptions that is not calculated would be
>useful.
Why? What are you *really* interested in? Your MDB file is named
"WorkdayFunctions.mdb". Your module is "modWorkdayFunctions". The
first two public functions are CountWeekdays() and CountWorkdays().
Aren't you really interested in working days? There's nothing
exceptional about a day some people don't work. It's all just business
data.
[snip]
>> >> Suppose the federal government makes August 12 a national holiday
>> >> beginning in 2008. Let's call it "Stupid Interface Day". Updating a
>> >> calendar table is so simple I won't even go into it. How do we update
>> >> your code?
>> >>
>> >> Well, we need to add a function, "IsStupidInterface()". That's pretty
>> >> easy. And we also need to add a case to IsHoliday(). Is your problem
>> >> obvious to you yet?
>> >
>> >It would take about half an hour including changing the user interface.
>> >What's the problem?
>>
>> The problem seems to be that you didn't actually try to *do* it. Run
>> that change through a full software lifecycle and tell us how how you
>> get on.
>
>Do you mean using automated testing software?
No, I mean make the change, move it to production, distribute it to all
the sites that use it, and follow it into maintenance. That should be
a real eye-opener.
--
Mike Sherrill
.
- Follow-Ups:
- Re: Function to count workdays
- From: jimfortune
- Re: Function to count workdays
- References:
- Function to count workdays
- From: jimfortune
- Re: Function to count workdays
- From: mike
- Re: Function to count workdays
- From: jimfortune
- Re: Function to count workdays
- From: mike
- Re: Function to count workdays
- From: jimfortune
- Re: Function to count workdays
- From: mike
- Re: Function to count workdays
- From: jimfortune
- Re: Function to count workdays
- From: mike
- Re: Function to count workdays
- From: jimfortune
- Function to count workdays
- Prev by Date: Re: A comparison among six VSS remote tools including SourceOffSite , SourceAnyWhere, VSS Connect, SourceXT, VSS Remoting, VSS.NET
- Next by Date: Re: ARGH! Type Mismatch on Set Recordset
- Previous by thread: Re: Function to count workdays
- Next by thread: Re: Function to count workdays
- Index(es):
Relevant Pages
|
Loading