Software design: comprehensive reasons not to hardcode Christmas as Dec 25th

The other day, I was talking about software design and the subject of hardcoding values came up. Someone said that there probably are cases where hardcoding of values was a sound idea. I replied that the mark of a good software designer would be that when it was suggested to hardcode Christmas day as December 25th, they’d stop to think, then come up with at least one valid reason why it might not be a great idea.

Now, I’m not sure that was such a particularly profound statement as it seemed when I was saying it, but I thought it might be fun to try to draw up an exhaustive list of reasons not to hardcode Christmas day as Dec 25th, so…

Firstly, Christmas day isn’t Dec 25th in some parts of the world.

The product might be used in a market where Christmas doesn’t happen at all.

Whatever purpose there might be for encoding Christmas=Dec 25th in the product, there may be an indefinite number of other dates that need to be treated in the same general way - and some of those might be variable, so it makes sense to develop a single coherent method for handling them all.

Is there not some concievable set of circumstances, however unlikely (civil emergency, death of a monarch?), that might contrive to cause Christmas (at least insofar as it pertains to the product) to be adjusted?
What else?

Metric calendar? Takeover of the whole world by China and they impose their calendar?

Customer wants Julian Dates.

Centralized and flexible data references are fine but I don’t want to live in a world where we are just one hack away from screwing up Christmas for everyone everywhere. The potential for disaster is even bigger than Y2K. Don’t give the Grinch another possible ploy. Keep Christmas hard coded and make the hackers work really hard at messing things up individually if they feel the need to do it. Add Halloween and my birthday to the list of acceptable hard-coded values too because they aren’t changing under my watch. Throw the speed of light and atomic masses in there as well because we have bigger problems than software if they start becoming negotiable.

For some values of Christmas, Christmas=January 7.

Why do programmers celebrate Christmas on the 31st of October?

Because 31 OCT = 25 DEC .

Hah.

Asimov did it first!

Is there an algorithm to calculate Easter? Presumably you’d need to include some kind of complicated moon phase doohickey.

In addition to the reasons already mentioned, it’s a best practice matter to avoid hard-coding whenever reasonably possible.

It is also a best practice to be consistent. If you have some holidays, such as Easter, that are subject to complex business rules (i.e. the date has to be calculated based on criteria), it makes good design sense to define Christmas through the same module.

If it’s for the “working calendar”, in many locations December 25th is a holiday except when it happens to fall on a Sunday; in some businesses / factories / etc., the 25th will be a government holiday if it’s on Saturday, but still shouldn’t be counted a “holiday” for company-calendar purposes because the company never opens on Saturday. The day is still called “Christmas”, but you don’t want it to be automatically marked as a holiday and deducted from the amount of “available company-calendar holidays for the year”.

Here’s one - although I didn’t test it.

Good one. I’ve never seen that one.

Likewise, some employees are entitled to Christmas as a holiday even when it falls on a weekend. So for instance in 2010 and 2011, the union at my city hall was entitled to a holiday for Christmas in spite of it falling on a Saturday and Sunday respectively in '10 and '11. So for payroll purposes in 2010, Christmas was on the 24th and in 2011 it will be on the 26th.

This could be a really good interview question. I’m going to try to remember it.

-D/a

Holy crap, I’m actually doing something right. I always avoid hard coding things. I thought I was just being lazy and writing code that didn’t need to be messed with much once it was working. Plus mixing data and code seemed icky.

Absolutely - that’s the whole point - IMO, a horror of hardcoding should be ingrained into the process of software design.

It’s business/management that tends to stray off and casually regard things that never usually change as being unchangeable - and in the requirements capture part of a system design, it’s really common for the customer to argue that treating Christmas as data, not code introduces complexity they think they’ll never need.

I’ve seen it several times in my own career, and had to strive to clean up the consequences when the choice to hard-code (or just code according to some constraint that turned mutable) came back to bite us.

And, in terms of consistency, if your customer (or a FUTURE customer that your BD people found) decides that St. Swithin’s day needs to be added, it’s a lot easier to add it to a configuration file or add it as a database entry than it is to deploy a new build. For those holidays that have complex rules to determine in the Gregorian Calendar such as Easter or Eid, you can add script to your configuration file, or you can have a separate module (e.g. a DLL) that plugs in that includes holidays (e.g. “hard” coding the calculation rules in that module), so when the customer asks for St. Swithin’s day, you just give them a new Holidays.dll rather than releasing version 1.01 of your product.

Doesn’t the Old Testament cover that right after mixing meat and dairy?

What happens when sales decides…

We are sorry, we no longer support version 1 of our product, you will have to buy the 1.01 upgrade if you would like your existing support agreement to stay in force :smiley: