6 ms·

If you cannot achieve correct without simple, redefine correct.

by Sir_Cmpwn 8y ago

rhapsodic 8y ago
> If you cannot achieve correct without simple, redefine correct. More hand-waving.
- Sir_Cmpwn 8y ago
  I disagree. I just can't get more specific without specific cases to examine. Like others have pointed out, take the matter of timezones: if "correct" is defined as "handling timezones", you should instead store time in UTC everywhere and redefine "correct" to be "convert times to local time when displayed and back again when input", which can be accomplished with much smaller, simpler, and focused tools.
  - jasode 8y ago
    >", you should instead store time in UTC everywhere It is not possible to store UTC unambiguously on the db server for all future local wall-clock times. (Previous comment about the erroneous assumption of "UTC everywhere" being a "simple solution".[1]) Therefore, redefining "correct" to be "store UTC everywhere" achieves the exact opposite: an incorrect and buggy program. That's because the "universal" in Universal Time Code doesn't apply to governments changing DST and Time Zone rules in the future. Pure UTC doesn't have enough metadata to encode future unknowns. For correct handling with zero loss of data, one must store the user's intended "wall-clock" time in his local TZ in the db. There's irreducible complexity when dealing with user-specified appointment times so an uncompromising fixation on programming a "simple" implementation with pure UTC-on-dbserver and localtime-at-only-at-browser-Javascript ... will lead to a broken calendaring program. [1] https://news.ycombinator.com/item?id=10990240 https://news.ycombinator.com/item?id=10990240
    - Sir_Cmpwn 8y ago
      You're right, future times are more complex and might require more attention to detail. But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules.
      - masklinn 8y ago
        > But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules. Congratulation, your emotional refusal to deal with zoned datetimes has led you to a non-standard ad-hoc reinvention of timezones, your misguided quest for simplicity and obstinate rejection of reality has thus led you to a system which is definitely more complex, probably less correct and likely less performant than if you'd just done the right thing in the first place.
      - jasode 8y ago
        >a simple way, [...] and running a script to update future dates I've commented previously that it's not a good idea to change the rows of UTC times in the database.[1] Designing "system correctness" to depend on on the reliability of a correctly written SQL statements completing atomic transactions for millions of rows is not a good idea. In addition to batch db updates of UTC being extremely fragile, it's also not simple. (It's fascinating to note that the multiple programmers independently arrive at the approach to update database rows of UTC times. There's something about it that's cognitively satisfying that attracts repeated reinvention.) [1] https://news.ycombinator.com/item?id=10991894 https://news.ycombinator.com/item?id=10991894
        Sir_Cmpwn 8y ago
        The event's time has changed, though. The local representation of when it will occur has not changed, but if you set a timer today and they change their timezone tomorrow, the timer will expire at the wrong time. We should store the actual time of an event and update it when the scheduled time changes.
  - rhapsodic 8y ago
    >I disagree. I just can't get more specific without specific cases to examine. You should probably mention somewhere that you're the author of the blog post under discussion. And it looks like you're going to make a reputation for yourself as the guy who argues that it's more important for software to be simple than for it to function correctly. Good luck with that.
- jstimpfle 8y ago
  "redefine correct" = "find a better version of the problem". Software development starts with requirements analysis.
JoeAltmaier 8y ago
Some problems are just hard and complicated. You can try to make code that dissects it into lots of simpler pieces, but then they have to be put together in a complicated way. Someplace in the code there will be some point of irreducible complexity. In my experience.
- ythn 8y ago
  In my experience you need a paradigm shift then. If your earth centric approach is creating a need for epicycles of complex code, then you need to paradigm shift to heliocentric which eliminates the epicycles and replaces them with a simple elliptical model.
- AnIdiotOnTheNet 8y ago
  I'm willing to believe that there are sometimes problems that are inherently complex, but I find that much of the time the problem is complex only because you've insisted it be complex. If you take a step back and re-examine the problem you often see that redefining the problem makes everything much more simple.
jpalomaki 8y ago
Having software people interact directly with the user/customer (internal or external) can be very useful because minor changes in requirements can make a huge difference in implementation complexity.

