A Tale of Two Bridges(unprotocols.org)
unprotocols.org
A Tale of Two Bridges
http://unprotocols.org/blog:16?
17 comments
This is why I like coming here. I'd never thought of the tradeoff in that way before reading that quote, yet it makes perfect sense.
(I'm not arguing with your point at all, but of course there's software... and then there's software. Building might be cheap for both, but cost of deployment could be entirely different. Spacecraft control, microcode in an appliance, even certain classes of enterprise software all benefit from big up-front design because it's so expensive to patch later.)
(I'm not arguing with your point at all, but of course there's software... and then there's software. Building might be cheap for both, but cost of deployment could be entirely different. Spacecraft control, microcode in an appliance, even certain classes of enterprise software all benefit from big up-front design because it's so expensive to patch later.)
I would go further and argue that software is design.
I don't know that much about real-world engineering, but I imagine you can plan out a car, or a bridge, or a skyscraper, almost perfectly before you build it.
Wheras the only perfect design for a piece of software is the software itself. If you wrote pseudocode that was unambigious and covered every detail, it would simply be code.
I don't know that much about real-world engineering, but I imagine you can plan out a car, or a bridge, or a skyscraper, almost perfectly before you build it.
Wheras the only perfect design for a piece of software is the software itself. If you wrote pseudocode that was unambigious and covered every detail, it would simply be code.
Forgive a shameless plug for a dear friend, but Harmon Parker builds footbridges in the back country around Kenya. His bridges bring people together and save lives:
http://www.bridgingthegapafrica.org/
What he does is not too different from the rope guy in the parable. He doesn't come in with a big team and a grand plan. He goes out and gets to know the people and finds out from them where they have dangerous crossings and what they need, and they build a bridge with him.
Harmon has the engineering know-how to make it safe, and the local people have knowledge he never could assume. When it's done, it's their bridge and they know how to maintain it: the people who use the bridge have been involved from the beginning.
http://www.bridgingthegapafrica.org/
What he does is not too different from the rope guy in the parable. He doesn't come in with a big team and a grand plan. He goes out and gets to know the people and finds out from them where they have dangerous crossings and what they need, and they build a bridge with him.
Harmon has the engineering know-how to make it safe, and the local people have knowledge he never could assume. When it's done, it's their bridge and they know how to maintain it: the people who use the bridge have been involved from the beginning.
I remember reading about him a few years back. (I think the link might even have come from memepool.com) His story was and remains my favourite example of practical aid in Africa. Skill, not money. Pragmatism, not ideology. Long-term cure, not palliative treatment. I'm sure you're honoured to count him among your friends.
I, too, can write vague parables to support just about any point.
And what is the point? That it's always better to let the grassroots develop software? Like so many other things in this world: It's Just Not That Simple.
And what is the point? That it's always better to let the grassroots develop software? Like so many other things in this world: It's Just Not That Simple.
Parables are, by their nature, designed to make you think about how you think about something. I know it is a kind of circular argument but the key is that people sometimes can't think outside the way they think. A parable is a way of bridging (sorry) that gap.
In this parable person A is engineering solutions, they are told to build a bridge so they build a bridge. Person B is solving problems, the people on one side of the gorge want to trade with people on the other. As part of the problem solution a bridge is built.
If the parable works, it kicks your thinking out of its rut for a moment so that you can ask yourself if there is something you are building/doing for the sake of doing it rather than because it solves a larger need. If you are, then you should consider what happens when you are done and everyone realizes it isn't really "needed." You can be ok with that, or not. But the key was you took a moment to think about it.
Parables hack your thinking process.
In this parable person A is engineering solutions, they are told to build a bridge so they build a bridge. Person B is solving problems, the people on one side of the gorge want to trade with people on the other. As part of the problem solution a bridge is built.
If the parable works, it kicks your thinking out of its rut for a moment so that you can ask yourself if there is something you are building/doing for the sake of doing it rather than because it solves a larger need. If you are, then you should consider what happens when you are done and everyone realizes it isn't really "needed." You can be ok with that, or not. But the key was you took a moment to think about it.
Parables hack your thinking process.
> person A is engineering solutions, (...) person B is solving problems.
This. You managed to highlight a difference that is often forgot.
I used to think mostly like person A, but the longer I stay on HN, the more I feel I start to think like person B.
This. You managed to highlight a difference that is often forgot.
I used to think mostly like person A, but the longer I stay on HN, the more I feel I start to think like person B.
I'm not sure what you mean by "grassroots", but the lesson I took away is that it's often better to launch early and iterate based on user feedback, rather than dump a bunch of effort into making a product that people might not turn out to actually want.
"Grassroots." A whole bunch of people built the second bridge based on their needs. The community.
The parable in that article is not about one person iterating based on user feedback. It's about users taking action and building upon existing works. Which is awesome if everyone has similar needs. But what happens when that group-made bridge hangs too low and interferes with river traffic? Or if I think it should be redone with steel but you don't want to have it closed for a year while that happens? What if I think it helps my competitors too much, so I burn it and start a new bridge closer to where I want it?
This is why we plan things. So everyone has a stake in the process and we can try to make good decisions that fit everyone's needs. Top-down planning isn't the only way to go, for sure, but this article is idiotic as far as making a point that community development is always the way to go.
This is a simple parable that offers next-to-nothing as far as real world solutions except to say that, yes, we should make sure what we're building is useful. Which: No shit.
The parable in that article is not about one person iterating based on user feedback. It's about users taking action and building upon existing works. Which is awesome if everyone has similar needs. But what happens when that group-made bridge hangs too low and interferes with river traffic? Or if I think it should be redone with steel but you don't want to have it closed for a year while that happens? What if I think it helps my competitors too much, so I burn it and start a new bridge closer to where I want it?
This is why we plan things. So everyone has a stake in the process and we can try to make good decisions that fit everyone's needs. Top-down planning isn't the only way to go, for sure, but this article is idiotic as far as making a point that community development is always the way to go.
This is a simple parable that offers next-to-nothing as far as real world solutions except to say that, yes, we should make sure what we're building is useful. Which: No shit.
> but this article is idiotic as far as making a point that community development is always the way to go.
What part of the article suggests that?
What part of the article suggests that?
Agree - this type of parable may be suitable for small children, but if you think about it, it has zero information content, and no applicability to the real world.
I'd much rather read a real story about a real bridge or two - that's what I come to HN for.
I'd much rather read a real story about a real bridge or two - that's what I come to HN for.
Real world version: Google Wave is bridge #1.
Edit: The CueCat is an even better example!
Meanwhile, the transition of Amazon from bookseller to everything-seller to hardware maker to cloud company is a good example of a real-world Bridge #2 story. Or the transition of Justin.tv into Twitch.
Edit: The CueCat is an even better example!
Meanwhile, the transition of Amazon from bookseller to everything-seller to hardware maker to cloud company is a good example of a real-world Bridge #2 story. Or the transition of Justin.tv into Twitch.
The first iPhone is also bridge #1. An overly-designed gizmo that no one needed at the time.
Hence its massive failure.
Hence its massive failure.
The first iPhone was a bridge with a circus. Hence everybody went to see it, even though the toll was hefty. Some loved it so much, they even left their own village for good.
In time a settlement grew around the circus. Now most people live around it. To see tigers and the zebras every morning became their way of life. No one lives in the old villages anymore, and who would - it doesn't even have a giraffe!
Then came another bridge - little down the stream. This also had a circus, but with robots in it instead of animals. It became suddenly very popular for two things - 1) people are already used to living around a circus, and 2) the toll was way cheaper. Also robots were a novelty - who wants to see a giraffe when there are robots?
In time a settlement grew around the circus. Now most people live around it. To see tigers and the zebras every morning became their way of life. No one lives in the old villages anymore, and who would - it doesn't even have a giraffe!
Then came another bridge - little down the stream. This also had a circus, but with robots in it instead of animals. It became suddenly very popular for two things - 1) people are already used to living around a circus, and 2) the toll was way cheaper. Also robots were a novelty - who wants to see a giraffe when there are robots?
I don't know what to say to you except "I'm glad this kind of story is on HN."
Reminds me of the best-selling parable of two mice and cheese, that I read before I had exposure to any real-world situations one might compare it with.
I thought the story was moronic. The mice made stupid decisions based on available information, performed no secondary actions, and the suicidal one was the one we were supposed to emulate.
Of course, I now understand a little better why people liked the story, but I'm glad I read it way back when I didn't.
I thought the story was moronic. The mice made stupid decisions based on available information, performed no secondary actions, and the suicidal one was the one we were supposed to emulate.
Of course, I now understand a little better why people liked the story, but I'm glad I read it way back when I didn't.
So the moral of the story is...
cross that bridge when you get to it.
Ha-ha! GET IT? No seriously, though. That's the lesson. Build for actual need now, not something you think you might need in the future.
cross that bridge when you get to it.
Ha-ha! GET IT? No seriously, though. That's the lesson. Build for actual need now, not something you think you might need in the future.
I think the moral is to pave over the desire path[1] and iterate with user feedback, rather than doing the big design up front and finding out nobody wants to use it after the money is already sunk.
[1]http://en.wikipedia.org/wiki/Desire_lines
[1]http://en.wikipedia.org/wiki/Desire_lines
The lesson is the first bridge would have been an unqualified success if only they had conducted usability studies and A/B testing and gathered feedback from community-oriented focus groups and practiced just-in-time lean-agile bridge-driven design concepts.
And applied for 6000 patents.
And applied for 6000 patents.
First paragraph is optional.
>Just a rope, tied to two trees. There were two villages, one at each side. At first, people pulled packages across that rope with a pulley and string.
I'm trying to visualize this, and it's not making any sense to me. I searched around to see if any such system is commonly used, and the closest I can find is a hauling line, which requires a second length of rope, at least long enough to span the gorge twice, which is hooked to the original rope via a carabiner and anchored at both sides. But there's no pulley involved with that (although if you wanted to over-engineer it, I guess you could use one instead of the carabiner).
So is this an actual thing that people do, or am I reading too much into this parable?
I'm trying to visualize this, and it's not making any sense to me. I searched around to see if any such system is commonly used, and the closest I can find is a hauling line, which requires a second length of rope, at least long enough to span the gorge twice, which is hooked to the original rope via a carabiner and anchored at both sides. But there's no pulley involved with that (although if you wanted to over-engineer it, I guess you could use one instead of the carabiner).
So is this an actual thing that people do, or am I reading too much into this parable?
Enterprise ending:
The Big 5 auditors refuse to certify the suspension bridge because in their opinion, it doesn't satisfy GAAP & SOX.
$10 million is paid to the Big 5 auditors for a program of education and documentation to convince everyone to use the "best of breed" bridge.
The suspension bridge is sunsetted.
It's so difficult to use the enterprise bridge that people don't bother. Eventually they move to another valley.
The town dies and its assets are sold for 10 cents on the dollar. Management blames "market conditions".
The Big 5 auditors refuse to certify the suspension bridge because in their opinion, it doesn't satisfy GAAP & SOX.
$10 million is paid to the Big 5 auditors for a program of education and documentation to convince everyone to use the "best of breed" bridge.
The suspension bridge is sunsetted.
It's so difficult to use the enterprise bridge that people don't bother. Eventually they move to another valley.
The town dies and its assets are sold for 10 cents on the dollar. Management blames "market conditions".
Heh. Startup ending:
Super-colourful, free-to-use bridge with moving walkways and an open bar half way across gets incredible traffic (despite dumping a few crossers into the gorge every now and again). Then one market day it's gone, replaced by a sign with a smug-looking photo of the builders and a note excitedly apologising for selling the bridge for parts to the nearest big city.
Super-colourful, free-to-use bridge with moving walkways and an open bar half way across gets incredible traffic (despite dumping a few crossers into the gorge every now and again). Then one market day it's gone, replaced by a sign with a smug-looking photo of the builders and a note excitedly apologising for selling the bridge for parts to the nearest big city.
I think the lesson is that vague fictional parables to support your worldview are a better way to work than real stories or facts.
I'm at all convinced that this would be any truer had it actually happened.
See also the recent Death Star Design Pattern by K. Kovacs: http://kkovacs.eu/the-death-star-design-pattern
The first bridge was an example of this.
The first bridge was an example of this.
Can you possibly REPLACE stone by steel in a bridge without destroying it and building it back again?
Doesn't sound plausible to me...
In the real world, when Engineer 2 needs a steel bridge to replace the stone one, he asks Engineer 1.
That would be the condition required for Engineer 1 to build her fancy bridge. If market research had been done properly beforehand, of course.
Doesn't sound plausible to me...
In the real world, when Engineer 2 needs a steel bridge to replace the stone one, he asks Engineer 1.
That would be the condition required for Engineer 1 to build her fancy bridge. If market research had been done properly beforehand, of course.
"In most parts of the world, when a bridge is needed it is built from wood, steel or concrete. But in Cherrapunji in northeastern India, the locals are much more patient. They simply coax nearby trees to grow into natural bridges. The process takes many years, but the result is completely natural, surprisingly strong, and looks like something out of a wonderful fantasy world..."
From: http://webecoist.momtastic.com/2009/10/21/bridge-to-nature-a...
From: http://webecoist.momtastic.com/2009/10/21/bridge-to-nature-a...
The point of the tale is to hire the 2nd engineer on the cheap to find out where people cross the river, then hire the 1st one to build the real thing.
What if it turns out that there's only enough demand to support a wooden bridge? If you went right from the rope to the superbridge, you've wasted an unbelievable amount of effort.
Reminds me a quote from pg: "Don't try to construct the future like a building, because your current blueprint is almost certainly mistaken. Start with something you know works, and when you expand, expand westward." http://paulgraham.com/ambitious.html
I have heard a very similar tale used to describe the inefficiencies of a centrally planned economy vs free market.
Needs more GNU/Bridge
"When designs are cheaper than builds, e.g. a skyscraper or a bridge, big up front design makes good sense. But when builds are cheaper than designs, e.g. software or oil painting, short and iterative design and build steps are best."
I couldn't agree with that more.
I work in an industry where builds are not cheap and iteration after launch is nearly impossible. You better believe we have a very, very long design cycle.