malvasia bianca

I wasn’t sure what I thought about this article on removing warning signs when I first saw it, and I’m equally confused by this one. On a basic level: does this really work? I’ve never driven in Europe, I’ve never been to Italy at all, so I don’t have much context for many of the examples. If it does work there, would it work in an American city? (Doubtless better in some than in others.) Would it work in the more suburban area where I currently live? It’s hard for me to imagine techniques that would naturally cause cars to want to travel under 20mph here. And then there’s Green Streets…

The second mentioned article is the one I’ve been thinking about more, because of my current lean obsession. I’ve been on a bit of a slow driving kick for a couple of years, so I actually do frequently come to a complete stop at stop signs, but I would tend to agree that doing so doesn’t make my driving any safer – it just slows me (and potentially other people) down. (And wastes gas, too.) To be sure, my slow driving has flow benefits as well – if I see a red light ahead of me, I just coast, which has the benefit that I’m more likely not to have to come to a complete stop at the light, giving me a speed advantage. (And saving gas in two ways.) Go production leveling! Of course, you have to be a bit careful: if you cut the timing on the light too close, you can get killed by somebody running a red light. But in general asking the question “is holding down the gas pedal going to improve my total time, or is something else the bottleneck?” has had pleasing affects on my driving.

But what I’m really confused about is this: on the one hand, we have the idea that adding explicit safety (or quality) warnings is actually less safe than encouraging people to pay attention to natural environmental signals. Which I think I’ve seen in other lean sources, though I’m not completely sure that it’s canon; I’m also not completely sure I believe it, but it’s plausible enough. On the other hand, lean also heavily promotes certain kinds of quality signals, so you can tell when something has gone wrong as quickly and as immediately as possible. So: how do I tell the good sorts of quality warnings from the bad sorts?

I would like to say that I know it when I see it, but a bit of testing shows that that isn’t the case. Is pair programming a good sort of quality signal, encouraging a constant flow of dialogue about the process and hence heightening awareness? Or is it a bad, rigid, rule that’s a detriment to flow and encourages people not to pay attention to what’s going on because surely their partner will catch the problems? Or is it orthogonal to the issues raised by these traffic articles? I tend to think that pairing is more good than bad, but it’s not at all clear to me how to derive that from general principles. (And maybe this is a sign that we’re doing the right thing at work by not pairing all the time.) TDD raises similar questions to me – good, bad, excessively rigid, creating an informative environment, something else entirely? Again, hard for me to analyze, though here I’m rather more confident that it’s almost universally a good idea – you’ll pry my unit tests out of my cold, dead hands, and red, green, refactor is a wonderful way to work. (But perhaps those wonders, especially the design benefits, are orthogonal to these issues.)

Always more to learn.