If you cannot achieve correct without simple, redefine correct.

rhapsodic 8y ago

> If you cannot achieve correct without simple, redefine correct. More hand-waving.

Sir_Cmpwn 8y ago
I disagree. I just can't get more specific without specific cases to examine. Like others have pointed out, take the matter of timezones: if "correct" is defined as "handling timezones", you should instead store time in UTC everywhere and redefine "correct" to be "convert times to local time when displayed and back again when input", which can be accomplished with much smaller, simpler, and focused tools.
- jasode 8y ago
  >", you should instead store time in UTC everywhere It is not possible to store UTC unambiguously on the db server for all future local wall-clock times. (Previous comment about the erroneous assumption of "UTC everywhere" being a "simple solution".[1]) Therefore, redefining "correct" to be "store UTC everywhere" achieves the exact opposite: an incorrect and buggy program. That's because the "universal" in Universal Time Code doesn't apply to governments changing DST and Time Zone rules in the future. Pure UTC doesn't have enough metadata to encode future unknowns. For correct handling with zero loss of data, one must store the user's intended "wall-clock" time in his local TZ in the db. There's irreducible complexity when dealing with user-specified appointment times so an uncompromising fixation on programming a "simple" implementation with pure UTC-on-dbserver and localtime-at-only-at-browser-Javascript ... will lead to a broken calendaring program. [1] https://news.ycombinator.com/item?id=10990240 https://news.ycombinator.com/item?id=10990240
  - Sir_Cmpwn 8y ago
    You're right, future times are more complex and might require more attention to detail. But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules.
    - masklinn 8y ago
      > But I think you can still achieve the requirements in a simple way, perhaps by storing it as UTC + lat/long and running a script to update future dates when someone changes their rules. Congratulation, your emotional refusal to deal with zoned datetimes has led you to a non-standard ad-hoc reinvention of timezones, your misguided quest for simplicity and obstinate rejection of reality has thus led you to a system which is definitely more complex, probably less correct and likely less performant than if you'd just done the right thing in the first place.
    - jasode 8y ago
      >a simple way, [...] and running a script to update future dates I've commented previously that it's not a good idea to change the rows of UTC times in the database.[1] Designing "system correctness" to depend on on the reliability of a correctly written SQL statements completing atomic transactions for millions of rows is not a good idea. In addition to batch db updates of UTC being extremely fragile, it's also not simple. (It's fascinating to note that the multiple programmers independently arrive at the approach to update database rows of UTC times. There's something about it that's cognitively satisfying that attracts repeated reinvention.) [1] https://news.ycombinator.com/item?id=10991894 https://news.ycombinator.com/item?id=10991894
      - Sir_Cmpwn 8y ago
        The event's time has changed, though. The local representation of when it will occur has not changed, but if you set a timer today and they change their timezone tomorrow, the timer will expire at the wrong time. We should store the actual time of an event and update it when the scheduled time changes.
- rhapsodic 8y ago
  >I disagree. I just can't get more specific without specific cases to examine. You should probably mention somewhere that you're the author of the blog post under discussion. And it looks like you're going to make a reputation for yourself as the guy who argues that it's more important for software to be simple than for it to function correctly. Good luck with that.
jstimpfle 8y ago
"redefine correct" = "find a better version of the problem". Software development starts with requirements analysis.

JoeAltmaier 8y ago

Some problems are just hard and complicated. You can try to make code that dissects it into lots of simpler pieces, but then they have to be put together in a complicated way. Someplace in the code there will be some point of irreducible complexity. In my experience.

ythn 8y ago
In my experience you need a paradigm shift then. If your earth centric approach is creating a need for epicycles of complex code, then you need to paradigm shift to heliocentric which eliminates the epicycles and replaces them with a simple elliptical model.
AnIdiotOnTheNet 8y ago
I'm willing to believe that there are sometimes problems that are inherently complex, but I find that much of the time the problem is complex only because you've insisted it be complex. If you take a step back and re-examine the problem you often see that redefining the problem makes everything much more simple.

jpalomaki 8y ago

Having software people interact directly with the user/customer (internal or external) can be very useful because minor changes in requirements can make a huge difference in implementation complexity.