That general incompetency you're referring to there can also be worded as
For years they didn't build unneeded complexity. And it sounds like for many more years to come. So they're just efficient. Any developer will have had to make things configurable afterwards, that's fine, just evolution of code.
Hard coding also means that it's less likely to break. No customer (in Denmark) can influence this, so why make it configurable?
Over time this does become a problem when source code is lost/companies go under.
Considering that's 25 year old code I'd expect at least a
#define VAT 0.25
and not hardcoded values all around the source code. However I don't expect a table (db table, array, etc) of product categories with their own VAT code or a user defined exception list. That extra code would inevitably add bugs that are not worth the trouble. Adding an exception for books probably requires an update of the apps.
Such a constant would be no better -- they don't want to change the VAT rate across all product types.
The code missing is that for per-product type variation in VAT rate, which sounds complicated enough that Iawould expect a good engineer to shrug and say YAGNI until it's actually necessary.
VAT rate can and does change. As such it can be different on different dates. And this change might not even correspond to change of year. So it really has no place in code.
So if the House introduced a 'fixed' VAT tomorrow, say $1, not proportional to the price of the product, would that not break most software used to compute VATs?
We have to make assumptions.
Good software doesn't account for every future possiblity, but it is easy to change when the requirements change.
