Comment by busterarm
18 hours ago
> Bike shedding means no decision is made. That is the worst possible outcome as it provides absolutely zero value.
And "bike shedding" is now a term that people hyperbolically apply to any discussion of something the labelling-participant doesn't really care about. A lot of times doing nothing is actually the best business outcome. Waiting until you have more, better information is great.
Lots of stakeholders ask for things that they think matter and then realize two weeks later doesn't and a ton of man hours have already been spent trying to build those skateboards as fast as possible.
> Even the timezone example isn’t really that material IMO. Sure, it’s an extra annoyance to normalize timestamps to locale in every app/debugging query. But in the end it’s just not that big of a deal.
Oh god are you underestimating the long term impact of data not being stored in UTC. For one, it will be a perfectly reasonable thing that your engineers forget this fact and build new systems in UTC, because that's the reasonable thing to do. Also as the years go on your company will make acquisitions of other companies and whatever timezones their data is stored in (hopefully UTC but obviously not always). To properly integrate this data you have to determine for every timestamp whether there was Daylight Savings Time happening at the time on every single object. You also have to figure out all kinds of edge cases around leap seconds.
Otherwise you have a ton of data that's out of chronology. Pity you if that's a thing that matters to you (it almost certainly does).
Also maybe you're lucky enough to be in a position to modify timestamps of all of your objects in all your datastores without significant engineering effort and coordination...but probably not. Obviously the reason the company I mentioned hasn't done it is because they're in that position...
But say you don't want to "fix it" and just want to do this "on every query"...now this process above is something you have to do across maybe thousands of services for potentially every request...
No big deal, he says...
Well you shifted the goal posts. Storing everything in EST vs UTC isn’t great, but isn’t some business ending level problem. It annoys engineers and causes inefficiency. Unlikely to even show up on a quarterly report if someone chose to write a mandate to fix it.
Once you get to the point of bolting on random systems that need to talk in whatever time zones is when you bite the bullet and change it. Yes, that is expensive.
The point I’m making is that if you spend a week dicking around with two junior devs while in your startup phase arguing about EST vs UTC you lose by default. Would much rather have my imaginary employee just choose EST in 14 seconds and move on at that stage. And I have dealt with systems that have done exactly this.
When it becomes a problem I can afford to fix it. Talking about it for more than 5 minutes at the bootstrap company stage is the definition of bike shedding to me. If those are discussions you are having in your weekly dev meetings you have already lost.
This will obviously depend on exactly what you are developing. Payment systems? Probably way more important to get this right vs. some social media app.
The ironic part to me is that this comment thread is basically bike shedding itself! Timestamps are an age old nerd snipe.