A Computer Upgrade Shut Down Bart

In the days before systems existed for publishing such schedules and emergency alerts, should public transit service not have been attempted at all?

> Trains by definition need to share the same tracks with catastrophic consequences for getting it wrong.

Just because it uses the same rail gauge as intercity freight doesn't require it to run on the same set of tracks. But if it did, I assume "local-first" entails other traffic just being excluded when an emergency in the local system necessitates it.

Modernization efforts focus on trains broadcasting position and speed so trains can travel closer together and still maintain a safe stopping distance, but that's again possible locally.

Operating switches is where it gets trickier. Some rail operators maintain the possibility to operate them locally, but that requires either stopping the train at each switch you want to change, or to deploy lots of people into the field to do it on schedule

If air traffic control can fall back to pen and paper in a pinch, I think it would be cool IF trains had a decent fallback. ;-)

Not saying SF politics is great, but at least point to the correct boogeyman.

Addition of the last phrase had truly the worst impact; Drumpf meme was not well-timed/placed

"Deploy on every commit" lmao

"Shipping software and running tests should be fast. Super fast. Minutes, tops." hahah

For "read only friday" to have been a novel idea in the first place, you needed a starting point where conventional practice already was making changes live without stopping to consider the time/day of week.

I really suspect the detractors represent a workflow that would break (or at least introduce pain) if unable to push to production for a few days. So they have to give the hard sell on the benefits of continuous deployment.

As an engineer I have absolutely no issue deploying on a friday. But friday bar starts at 4pm, and after that I am not sober before monday.

So leadership don't want me to do it - which is probably wise.

I've found that little things like that breed a growing resentment and stress that compounds, until someone wants to leave the company. Thursday night outage that I have to hop on? Much smaller deal than a weekend where I have established plans.

One can argue "why was the PR approved in the first place", but sometimes people make mistakes. It especially sucks when there are limited people that know how to troubleshoot and resolve the production issues with a system, even more so when the on-call individual may have not even reviewed the code initially.

All that said - I'd love to deploy as normal on Fridays! I've just found that the type of businesses I've worked at can wait until Monday, and that makes our weekends less risky.

The idea the author seems to be advocating for is is that, while maybe you sometimes/often shouldn't deploy on a Friday (or even not at the very end of any workday), there should never be a stated policy in place that freezes deployments.

And yeah, I've been at places where they have freezes on weekends, holidays, right around the company's conference, etc. But they're never 100% freezes: if something goes wrong or is necessary, you just get a manager to approve it, and off you go.

I think the author's exhortation that developers should all be able to exercise their judgment to make these calls is a nice idea in theory, but falls flat in practice. Every developer will not always have all the necessary context in order to exercise that judgment. Even those who do, and generally have good judgment, will screw up sometimes because they are tired or are working under some sort of time pressure, or something.

Having a policy -- with some flexibility and exceptions allowed -- makes it easier to avoid those sorts of lapses in judgment. And that's a good thing.

But the whole article is just all over the place to me. The author starts by implying that people should be "ashamed" about identifying with a no-Friday-deploy policy, but then softens to the point of saying it's fine to have a personal policy of no late-afternoon deploys, no shipping big changes right before the weekend, etc. But that somehow if that's instead company policy, that's a bad thing. Nope, I don't buy it.

It is a microcosm, a bit of a litmus test, and an ideological battlefield of the embattled sides. But this example specifically is also a kind of infighting, of the more anarcho-libertarian tech camp that enjoys highlighting and dripping with self-righteousness about any tech related failure of government, i.e., or at least government that does not align with their ideology or control over it.

This fault line of America runs right through things like BART like an effigy or idol that America performs a kind of ritual form of battle on as proxies for all out civil war. Think of tribes you may have seen videos of where they do all kinds of elaborate dances and blustering displays and fake charges to demonstrate their power.

The glee about this outage happening to BART is very much because the libertarian tech progressive types are amused and validated by it, where something more like rashes of violent attacks on BART riders by menaces to society might be something that the "heartland" may become gleeful about, as evidence for how the ideology of SF is messed up. In the cases of violent attacks on BART riders, another camp/tribe would come out and demonstrate their fierceness; the "socially liberal" types from all over the country and even world, would rush to the defense of their ideological idols with a bewildering storm of rationalization, delusion, and excuse making for violent attackers and in defense of their ideology/cult.

It's just elaborate war dances around an idol/ideology to demonstrate how fierce and powerful each party is. BART is just one of the idols in America around which these displays of simulated conflicts happen.

The larger engineering lesson from that is you're probably better off making standard solutions work for your situation than custom solutions. The wider gauge solved(?) the stability problem, but at the cost of always needing custom rolling stock, but more importantly, making Bart build-out significantly more expensive and unable to take advantage of existing track. That hurts the viability of the Bart ecosystem.

Costs are an America issue, not a BART issue: https://transitcosts.com/new-data/

BART is one of the most cost efficient systems in the US: https://www.reddit.com/r/transit/comments/1d27dvo/us_cost_pe.... It's so efficient that pre-pandemic it got the majority of its funding through fares, not taxes.

By the way it costs exorbitant amounts to build highways too and you don't see people criticizing all of our highways around the area do you.

So quite frankly you don't know what you're talking about.

I would think increased ridership means increased efficiency.

Jokes aside, I'd like to see a stack ranking of US public transit. I'd assume NYC and DC are top dogs, but I'm curious about other cities.

It even has direct service from two metro lines to the airport.