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.

Why the general incompetency added on?

Ad the other commenter wrote: The 25% is assumed - this has nothing to do with competence but to what level an assumption is true.

Everybody can point fingers at 25 year old code and call the developers incompetent because surrounding requirements have changed.

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 is not a compile-time value. It's a runtime value. Nevermind not scattering it in your code, it shouldn't be in your code at all.

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.

The US is used to this as the rate changes between states and product categories - it is not reasonable to adopt this view onto other VAT systems.

You can not transfer categorical statements like you do.

> and call the developers incompetent

Why would you blame developers for this?

This is management problem!

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.

During the financial crisis, Ireland added half a percent to VAT. Wanna guess what happened?

(The funny thing is, the _reduced_ rate had been 13.5% for years, but a non-integer rate for the main rate _still_ caused widespread IT problems...)