3 ms·

Insane that technical debt and general incompetency in software can produce such unexpected side effects.

tossandthrow 1y ago
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.
- pmontra 1y ago
  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.
  - deleted 1y ago
    [deleted]
  - bruce511 1y ago
    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.
    - Ekaros 1y ago
      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.
      - tossandthrow 1y ago
        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.
  - kqr 1y ago
    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.
- throw748848485 1y ago
  > and call the developers incompetent Why would you blame developers for this? This is management problem!
hvb2 1y ago
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.
geysersam 1y ago
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.
rsynnott 1y ago
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...)

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.

pmontra 1y ago
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.
- deleted 1y ago
  [deleted]
- bruce511 1y ago
  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.
  - Ekaros 1y ago
    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.
    - tossandthrow 1y ago
      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.
- kqr 1y ago
  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.
throw748848485 1y ago
> and call the developers incompetent Why would you blame developers for this? This is management problem!

hvb2 1y ago

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.

geysersam 1y ago

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.

rsynnott 1y ago

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...)