Is Hard-Coding Ever OK?
I've never known Value Added Tax (VAT) here in the UK to be anything other than 17.5%. I always thought it was set in stone, never to change. Having just Googled it I see it changed from 15% to 17.5% in 1991, but has remained the same for the last 17 years.
Next month it is going to change back to 15% in an attempt to stimulate the economy (yeah right, like "Oooh, now that iPod is £2 cheaper I think I will buy it after all").
When I saw this on the news last night the first thing that came to mind is how many places I've hard-coded the VAT rate as 17.5% and how I'm going to have to go about soft-coding it before the cut takes place.
I guess it just goes to show it is never ok to hard code something that is so obviously a variable. No matter how often it might change, chances are some day it will.
Lesson learnt.
Skip to the 
You can subscribe to an individual
I've got to do this too. Here's me thinking having the VAT set at 17.5 wasn't hardcoding.
First things first though, I need to work out which of the Notes applications have VAT in them!
I remember 15%, but it is more complicated than that. Some things are zero rated, some things are 5% (fuel I think) some combination products (gas cartridge powered heated hair curlers and their refills as I recall) have a complicated VAT status. I have a fair bit of impact analysis work though! One thing that gets very tricky is credit notes. If you invoice now for £1000 plus VAT then again next week for £1000 plus VAT and later next month issue a credit note for £1000 plus VAT what is the gross figure of the credit note? £1150? £1175? The answer is it depends on the tax point of the credit note, which in turn depends on the intent of the credit note. If it was cancelling one of the invoices then the tax point of the credit note is the corresponding invoice date.
http://www.hmrc.gov.uk/manuals/vattosmanual/VATTOS5230.htm
So the lesson is that once every 17 years or so something interesting happens in accounting.
Oh my!.
I must be getting old or something, but I very clearly recall not only changes in VAT rate, but multiple concurrent VAT rates where "luxury" items like TVs used to attract more VAT than other items, like adult clothing. Food, children's clothing and (if I recall correctly) books have always been VAT exempt.
Any system which calculates VAT should therefore be able to handle different VAT rates simultaneously and so would never have had 17.5% hard coded.
We were just discussing this very issue here last night as it happens and changing VAT rates (which are not hard coded in any of our systems) will be very easy.
What is much less easy is to work out the implications for third party stock funding, where stock is funded assuming 17.5% VAT but, if sold after Sunday next, will attract only 15% VAT.
Why do politicians always assume these things are easy?
Well, even if it's hard coded I assume no one is actually using the '17,5' figure in several places in their code but instead have a global variable or settings object. So it's only a matter of 'softify' in one place per code base.
I'm obviously old too (or is that too old), as I actually still think of 17.5% as 'new', although I didn't realise it was that long ago it changed.
I had just finished checking the extent of the changes I was going to have to make when I read this blog, luckily for me even my very old system which I thought I'd hard-coded VAT in lots of places has a nice single script library to get VAT (where 17.5 is hard-coded but I can change that to look it up easily enough)
Alan/Chris are right of course, but most systems won't have to deal with the complete spectrum of VAT. We do have to deal with 2 different types of 0 rating though which for accounting purposes get separated out. I guess accountants can even make 0 'interesting'
I answered here: http://inotes.de/blog.nsf/dx/the-times-they-are-a-changin.htm
So if I have this right, valid UK VAT rates are 0%, 5%, 15% and 17.5% (we are reverting to 17.5% on 1 January 2010).
Heck.
(yeah right, like "Oooh, now that iPod is £2 cheaper I think I will buy it after all").
There is strong statistical evidence from the past that such tiny changes in taxes do actually have a effect on aggregated demand, no matter if you are going to buy an iPod or not. One of 10.000 Englishmen probably will.
Personally, I avoid hard coding anything, but that's just my humble opinion.
I'd rather an application administrator have the ability in some profile to change any potential variable that could change, even if it's sending them code for a Smart Icon and instructions on how to change a value that is computed in their associated profile document.
A lot of the databases I've built in the past have multiple customers accessing them, requiring data segregation on a hub/spoke infrastructure and implementing selective replication formulas to avoid exposing data from customer "a" to customer "b"; more or less, I've been forced in to this habit. Even if it's not multiple customers per se, it may be various business units within the enterprise that may require different values.
For example, customer "a" requires I prune their log entries every x days, and customer "b" requires I prune their log entries every y days, and the overall system log requires entries to be pruned every z days--3 variables stored in separate profle documents.
I feel I need to point out at this point that I never hard code and am completely against the practice.
Well, I say never, I mean hardly ever. The only time I do is when I think it's "safe" to do so. Until yesterday I thought VAT was a "safe" bet never to change. This was down I think to naivety on my part rather than generally bad coding. I do know what I'm doing. Honest.
As a funny aside it's worth reading about the debate over whether a Jaffa Cake is a cake or a biscuit. HM Revenue want to class it as a biscuit and back-claim millions in VAT from the manufacturer, McVities. McVities took them to court to prove it is in fact a cake (just a very very small one) and so VAT-exempt, as cakes are a "necessity" whereas biscuits are a "luxury". I kid you not.
http://en.wikipedia.org/wiki/Jaffa_Cakes#Cake_or_biscuit.3F
I think the definition of cake vs biscuit comes down to what they do when they go stale. Cakes go hard, biscuits go soft. Jaffa cakes go hard.
a fact that I wouldn't have bothered to type if I had read the wikipedia article first :-)
Ireland's VAT rate is going up on monday.
As possibly the oldest person watching this blog, let me say I remember when there wasn't ant VAT - and when there was how it varied. Not just the rate (how many spaces do you leave for that?) but in terms of configuration management, do you provide a facility to change it - and yes, there are different VAT rates for different commodities. But also, how many spaces do you leave in reports for the VAT incurred on items - lets say in 3 or 4 years time it goes up to 22% as part of the claw back - have you got enough room to express that on your forms/screens/reports?
I love this stuff.
Then there's the M&S "Teacake"...
http://chris-linfoot.net/d6plinks/CWLT-7DKEPZ
Guys, I see your discussion, and I can say I envy you... In a good way :-)
Here, in Brazil we have 74 (yes, seventy four) taxes, varying from kind of goods (if luxury, etc...) place it was made and place it was consumed!
Ask the SAP guys, why they postponed for one year to release it's SAP Business one here!
So, there's no chance to hardcode them, also it's almost impossible to calculate them!
Anyway, hardcode is a bad habit, but in this particular case, it's easy to fix!
Yes hardcoding is a 'worst practice' if you will. However, sometimes the customer wants you to cut costs at all opportunities and sometimes I may let them make the call depending on the amount of customization needed. Obviously a variable here or there (as in this case) will not make a difference...
@Jake -- hopefully in my reply I didn't come across as rude; that certainly wasn't my intent...
You're using Notes for mathematical calculations? Shock horror!!
@Matt. No. It didn't seem rude to me at all. I just felt the need to defend my professional reputation ;o) Nothing to do with what you said. More to do with the fact all responses seem to confirm that I committed one of the seven deadly sins of development.
Tyron. Anything more advanced than X+(X*0.175) and I'd have thought twice!!
I don't get it -- Jaffa Cakes are a cookie. :P
Though I once had an uncle who claimed them as a necessity, so I guess there's some precedent to their claim.
Anyway -- ha ha! Silly Europeans with your VAT. We Americans don't have to bother with the like.
Now one second, I have to get ready to start my third job to help pay off my medical bills.
If you're trying to figure an easy way to find and fix all those places you hard coded 17.5, you may want to check out Team Studio's Configurator - it's sort of a super 'find and replace' tool. I ran into it some years back when I had to fix a ton of hard coded server names...GREAT short term fix that gives you time to go back and 'soft code' your variable. As far as I'm concerned, the tool paid for itself the first time I used it.
I have no financial interest in the product, just a happy HAPPY customer.
I am prepared to hard code a week having 7 days, a dollar having 100 cents and a few things like that - beyond these I regard everything as being capable of being changed and expect that anything I hard code automatically becomes more likely to change.
Interestingly early versions of Notes had daylight saving dates hard coded to the dates that were used in the US. It made life difficult for those of us who live down under.
However I second the endorsement of Configurator.
As I program Notes applications intended to be managed via the web, I usually make a practice of soft coding variables as often as I can ... even CSS attributes are variables in my systems.
I do this for multiple reasons, but the most important reason is that I don't have the time to change code that relies on a particular setting ... and I don't have a good enough memory to find every spot where I hard coded something.
Additionally, working in the U.S. where each state has its own tax rate ... it just makes more sense to soft code something like this.
As a matter of fact, I use a settings view similar to the ones I've found in CodeStore templates and demos. That being said, I can't tell you how many times I've hard coded the name of a document (in a @DBLookup call etc...) and then had the client open the setting document and change the name thus breaking my code. (Even after I leave a note stating "Don't Touch!")
It just goes to show that you can never really rely on hard coded variables unless the dependent 'string' is off limits to every one and every thing.
(A note for Jake: I submitted this comment from my ThunderBird client, and it didn't seem to take, so I submitted it again from your site. So, if there's 2, it's ThunderBirds fault )