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.
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.
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.
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...
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." :-)
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.
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.
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.
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.
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.
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.
[+] [-] Dove|13 years ago|reply
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.
[+] [-] lotharbot|13 years ago|reply
[+] [-] pash|13 years ago|reply
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 ...
... 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.)
[+] [-] dunham|13 years ago|reply
They started out with a toilet on each car and ended with a toilet on each car, the cars just happened to be twice as long in the end.
[+] [-] gojomo|13 years ago|reply
• 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.
[+] [-] 205guy|13 years ago|reply
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.
[+] [-] neumann_alfred|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] run4yourlives|13 years ago|reply
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.
[+] [-] 3JPLW|13 years ago|reply
What a spectacular tautology. But, yes, you are right. More importantly: It's an easy place to win or lose dollars.
[+] [-] onemorepassword|13 years ago|reply
No joke, they even came up with the brilliant idea of handing out plastic bags for "emergencies"...
[+] [-] pavel_lishin|13 years ago|reply
[+] [-] digitalengineer|13 years ago|reply
[+] [-] jules|13 years ago|reply
[+] [-] dsr_|13 years ago|reply
So I'm not a manager, and not a programmer... I'm a sysadmin at heart.
[+] [-] betterunix|13 years ago|reply
[+] [-] gz5|13 years ago|reply
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...
[+] [-] mistercow|13 years ago|reply
But it was fixed. It just took a clever enough incremental improvement to move back to square one.
[+] [-] xenophonf|13 years ago|reply
[+] [-] bernardom|13 years ago|reply
"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." :-)
[+] [-] gsg|13 years ago|reply
[+] [-] xenophonf|13 years ago|reply
[+] [-] digitalengineer|13 years ago|reply
[+] [-] run4yourlives|13 years ago|reply
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.
All in all, they probably took a loss.
[+] [-] thirdstation|13 years ago|reply
[+] [-] mav3r1ck|13 years ago|reply
[+] [-] BCM43|13 years ago|reply
[+] [-] juan_juarez|13 years ago|reply
[+] [-] andmarios|13 years ago|reply
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.
[+] [-] larrydag|13 years ago|reply
[+] [-] gsg|13 years ago|reply
Your reading works too.
[+] [-] run4yourlives|13 years ago|reply
[+] [-] JumpCrisscross|13 years ago|reply
[+] [-] redwood|13 years ago|reply
[+] [-] run4yourlives|13 years ago|reply
[+] [-] oasisbob|13 years ago|reply
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.
[+] [-] greenyoda|13 years ago|reply
[+] [-] redwood|13 years ago|reply
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.
[+] [-] xefer|13 years ago|reply
[+] [-] ww520|13 years ago|reply
[+] [-] sidcool|13 years ago|reply
[+] [-] anonymouz|13 years ago|reply
[+] [-] shardling|13 years ago|reply
Of course, this is exactly equivalent to just making the cars so that they all have restrooms, but are twice as long...
[+] [-] F_J_H|13 years ago|reply
[+] [-] ak0s|13 years ago|reply
[+] [-] kstenerud|13 years ago|reply
* Toilets every n cars (from 0 to 3)
* Asymmetrical vs symmetrical ordering of toilet enabled cars.
* Helvetica vs Times for signage.
etc.
[+] [-] Yhippa|13 years ago|reply
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.
[+] [-] thesteamboat|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] jules|13 years ago|reply