3 ms·

Another possible conclusion: fix this several years from now, the first time it causes a test failure and still probably before it causes any production problem

Another possible conclusion: fix this several years from now, the first time it causes a test failure and still probably before it causes any production problems.

lmm 11y ago
If you have time bugs that only manifest at the DST changeover then everyone knows why your bugs have happened and you look incompetent. I suspect this applies if subscriptions handle leap years poorly too.
- markburns 11y ago
  My point is more that if it costs more to fix it now, than it does to fix it later (including the opportunity cost), then there is little point in fixing an extreme edge case now. Especially if it means having to understand every intricacy of every library you work with and spend a long time thinking of permutations that have little effect on the business. It depends on the situation you are in as to whether that cost calculation works out in your favour. It is not always that is has to always work in 100% of edge cases, all thought about up-front and with no possible bugs arising due to not 100% understanding every line of code in every library. Sometimes it makes more sense to fix a bug that happens every four years when it causes a problem. In this case the bug may manifest itself in a user potentially seeing a day off by one error on a subscription details page. In which case it may never make sense to fix that page. As the user may never look at that page, and even if they did, they may never care.
  - lmm 11y ago
    > Sometimes it makes more sense to fix a bug that happens every four years when it causes a problem. Sometimes yes, but you need to actually perform the risk assessment/cost-benefit analysis. Many bugs are costly enough that it's worth fixing them pre-emptively rather than always waiting for a problem to happen before you do anything about it.

3 ms·

Another possible conclusion: fix this several years from now, the first time it causes a test failure and still probably before it causes any production problem

by markburns 11y ago

Another possible conclusion: fix this several years from now, the first time it causes a test failure and still probably before it causes any production problems.

lmm 11y ago
If you have time bugs that only manifest at the DST changeover then everyone knows why your bugs have happened and you look incompetent. I suspect this applies if subscriptions handle leap years poorly too.
- markburns 11y ago
  My point is more that if it costs more to fix it now, than it does to fix it later (including the opportunity cost), then there is little point in fixing an extreme edge case now. Especially if it means having to understand every intricacy of every library you work with and spend a long time thinking of permutations that have little effect on the business. It depends on the situation you are in as to whether that cost calculation works out in your favour. It is not always that is has to always work in 100% of edge cases, all thought about up-front and with no possible bugs arising due to not 100% understanding every line of code in every library. Sometimes it makes more sense to fix a bug that happens every four years when it causes a problem. In this case the bug may manifest itself in a user potentially seeing a day off by one error on a subscription details page. In which case it may never make sense to fix that page. As the user may never look at that page, and even if they did, they may never care.
  - lmm 11y ago
    > Sometimes it makes more sense to fix a bug that happens every four years when it causes a problem. Sometimes yes, but you need to actually perform the risk assessment/cost-benefit analysis. Many bugs are costly enough that it's worth fixing them pre-emptively rather than always waiting for a problem to happen before you do anything about it.