I only have a couple of issues:
3. Documentation in code... So, if a non-programmer needs to know what's going on and does not have access to the code, how are they supposed to get at the documentation. Documentation is not only for developers, it is for those who need to know how to install it, how to perform any set up. Put documentation in a repository so those who need it can get at it. Word and Visio work great for documentation.
If the documentation is not in the code it will NOT be maintained and it WILL get lost. If you want to document it elsewhere, great and good and there are many wonderful tools for exactly that purpose. BUT, one day some poor schlub (who might be yourself) is going to have to fix the program and they will primarily rely on the documentation built into the code.
My intention was not to stop people producing other documentation, it was to ensure that they do not neglect the in-code documentation because they have a stack of Specifications, Entity Relationship Diagrams, Requirement Lists, Manuals and Printouts. Oh, and do not EVER run a utility that strips out all of the comments from your code. If someone wants to steal it, they can do that with or without the comments, but you do not want to experience the embarrassment of trying to fix your own code after the only copy had the comments stripped out (not me, but a good friend !)
8. DO NOT EVER hard code dates. Or, most anything else. EVER! (Yes. I did intend to shout). When the program fails and you are not around, it will be bad for whomever is around to handle the issue. Put them in a table and reference that. And, don't calculate dates for only 10 years. Programs I wrote in 1989 are still in use. Do not assume that your code will be replaced within a certain period of time.
You are right, I expressed that one badly and did not give as much detail as I should have.
When I referred to hard-coding Public Holidays, I did not mean for them to be specified in the code - a Lookup Table is the ideal approach. My point was that it may be possible to calculate the dates of the Public Holidays into the future, but it isn't worthwhile, especially since they could change. Thus, a lookup is a better approach.
I also failed to mention the proviso that, if you do use this approach, you must have a way to alert the users when the information expires or for the users to know what information is hard-coded. Thus, when the lookup has no more dates in the future, you could display an alert stating that the Public Holiday list needs to be updated. Similarly, if you have a hard-codes sales tax rate (this was often done in Britain in the 80s), there should be something that states the rate being used without the user having to go an look for it, perhaps a confirmation prompt or an on-screen display.