61–70 of 83 posts
Hrm. I was annoyed by the cost-savings idea and at each of the partial fixes, and then reasonably pleased by the solution (but I would have been happier if the root cause was fixed.) So I'm not a manager, and not a programmer... I'm a sysadmin at heart.
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. Peop…
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.
Earlier quoted context omitted.
Not sure. Essentially a new class of 'car' was created, twice as long and roughly twice as expensive. If the cost of dealing with the larger cars was non-zero, then maybe it was break-even. Its premature-optimization at its finest I think.
Assuming the original cost-cutters decision was correct, it isn't twice as expensive.
I have told the above story to different audiences. Programmers, as a rule, are delighted by it, and managers, invariably, get more and more annoyed as the story progresses; true mathematicians, however, fail to see the point. If I may venture an explanation for that, it is that the different groups identify with different people in the story. Managers identify with the cost-cutter. It is a story about the futility a…
I love this parable, but here's the kicker: The company lost money, and probably, to this day, doesn't understand that it did. Certain costs are very visible to business leadership. Like the costs of toilets. Others, not so much. Like the time lost in the shunting yard farting around with the cars. Or the costs of people that used someone else's train service because they were pissed at not finding a toilet. Business…
> All other things being equal, how you manage ______ is how you beat your competition. What a spectacular tautology. But, yes, you are right. More importantly: It's an easy place to win or lose dollars.
Thanks for the backhanded compliment, but no, how you manage hidden 'soft' costs is how you beat your competition.
Extending that to be "value x" is simply a race to the bottom. Measuring (and reducing) costs that other people also have but don't realize is the kicker.
For example: Understanding the cost difference between client acquisition and client turnover. Everyone focuses on growth, but in reality it's often cheaper to retain a client - even if you do things like give your product away - than it is to lose them and add a new one. (Which can often looks better on the surface).
Another one: Firing bad customers. Telling a customer that pays you a large sum that you aren't interested in the relationship anymore looks bad on your bottom line. Recognizing that you were actually putting 120% more money into servicing them than they were paying (or even worse, recognizing that those services are out of your preferred scope) is what puts you ahead of the game overall. You don't see that on any report though, at least not right away.
I have told the above story to different audiences. Programmers, as a rule, are delighted by it, and managers, invariably, get more and more annoyed as the story progresses; true mathematicians, however, fail to see the point. If I may venture an explanation for that, it is that the different groups identify with different people in the story. Managers identify with the cost-cutter. It is a story about the futility a…
For a mathematician, the problem would be much more interesting if it began "consider a train of infinite length in n dimensions", laid out requirements for spacing of m different amenities contained in disjoint cars, and ended with theorems about optimal construction of minimum-sized tiles.
Ironically, this kind of "cost-savings" is exactly what the Netherlands railways have been doing over the years (only by closing half the existing toilets). However, they ended up with the ultimate solution: ordering new trains without any toilets . No joke, they even came up with the brilliant idea of handing out plastic bags for "emergencies"...
It may be a symptom of my own possibly-pathological preference for reusable modular design, but I'd want to make tiny toilet-only cars. Borrowing anonymouz's diagram style: +---------------+ +-+ +---------------+ | | |T| | | +---------------+.+-+.+---------------+ O O O O O O Then all carriage-cars and toilet-cars are… • reversible • interchangeable with others of their type • easily externally identifiable at shunti…
Because your solution needs more CS thinking. Your carriage cars are not reversible when used in any ratio other than 1:1 because they need an arrow inside to point to the nearest toilet-car. Also, in odd-numbered ratios (3:1, 5:1), you would really need a car with arrows going both ways, starting from the middle of the carriage. Or maybe you are selling a programmable LCD arrow signage for the carriages...
There is also one issue with Dijstra's parable: although the new coupling solution doesn't require ever turning carriages around (as long as they are shunted as pairs), it also means carriages cannot be turned around without extra effort. Assuming the turning platforms can only take one carriage, you have a lot of extra work to turn around a pair and get them back together correctly. However, there are track configurations that can turn the paired cars around more easily. In any case, this probably explains why all trains have seats facing both directions: they never need to turn them.
It may be a symptom of my own possibly-pathological preference for reusable modular design, but I'd want to make tiny toilet-only cars. Borrowing anonymouz's diagram style: +---------------+ +-+ +---------------+ | | |T| | | +---------------+.+-+.+---------------+ O O O O O O Then all carriage-cars and toilet-cars are… • reversible • interchangeable with others of their type • easily externally identifiable at shunti…
I was at first going to wonder if HN is going to recycle all of CS history, and whether that was a good thing or not. Now I see it may be necessary. Because your solution needs more CS thinking. Your carriage cars are not reversible when used in any ratio other than 1:1 because they need an arrow inside to point to the nearest toilet-car. Also, in odd-numbered ratios (3:1, 5:1), you would really need a car with arrow…