Four to five calls per week? Really? So many?
This was a kindof interesting article about designing a gas station to prevent crime. The concept was neat and also pretty obvious if you think about it – clear sight lines, brightly lit, no hiding places. Seems to have worked; police calls are down by a third (222 calls/year to 148 calls/year). Awesome.
Except, look at that gas station. Kinda… industrial-looking, don’t you think? So bare, so concrete-y. It isn’t appealing for criminals to lurk there, but it isn’t appealing to be there either. That’s probably fine. There’s no good reason to linger at gas stations. But the whole thing reminds me of what I call One Thing Engineering.
One Thing Engineering is what happens when you give engineers one purpose to maximize. (The gas station actually has two; ease of buying gas and preventing crime.) Engineers are GREAT at that. Hoooo boy, they love that. They will go home and think of small improvements and tinker with designs until they squeeze every last advantage to serve the One Thing. Then they know they did a good job. If you come to them after and say, ‘but that gas station is a heat island in the middle of the block’, they will say, ‘sure. I had to do it that way to get in the other crime preventing feature.’ And you say ‘kinda awful-looking, isn’t it? Punches a hole in that block, wouldn’t you say?’ and they say, ‘Yep. That deters criminals by 17.3%.’
That is why I don’t fault engineers for well-designed systems that cause other bad effects. (Faulting them for poorly designed systems, when that happens, is completely appropriate.) They simply did the assignment they were given. If you want a gas station that sells gas, deters crime and looks nice, then you expand the problem statement. Engineers will happily maximize for those things*.
This is why broad and forward-looking thinking has to come first. Decisions come first, what the priorities are and what the goals are. Everyone who is affected, anyone who wants to be involved, should make those decisions; those decisions will be based on their preferences and morals and intuitions. Those decisions will be based, in large part, on how they feel. Soft things like feelings are plenty good enough to decide things like ‘what should a gas station in my neighborhood do’ and ‘what should water in my state do’. After those decisions are made, hopefully in an inclusive and transparent process, you send in the engineers and economists**. Then the engineers design something that does the best it can with all the different things the public wants. Then the economist unleashes her market forces to get efficiencies out of voluntary trades. But the design and the market are there to support the decision. They are not worthwhile in their own rights. They’re just systems to accomplish something. We pick that something together, for all kinds of good and bad reasons. When participation is open and the information is readily available and the choices are clear and the trade-offs are explicit and the decision reflects what people wanted, then democracy got its due.
*One danger of this is that the new design will do no individual thing as well. The trade-offs always find us.
**You maybe want to have them there at the beginning, too, to give people bounds on what can be done for reasonable money.
Except, look at that gas station. Kinda… industrial-looking, don’t you think? So bare, so concrete-y. It isn’t appealing for criminals to lurk there, but it isn’t appealing to be there either. That’s probably fine. There’s no good reason to linger at gas stations. But the whole thing reminds me of what I call One Thing Engineering.
One Thing Engineering is what happens when you give engineers one purpose to maximize. (The gas station actually has two; ease of buying gas and preventing crime.) Engineers are GREAT at that. Hoooo boy, they love that. They will go home and think of small improvements and tinker with designs until they squeeze every last advantage to serve the One Thing. Then they know they did a good job. If you come to them after and say, ‘but that gas station is a heat island in the middle of the block’, they will say, ‘sure. I had to do it that way to get in the other crime preventing feature.’ And you say ‘kinda awful-looking, isn’t it? Punches a hole in that block, wouldn’t you say?’ and they say, ‘Yep. That deters criminals by 17.3%.’
That is why I don’t fault engineers for well-designed systems that cause other bad effects. (Faulting them for poorly designed systems, when that happens, is completely appropriate.) They simply did the assignment they were given. If you want a gas station that sells gas, deters crime and looks nice, then you expand the problem statement. Engineers will happily maximize for those things*.
This is why broad and forward-looking thinking has to come first. Decisions come first, what the priorities are and what the goals are. Everyone who is affected, anyone who wants to be involved, should make those decisions; those decisions will be based on their preferences and morals and intuitions. Those decisions will be based, in large part, on how they feel. Soft things like feelings are plenty good enough to decide things like ‘what should a gas station in my neighborhood do’ and ‘what should water in my state do’. After those decisions are made, hopefully in an inclusive and transparent process, you send in the engineers and economists**. Then the engineers design something that does the best it can with all the different things the public wants. Then the economist unleashes her market forces to get efficiencies out of voluntary trades. But the design and the market are there to support the decision. They are not worthwhile in their own rights. They’re just systems to accomplish something. We pick that something together, for all kinds of good and bad reasons. When participation is open and the information is readily available and the choices are clear and the trade-offs are explicit and the decision reflects what people wanted, then democracy got its due.
*One danger of this is that the new design will do no individual thing as well. The trade-offs always find us.
**You maybe want to have them there at the beginning, too, to give people bounds on what can be done for reasonable money.
posted by Megan at 12:08 PM
14 Comments:
Some CPTED solutions, such as adding more streetlamps to make residents feel safer, may seem obvious.
This, from the article, worries me a bit. I've read, and it certainly accords with my own perceptions, that you're safer with less intense lighting at night. People's vision can adjust way down, if there's a consistent level of dimness. But pools of bright light, like a gas station, make your eyes adjust to them, and then you're blind walking out of the pool into a more dimly lit area.
Good post, as an engineer (software, btw) I run into this problem all the time.
Me: What do you want me to create?
Management: This thingy.
Me: That's a very broad spec, are you sure you want _me_ making all the choices and privatizations? I'm a smart person, but I'm not the person who will use this. I lack experience in the real world with this sort of system, we should engage people who have more application knowledge.
Management: Nice work, you're now 1.2 days behind schedule. Less talky more worky drone.
Me: There's a schedule? I don't even have a design yet.
Management: Of course there's a schedule and you're now 1.6 days behind.
Me: Right, well, I'll give you a good faith effort to guess what you want. I'll write it all down and you can sign off on it.
[days...]
Me: Here's my proposal...
Management: *no response*
Management: You know you're 6 days behind.
[weeks...]
Me: I've come to a point where I need input. I have a decision to make and there are three choices that seem equally good to me. I need clarification of the business or user's interests.
Management: WHAT?!?!?!
Me: Input. Needed. Now.
Management: Write it up, we'll get back to you.
[days...]
Me: Bueller? Bueller?
[weeks...]
Me: Ok it's done.
[the process forks here based on management's response]
Management: Uh, that's nice, put it over there.
Me: Um, you gonna use it.
Management: *no response*
[OR]
Management: WHAT!?!?! It's not red and yellow polka dotted, it HAS to have RED and YELLOW POLKA DOTS!!!!
Me: Yeah, see, I didn't know that, you didn't tell me about polka dots. Before starting I sent you a detailed plan with an executive summary that never said a word about polka dots. You didn't read that did you?
Management: POLKA DOTS!!!!!11111!111!11!!
[politicking and fighting ensues]
So while I see the phenomenon you describe (and appreciate your insight to recognize it for what is) I kinda like seeing engineering run a mock. It reminds me that my situation is pretty universal.
er... "prioritizations" not "privatizations" in the second "Me:"
LB, I personally love dark streets. Other people seem to like them lit, though. Dunno which is safer.
Scott, you're totally right. It is hard (and also expensive) to get all that input up front. If you like seeing engineering run wild, you should be a pretty happy guy. There's lots of that everywhere.
Scott, you're totally right. It is hard (and also expensive) to get all that input up front. If you like seeing engineering run wild, you should be a pretty happy guy. There's lots of that everywhere.
Sadly I was exaggerating. Truth is I got into engineering because I love well built things and think the world is a much better place when our designed artifacts are really really good. Single factor design wrecks that. Some day I might learn how not to give a damn, but that day won't be today.
Also, I recognize how hard full requirements gathering is at the beginning of a project. Some of the best projects I've worked on were highly iterative. Software's nice like that, it's malleable. But the sad truth is that most of the time _nobody_ pays _any_ attention to spec or design at any point of the project. Not that any of this is a surprise to teh Public of teh Intarwebs. Anybody who uses any software product anywhere can see just how broken the software industry is be looking at how much terrible software there is.
heh, SC... I know people who think that line about you starting to code while I go figure out what the specs are, is just a joke... It's so very true, a sad amount of the time.
"oh yeah, and now we need you to scale that 1000%, but keep it in access database so I can change stuff later..."
What I was wondering is why no architect seemed to be involved? hey at least might help you with the 'uglier 'n sin' aspect of many retail buildings, at least in theory.
Cool. Engineers complaining about faulty specs, and implying that it's easy (or even possible) to fix!
As LB's example perfectly encapsulates, intent and decision-making are the important part of engineering, much more so than execution or optimization.
It's simply not possible to make all decisions first, then build the perfect agreed-upon thing. At least with most current humans, you just can't get them to discuss it in the abstract, and certainly can't hold them to it when they change their minds.
The engineers must design and explain WHILE the stakeholders express (and change) their feelings AND the market forces (and/or authority power relationships) aggregate those desires into measurable trade-offs.
This all happens continuously in a beautiful and horrible fractal mess of a system. Trying to split it into discrete phases is doomed.
Why can't we save power and have motion sensors on the lights? or at least low power ones like these http://electrimetric.blogspot.com/2007/08/bright-ideas-lunar-resonant.html
Anywho, what I'm really here to say, is that the reason they optimize for one thing is because decisions can be made. Does this reduce crime? yes. move on. But when optimizing for two vectors you don't have a procedural way of deciding improving X by 8.3% at the cost of reducing Y by 9.2%, better or worse?
short of months of input (which is good when you can get real input from a cross section of people) you're stuck.
Of course often more progress is made by engineering something then re-engineering it, after real world use than by waiting for months and years to supposedly get it done right the first time mean while everybody is waiting to be able to pump gas, any gas even ugly gas station gas. (this is really a software engineering biased rant)
Lit is obviously safer. If you're attacked in a dark area, people can be near by and not raise an alarm. If, on the other hand, an area is well lit, you can see somebody approaching and avoid them. People can't lurk in lit areas and catch you unawares.
Perhaps these aren't issues for you. You live in a fairly safe place, you're fast, often on a bike, strong, and well trained in martial arts. But for the rest of us, lit is most definitely safer.
Look at testimony from crime victims or ask people who have been attacked, the pattern is pretty clear.
There are a couple of orthogonal issues here that ought to be teased apart. One is avoiding One Thing Engineering, which I completely agree with. Another is in what order to consider engineering (how, exactly what) vs. "non-engineering" (why, generally what) concerns. And another is what the boundary between those two kinds of concerns should be.
Order-wise, one of the lessons from software is that waiting to involve the technical people is a bad idea. While a "customer" (gas station owner, public at large, misc stakeholders) may have some idea of what they want, they generally don't understand the tradeoffs very well. Very often, engineering insight will let you have your cake and eat it too, and that kind of information should be part of the process from the beginning. Even when that's not the case, an understanding of what's possible should absolutely inform the broad goals of any project.
Of course, that's not to say that engineering input is more important that non-engineering input. You absolutely have to have both, I agree. You just don't want to separate the two kinds of concerns the way you seem to be advocating. Instead, they should both fuel an ongoing dialogue.
The solution in the software world is to iterate. Start with rough ideas, implement a basic version, talk about where you want to go from there. Lather, rinse, repeat. Even outside of software this has reasonably broad applicability; if you're a gas station chain you're going to be building gas stations over and over again, and renovating some over time.
Of course, if you only have the resources to build something once, then iterating is harder. But you can still get some of the benefit here with simulations and models (both physical and computer models). The Holland dam thing in particular I liked because it bridged the gap between engineer and stakeholder in a very intimate way.
As far as the boundary between engineering and non-engineering concerns, I think engineering practice ought to expand to include as many relevant concerns as possible. In other words, avoid One Thing Engineering by training the engineers to appreciate the aesthetics of the gas station.
All that aside, I get the feeling that this post is more about reason vs. emotion in public policy than it is about engineering.
I certainly agree that emotion and intuition ("what do we really want?") should set the overall direction of public policy. All I ask is that you recognize that there are plenty of situations where emotion can lead you astray. And I want you to answer the question of how to deal with that kind of situation.
My favorite example of people making emotionally-driven mistakes in public policy is with Kyoto. I think it's a pretty good first step. But I've heard criticism from both sides; republicans don't like it because it increases the cost of certain kinds of businesses. They fear the government coming and taking their livelihood away. One way to counter this concern is by making more concrete the reasons to fear excess carbon emissions (a la "An Inconvenient Truth").
But I've run into hippies that don't like Kyoto because it uses a market mechanism. "Let people pay to pollute more?" they'll say. This idea triggers all of their fear of and hatred for the Big Bad Businessman. You can almost see the top hat and monocle in their minds' eye.
The only counter I have for that is to say that the market mechanism gives you the most pollution-reduction bang for your economic-disruption buck. But that response lacks emotional resonance; their anti-market bias is often deeply ingrained, and I can't figure out how to touch it.
I've been told (don't remember by whom, but by people who knew him) that George Danzig thought his greatest contribution was not the simplex method but getting people to think about their objective function.
BA
It's hard to say for sure from the pictures in the linked article, but that gas station doesn't look any less attractive (or any more unattractive) than the typical such establishment.
Why so negative towards One Thing Engineering?
OTE is only bad under some circumstances, ie. When more than one thing should have been optimized. There are plenty of times when OTE is the best thing to do. I'm thinking of Formula 1 cars, racing bicycles, tennis raquets, bank vaults ...
Hi doctorpat,
I'm not sure those examples are about maximising one thing alone, there is usually (at least) one constraint: for the vehicles it tends to be safety issues; more broadly for sports equipment there is usually a balance of power and control; even bank vaults, security needs to be balanced with certain levels of functionality...
I really have trouble coming up with a situation where you really want to maximise only one thing - utility functions are (almost) never one-dimensional.
Post a Comment
<< Home