Some more historical research here:
https://www.kalw.org/show/crosscurrents/2016-07-05/hey-area-...
Seems highly likely that keeping freight trains off the tracks also factored into the decision. Huge shame that they didn't consider the ongoing maintenance cost of using a non-standard gauge.
Don't know what NIH syndrome has to do with it, doesn't sound like interoperating with other rail systems was in the spec.
They also entered busmaking at this time and produced the Flxible 870, a notorious lemon of a bus.
Standard gauge was ubiquitous in the US at the time, and this engineering firm didn’t even evaluate it in their report, despite the fact that the original BART plans called for standard gauge. Stability of standard gauge has since been proven to be a complete non-issue.
If you read more about the history of BART, everything about it was NIH. They thought they were going to design some new space-age standard and usher in a new era of public transportation.
Truly, help me understand how to better navigate when to defer and when to have the courage to invent here.
In the case of trains they could be a lot cheaper if everyone agreed one one standard and only made changes when everyone agrees to upgrade at once (over 40 years counts as at once,so long as there is agreement). All the different standards mean manufactures have to have more expensive jigs, and also cannot optimize their lines as much.
Though wheel gauge within limits that Bart fits is not too big a deal to adjust on a line.
Not really any ideal solution here, if the standard isn't suitable, you need something nonstandard.
BART has actually built or planned to build standard gauge since then to reduce costs on future extensions. Some extensions, like BART absorbing Caltrain to go to San Jose, have failed due to the cost.
Then again, the original choice to use the broader TTC gauge was also petty political.
The point is, it's not an economic or technical decision.
Now imagine that Metrolinx's GO trains also used a non-standard gauge? Not only could they not share track with freight trains, or even Via Rail, but simply delivering the train cars from where they are manufactured in Thunder Bay would be a nightmare. As it is, they're just attached to a freight train and pulled along like any other car, and I've even seen them on a CP freight train.
Standards also mean you can buy standard parts instead of getting something custom made. This can greatly reduce costs as mass manufacturing is only cheap when there is a mass needed. (At least Bart choose a guage in use elsewhere so there is some demand for those parts).
Standard means CA HSR or Caltrain could share less used track which can save everyone money. (It makes scheduling hard, but that is a lot cheaper than building track) who knows, maybe freight rail would use that track for some low demand customers they can't serve at all now, and trains are more environmentally friendly than trucks.
If you invent a competitor to microSD that somehow stores 50% more data in the same space(For example only, just ignore the fact that form factor is independent of the flash storage tech), I would be annoyed.
If you push to make it the global standard and succeed, I'll still be annoyed but appreciate the progress.
If you just make a line of devices with unique storage, I'll probably be like, yeah, but MicroSD was fine and this doesn't work with my readers, and now I have to buy a new card.
In software NIH often doesn't offer much benefit at all. It's usually just "We want to build it ourselves and really understand it". Sometimes features are even worse("We don't need to support importing those formats, build something smaller that only support one"). Sometimes performance is worse ("Who needs a million line library with crazy vector instructions? 5 lines of C will do").
Progress involves making the best changes we can. NIH syndrome means re-litigating small changes that aren't impactful rather than focusing on the new big ticket items that will really make a difference.
What's the point in optimizing something that will have a negligible return when there are better opportunities? And there's also the important downside of NIH syndrome. It might just be that the people who solved the problem initially knew what they were doing and you'll discover years down the road that your solution doesn't help anyone make progress, it was actually a terrible mistake.
Like the BART solution. The people who did this were aerospace engineers. They thought they were improving on train design. Well, they were not. They were ignoring important constraints you only learn about later: the fact that interoperability between train tracks is critical to long-term development and efficient operation. Extending BART is a nightmare, it cannot share track with other systems, you cannot move trains on other systems to get them to BART which makes it far more expensive to do anything, the parts are incredibly expensive now that the supply chain for them is tiny.
Basically every commuter suffers every day because of this idiotic decision which keeps the system fragmented.
And that's what NIH syndrome gets you. You think you're making progress. But you often just have a terrible understanding of the problem and you're building yourself long-term technical debt.
Arguments like "the best code is no code" basically allude to the idea of defining the problem in a way that allows a solution without addressing it through some complex technical dependency.
In transportation there is a lot of popular discussion based around different modalities like car, train, bike. Each one has its enthusiasts arguing for a mode being a solution. This is a very engaging topic because it creates the grounds for an ideology: "everything will be great once we eliminate x and build more y". A great way of addressing transport issues while not discussing the overall problem in terms of land use, tripmaking needs, accessibility, safety, etc. The path to the actual solution is through studying all those other things to identify what key metrics are in play and then specifying your solution in terms of "must meet this metric". That's where the meat of any problem lies, because the person who lays down the finishing touches is building on all that preparatory work - supply chains, scientific principles, engineering tolerances and so on.
And, of course, there's another path into addressing without solving by selecting unrealistic metrics that don't suggest how to move forward. Before you even have the metrics you need good critical thinking skills, ability to collect and analyze data, and some resulting media that communicates the findings like a document. That's a whole job in itself, and then selling and marketing it is another. And then maybe we get to actually implementing something.
It takes a lot, in all. It's almost imperceptible how we progress on big issues. And the whole way through someone is trying to steal credit for some part of it.