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 and difficulty of doing their jobs, particularly in the midst of unpredictable technical problems. Above all, it is about engineers' failure to just get things right the first time. It is a tragedy.
Engineers identify with the shunting-yard folks and especially with the final brilliant solution. It is a heroic story, a story about succeeding against unreasonable demands, dominating an unkind and unfair world with a simple idea.
Mathematicians identify with no one in the story. It is a mundane story about an uninteresting and unnecessary practical problem, self-inflicted and then solved in an elementary way. The problem is not general, the solution is not interesting, and no one in the story is very smart.
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.
I wonder. And I'm curious what other readers think Dijkstra meant by that.
I think, as far as the part about mathematicians goes, that the point is that once the problem is stated sufficiently abstractly and sufficiently precisely, there is no problem.
Forget all the nonsense about trains and toilets and rail yards and whatnot. You start with a single linear, symmetric object, and you don't have a problem. Then you break it into two sub-objects, one of them asymmetric ...
|-T-| = |-| + |T-|
... and now you have a problem. If you want the problem to go away, just un-break apart the pieces. QED.
(As Dewey said, "A problem well posed is half-solved." And sometimes doesn't even exist.)
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 shunting yards
• able to represent either the original 1:1 carriage:toilet ratio, or the cost-saving 2:1 ratio, or any other ratio that might be desired
• able to represent any desired min-distance/max-distance in carriage-car-lengths to the nearest toilet
• able to be upgraded/serviced independently (including occasional periods of operation outside of usual ratios, as trials or when cars are out-of-service)
Of course the costs of extra couplings (in construction, linear deadspace, and operational overhead), and effects of such unevenly-sized cars on travel characteristics (stability, wear, fuel-economy, etc) might outweigh the explicit flexibility benefits.
But such flexibility is less risky in the abstract and more easily-rewritten world of software where I practice, as opposed to the world of railroad engineering, as practiced (perhaps not coincidentally) by my father's father.
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 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.
Gojomo's design could use windows instead of arrows, so that the toilet car's external signage can be seen from anywhere in the adjacent car's hall. At a 1:1 or 2:1 ratio, a passenger just has to look both directions and go toward the sign they see. At a 3:1 ratio, a passenger who doesn't see a toilet car out of either window could always walk to the door closest to them.
Then the cars to each end of the toilet car would still exist in two types, depending of the direction of the arrows; which means you have 3 different units instead of 1. Reduce conditionals, reduce cache misses! ^^
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, on a whole, is great at optimizing those visible costs, but only the good companies are good at managing those soft costs. All other things being equal, how you manage those soft costs is how you beat your competition.
how you manage ______ is how you beat your competition.
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.
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"...
Correct! Here's an image of the so called 'Travel John' http://bit.ly/Vs9W2G (Google Images). There is still a bit of a problem for the ladies or 'number 2'.
As far as I remember from the news, each toilet in the NS trains costs more than €1 million, which is why they decided not to install any. Perhaps they should fix that number, instead of removing the toilets altogether. Note that a train toilet is nothing special, the waste disposal is just an open pipe to the bottom of the train.
I would think they took into account cleaning (multiple times per day), maintenance, vandalism and loss of seating to come up with that number.
Especially the latter, since this isn't the first time they've done something insane for a few extra seats.
Putting the air intakes at the bottom of new trains (instead of on top as was the original manufacturers design) comes to mind, which lead to dozens of trains becoming unusable and needing weeks of repairs after a bit of snowfall...
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 saw the solution immediately, to be honest. Of course, my mother has worked for a railroad since before I was born, so maybe I had an unfair advantage...
We all know most changes result in assumed consequences and unforeseen consequences. Especially if you mess with the most basic human functions ; )
The planner in me therefore would have liked to see a bit more planning upfront, less knee jerk reaction to each issue, and more consideration to the costs to the org as a whole of each change...
Except that you now effectively have cars that are twice as long and articulated in the middle. If one half of the double-car is damaged, both have to be taken in for repair, and both have to be transported and handled as a unit.
Presumably, the previous single-car size had already been optimized for pre-toilet criteria, and changing that by a factor of two probably massively screws with at least some of those criteria. It's hard to believe that the costs savings for having half as many toilets significantly outweigh those other factors.
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.
Yes, but there is half the number of cars in each train, so the doublings cancel out. That said, the overhead of larger cars could still be a significant factor.
Absent from the story is any mention of cost-benefit analysis. I'd agree with the unnamed director's decision to eliminate every other toilet if there was evidence that, in the long run, it actually did cost the railroad less.
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.
Wouldn't it be cheaper to just install the bloody toilets in every train car? Than every car could be everywhere. After all it's just a toilet with a hole.
No, it would have cost the same. That was, to me, the point of the parable. The initial cost savings was absorbed by the cost of purchasing the additional cars necessary to implement the N/2 fix.
One penny pinching solution, improperly evaluated, pissed off customers, made the company less efficient (man hours working on a previously smooth process), and resulted in a direct capital expense.
Same problem as with airlines-- a toilet would probably remove 4-6 paying passenger seats, which means less money. Toilets don't generate revenue whereas seats keep paying for themselves many times over.
I think there is more to train toilets than that. You need somewhere for the wast to go, and waste disposal, cleaning, maintenance, stocking all have to be done on a regular basis.
It's a parable, not a real world situation. It's meant to illustrate how an appropriate abstraction can remove complexity from a problem as requirement get piled on.
To me the point of the parable (apart from clever programming) seems to be that for a successful venture you need to have competent people on all fronts, managers and engineers, good communication between teams and listen to your clients.
The manager did a good job to find a way to cut down the costs but didn't get the specifications right so the engineers, although they could deal with the issue, didn't even know that an issue existed.
I guess in the day, they didn't have UX designers.
As for the article's point, it probably is nor managers, nor engineers, nor mathematicians really get the point of the parable.
In these sort of parables I tend to agree with W Edwards Deming in that the root of most problems is the managers. The goal should be to reduce variability in the process. Not being able to see any data I would guess that most of the variability in the data would be with the shunting.
Hmm, I read it at least partly as a riff on the idea of composition: the day is won by designing components with desirable properties out of lesser components which lack them. The parallel to programming seems obvious.
Given that the article was written by Dijkstra, your interpretation is probably closer to the truth than mine.
I wonder though if this lesson has the same value nowadays as it had on its day. Maybe it is because of such lessons that this design procedure is common today.
I'm an economist and saw a story about innovation. An arbitrage was identified and, after some searching, a mechanism found to exploit it. The process was messy, but resulted in a system which increased profitability (or lowered ticket prices or freed up capital to make the chairs comfier) by more efficiently allocating limited resources (note that none of the complaints were about lines outside the toilet) through the deployment of technology.
I'm a bit surprised to see that nobody has mentioned that this is a very common configuration in the real world, cars linked this way ("coupled, from now until eternity") are called married pairs, or twin units:
http://en.wikipedia.org/wiki/Married_pair
They're falling out of favor on New York's MTA system, but Chicago's newest 5000-series cars are still configured in married pairs.
Hypothetically, with married pairs you never need to turn cars around, each unit is independently functional, and the number of many expensive components is reduced by half. Quite elegant, if you ask me.
Romantically(?) divorce among married pairs is rare, and in the case of Chicago, fan-sites document the handful of mis-matched cars.
On at least one part of the MTA system, the Long Island Rail Road, all the cars are in permanently coupled pairs and have toilets in the odd-numbered cars only. And indeed, they're never turned around: the odd numbered car is always at the west end of the pair.
a) the solution assumes you can put two cars on a turntable... can you?
b) couldn't the solution have been to just manually move the TOILET sign on the toilet-less cars as appropriate?
Finally the real take-away here is that cost-cutting always has external costs that are seldom thought of, and especially when they harm the product experience, should definitely be re-evaluated :)
edit: I realize I was wrong, you don't need to ever put pairs on a turn-table as long as you keep them paired correctly.
This reminds me of the oft-considered notion of pre-rotating airplane tires on landing to reduce wear. It seems like a good idea on paper, but ultimately it just complicates aircraft design and it's cheaper to just replace the tires.
The take away I got from the article is that complication in a requirement multiplies many times in the rest of the business process. The KISS principle is not just for developers. It's more so for the business people. Having simple business models, requirements, and features directly translated into ease of implementation, simpler operation, and more satisfying service. And lower cost, too.
You always keep pairs of carriages, connected like this:
+----------------+ +---------------+
| T| | |
+----------------+ +---------------+
O O O O
where 'T' marks a toilet. You build your train from a bunch of those cars, and now it does not matter how you connect them, you'll always have a toilet within a car's range, plus at worst the additional cost of crossing into the next car (since you can't put the toilet between two cars, there's a slight asymmetry).
Two cars were coupled together correctly (i.e. car with toilet coupled on toilet end to a car without a toilet), and then never decoupled. Each two car couple was then treated as a single unit.
Turntables? Those usually only get used when something (like an engine or motor unit) needs to be turned around. Many motor units that I see can operate just as well without turning around; some have cabins at both ends, or are in mated pair configurations with a "backwards" facing motor unit. Most carriages (that I see on a regular basis) have either half the seats facing one way, and half the other, or are reversible.
Regular switching track suffices to switch which end of a train a motor units runs on, and some smaller passenger trains can work fine in "push" instead of "pull" mode.
Second of all this does delight me. I feel like I deal with this on a daily basis with scope creep in my projects.
On one end of the spectrum you can have an over-engineered project and take forever to get to a requirements decision only to keep kicking down a bad requirement down the chain due to the investment involved.
On the other end you have little to no requirements and you keep discovering new requirements all the time. Scope creep can get ugly here.
Alternatively, the company could place the toilets in the middle of each car rather than on an end. NB: This solution may be hard to implement once the train cars have been designed/procured.
Me too. It's obvious that the two permanently coupled cars are really just one big car with a toilet, and it's obvious from the start that they should just have put a toilet in every car. But that's too easy to be the point, I suppose?
Maybe it is a parable against yet another workaround?
USSR electric trains have a similar design feature: it consists of two kinds of cars, one has pantograph and the other has some other equipment which makes it hum when it stands still on the station.
And they're always interleaved like this: chphphphphc
(c - car with a cabin, p - car with pantograph, h - hummy car)
I wonder if it ever caused logistical problems when assembling trains from cars. Probably not since they are visually different and not sensitive to flipping.
P. S. And toilets? You only had two - one in each cabin cars.
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 and difficulty of doing their jobs, particularly in the midst of unpredictable technical problems. Above all, it is about engineers' failure to just get things right the first time. It is a tragedy.
Engineers identify with the shunting-yard folks and especially with the final brilliant solution. It is a heroic story, a story about succeeding against unreasonable demands, dominating an unkind and unfair world with a simple idea.
Mathematicians identify with no one in the story. It is a mundane story about an uninteresting and unnecessary practical problem, self-inflicted and then solved in an elementary way. The problem is not general, the solution is not interesting, and no one in the story is very smart.