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, a

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.