I'm in IT ops, and I will bet you dollars to donuts that the money saved by putting toilets in every other car was more than wasted by the shunting yard switching cars every which way.
Perhaps, but I dislike that attitude. It's this kind of story that people generalize to justify why change is bad.
"Look at those idiots who tried to cut costs myopically and ended up at a net loss" is a common story, and I've heard it used to kibosh good ideas.
The point of the parable, to me, is that you need to think the whole process through. It's about good, thorough engineering. It is NOT about not trying. People get reflexively pessimistic about improvement ideas, which is a real shame. Perhaps I'm sensitive to it because I've often been the guy trying to change "the way things are done." :-)
That "you need to think the whole process through" is exactly my point. In my experience, administrative overhead is rarely given this kind of consideration, and it results in a lot of wasted effort and upset users - like shunting a bunch of cars around just to even out toilet spacing, when it's simpler to put a toilet in every car and be done with it (especially since the story tells us that the shunting yard is already heavily loaded).
Sometimes this lack of end-to-end attention to a process results in serious mishaps. Let me give you a concrete example - thin provisioning in SANs. It can help you efficiently use your storage, but if no one on staff has time to keep a watchful eye on storage utilization growth rates, you can get into a situation where the SAN fails in a way that's very difficult to fix. If hiring isn't possible and you lack the resources to automate storage monitoring, it's probably better to switch to thick provisioning, even though on paper it's a less efficient use of the SAN. I'd argue that an opaque LUN that goes down because it can't expand is harder to recover than a file system that's full.
Change isn't only good, it's critical to continued success. That said, too many people optimize a process or service prematurely, without a deep understanding of the process or service. This, I think, is why Dijkstra describes how managers get more and more annoyed as the story progresses.
Yes, and I think that's why I like this parable so much. The contrast between the elegance of the solution and the futility of the enterprise as a whole is striking.
