Conundrum 65: Taxi Driver Braking Style

The burning issue that has been exercising my mind for the past few hours is the way in which taxi drivers apply brakes to their cars. Thus I give you another entry as part of an occasional series, briefly noted...

So. Why do taxi drivers brake the way they do? What accounts for their peculiar relationship with their car's braking system? Why is that taxi drivers never want to idle their cars? And so forth...

When a cab driver sees a red light, she will do one of two things:

1. Accelerate and simply speed through the light - daring oncoming traffic in a game of chicken.
   This behaviour is almost de rigeur if you want to obtain a taxicab medallion - an initiation rite of sorts. When your car is branded as a taxi, it is a signifier, almost a warning signal of recklessness to other drivers, and you can trade on this reputation to bully through most intersections. Such are the fringe benefits of every profession.
2. Slow to a stop at the light if it is obvious that one can't beat the light.
   In this scenario, you'll almost see the subliminal scowl on the driver's face in the mirror and the accompanying sound of disgust under their breath.

It is the manner in which taxi drivers slow to a stop that is the source of today's conundrum.

A taxi driver never simply slows down to a stop like other drivers. There's an eccentricity to the gradual manner in which they apply their brakes. It's a little hard to describe exactly how they brake but it is different enough that I always notice it; let's simply posit for our purposes a Brake Eccentricity Index ™ and assign taxi drivers the maximum value, 10, on an admittedly arbitrary 10 point scale. Still, why do they brake in such an unnatural fashion?

Theory 1: Maximize the fare

I should be a little bit more precise about this, namely that I've mostly observed eccentric braking styles in cities that have metered fares for taxis. Of course correlation is not causation but I've always thought that it was the fact that meter fares are lower when the taxi is idle than when it is moving that drove taxi drivers to this behaviour.

The notion here is that by keeping the taxi moving for as long as possible you will reap fiscal rewards. Amortized over the length of a typical shift, perhaps you can sneak in an extra hour of fares at the higher, mobile rate. If you consider driving a taxi as a purely revenue maximization enterprise then the optimal economic strategy is all about minimizing engine idle time and maximizing the amount of time the car is moving. The braking style then is simply a matter of arbitrage; 5-10% extra revenue will be nothing to sneeze at (handwaving at the exact amount).

One piece of the puzzle however is that I sometimes observe as much even in countries where taxi rides are not metered transactions. What gives?

Some control experiments: presumably there should be increased eccentricity in braking style the larger the difference between moving and idle fares. Drivers in cities with greater idle premiums would exhibit a higher brake eccentricity. Anecdotally New York and Boston are more prone to the phenomenon than San Francisco.

The web being what it is, an armchair economist such as myself can validate such intuition...

Consider this table taken from the San Francisco Taxicab Industry Report 2006 via the invaluable Taxi Library site. It is a survey of rates charged in various US cities.

We'll codify a proxy for our braking eccentricity quotient as the ratio of mileage rate to waiting time rate. In New York, this ratio is 10 (mileage rate per mile is $2.00 and waiting time per minute is $0.20). In San Francisco, the ratio is 5 (mileage rate per mile is $2.25 and waiting time per minute is $0.45). This would confirm the greater propensity of New York cabbies to work the brakes and even assign them 10 on our admittedly arbitrary index.

Out of interest, we have the following results: Chicago at 5.45, Houston at 5.67, Los Angeles at 5.5, Oakland at 6, San Jose at 5.95. In my experience, Oakland taxi drivers are more eccentric than San Francisco cabbies so this seems to be about right. The rate structure of fares provides serious incentives to taxi drivers to do everything possible to keep in motion, it is no wonder that they are irritated at having to wait, idle time literally robs them of revenue.

Theory 2a: Minimize fuel consumption and/or 2b. minimize wear on the car's brakes

Part of the utility function that a taxi driver has to account for is the impact of fuel consumption. With conventional internal combustion engines, the fuel that is used when the engine is idle is pure waste, hence it makes sense to minimize fuel consumption as part of the profit maximization function.

Wear and tear on the brakes is also something drivers need to worry about; perhaps it is indeed easier on the brakes to slow down the way they do. No one tells you that when you learn how to drive so this might well be a trade secret of sorts.

This last theory is counterbalanced by the frantic way brakes are applied when the driver misjudges and almost causes an accident (all too frequently judging by the statistics of road accidents involving taxis). Frequent near misses and even accidents are almost a cost of doing this kind of business and in those cases, brakes are manhandled. So a question for auto engineers, what is the best way to apply brakes? Incidentally I wonder if there is any research on the incidence of heart attacks amongst taxi drivers, but I digress...

Some control experiments:

• hybrid cars are slowly being adopted into taxis fleets, these are cars in which the cost of idling has essentially been eliminated. Minimizing fuel consumption in one's Prius is thus a matter of running for as long as possible on electricity rather than on the conventional gasoline engine. Presumably Prius taxi drivers would not be as prone to brake eccentricity and the new technology might provide an insight into the relative importance of the fuel consumption factor. One should monitor the situation as hybrid adoption rates increase.
• rising petrol prices should increase the fuel consumption premium so there should be increased eccentricity when we have higher prices. Metered fares after all aren't indexed to petrol prices and are only updated episodically. Anecdotally again, I've been noticing more braking shenanigans during the Bush years with the concomitant high oil prices.

With this in mind, perhaps we can add some additional dampening factors to our braking eccentricity index. I welcome your mathematical input.

Exegesis

The obvious thing to resolve this conundrum is to simply ask taxi drivers why indeed they brake the way they do. The thing is that whenever I've observed this behaviour, I've typically been annoyed because I tend to lean towards the first theory, namely that the driver is engaged in an attempt to wring an extra dollar or so out of my inconsiderable wallet. With that at the back of my mind, it will come off adversarial to ask the driver about this, no matter how academic the concern is. Also you might change the behaviour merely by asking and make the driver self-conscious. Moreover, there's always something more pressing to talk about: politics, the economy, real estate, cars, relationships etc. In any case, small things like taxi driver braking styles are appropriate fodder for blog entries. I hope I've made a plausible economic case of cabbies being rational economic actors but of course I may be missing the plot. Perhaps others can come up with better analyses. The floor is yours...

On Metering and Automation

Now you might well wonder why indeed I'm spending time and virtual ink on this matter. Well it is in aid of a book of toli. The low end theory posits that one should temper the human factor to encourage adoption. Thus I've been digging around matters of human factors and automation. The obvious case study of the human factor in technology adoption is with taxis and the introduction of metered fares. A little digression and that's all she wrote.

The idea of meters, of standard fares introduced through regulation, meshes with an attempt to eliminate the vagaries of human discretion and bargaining around the negotiation of payment for rides. Prior to their introduction, one was at the mercy of one's skill and knowledge of prevailing rates when discussing fees with cab drivers, and often one would be at a considerable disadvantage in the conversation. The drive towards standardization and automation was almost inevitable in many communities; electronic meters were the technical solution to the legal and cultural problem. By metering you could reduce the amount of price discrimination that taxi drivers could do and gain some amount of consumer satisfaction at not having to bear the mental transaction costs.

Recently also there has been the introduction of GPS-driven radio dispatch into the taxi business in. One virtue is that this might prevent certain dispatchers from rewarding their favourites with the best jobs. I know that in the Boston area, Haitian cab drivers would always curse the often 'native' dispatchers, claiming that they wouldn't give them (the immigrants) jobs even if they were closer to the customers. Presumably technology in the form of location-aware optimization algorithms could add a measure of impartiality to the dispatching process along (potentially) with some extra efficiency. Of course as with all things in which the human factor applies this is not the end of the story. Wherever there is human discretion we will see the usual social and cultural cues and biases assert themselves in one form or another. For one, it all depends on what is coded and who gets to make the decision.

Indeed New York city taxi drivers will be going on strike against GPS devices in coming days:

The Taxi Workers Alliance opposes the installation of high-tech touch-screen video systems that will allow passengers to watch television, make credit-card payments and — using a global-positioning device that tracks the cab - follow their ride on an electronic map.

Some drivers have said that the global-positioning devices and the automated trip recording system are an invasion of privacy, and that the use of credit cards would diminish drivers' incomes, given the card transaction fees.

They also say they will take in less money because the system requires drivers to log on before each fare, and they object to the television noise and the heat from the monitors.

This last case is interesting in the bundling of two technologies, electronic payment systems and location aware devices. In both arenas, the proponents highlight the benefits in terms of consumer convenience: additional payment options and additional information (map data) that can empower the rider in the transaction with the driver. For example, a tourist, able to see a realtime map of their journey, will now be more liable to ask "Why the hell are you going in this roundabout way to my hotel?" and reduce the unscrupulousness of drivers.

Detractors similarly highlight the effects of payments and transaction costs. By introducing credit cards into the billing systems, the authorities are passing on increased costs to drivers, a tax of sorts. A slight digression here: the taxi profession has typically been a cash-is-king affair - hence for example its appeal for the informal sector often the domain of transients and immigrants etc. (e.g. for an extreme case of 'informality' you can read James Ellroy's novels on the appeal of taxi ranks for the Mafia).

Both sides of the debate conflate things. Who really wants to watch television in a cab? That is surely a byword for yet more advertising. And yet that is what Mayor Bloomberg is touting even as the agenda of the authorities is plainly to exert additional control on the profession. On the one hand, the argument about privacy that the drivers advance is probably not the core objection, it is rather the issue of control, about losing discretion in the way they do business and the burden of additional transaction costs (which can even be mental costs).

A few centuries ago, the Quakers brought sanity to the systems of measurement with their reputation for probity in the standards of weights they provided. Eventually, social norms and mores were codified in laws, regulations and sometimes in technological standards. It is interesting that we are seeing lawmakers seeking to impose technological standards to achieve social ends. As we have seen in the case of braking style, there will still be behavioural attempts to game the system — that is the realm of the human factor. In the low end theory framework, the best you can hope for is to temper these things.

This year in Accra, the Accra Metropolitan Authority introduced medallions for taxi cabs and even imposed a dress code on taxi drivers (although from what I understand, the dress code is not that widely adopted). The introduction incidentally lead to an immediate decrease in the typical crime methods where criminals would use cabs for their robberies. By getting control of licensing, the AMA has managed to better understand the scope of the taxi market, the public also can better identify taxis and further norms can be codified. One wonders whether metered fares will be the next regulation to be adopted in Ghana. As anyone would tell you, a large part of the experience of using public transit in Ghana is the bargaining that one must do. Taxi drivers will quote exorbitant fares to those they perceive as well-heeled or unaware of the prevailing rates - and you don't even need to be an obroni to feel cheated at times. Metered fares would have undoubted benefits in reducing this kind of price discrimination and the associated transaction costs but might also remove social and cultural lubricants, those aspects of conversation and market traditions. I wonder if this is a trade-off that should be made. What say you?

I'll close with a further digression... You might have seen me point to this Lion King decorated taxi a couple of weeks ago. The Wife caught it parked next to the zebras and kitsch taxi displayed above. I quite like the serendipity of the photos and the varying images of Africa expressed in taxicabs.

Abercrombie & Kent are merchants of "Inspiring Experiences of Namibia" hence the zebras crossing they use to advertise their escapist travel services. The Lion King of course is pure Disney nostalgia. Such are the types and faces we use on our taxis about Africa that mysterious land. The fantasy of Brand Africa.

A Taxi Driver Soundtrack

A playlist for this note

• Loose Ends - Slow Down
  Apropos braking, we'll start our playlist with Slow Down, the brilliant showpiece of Loose Ends' Zagora album. Classic 80s soul music, eminently danceable and with an infectious chorus. It is often paired with the lead single Stay A Little While Child and the titles are fitting for the laidback theme of the band.
• The La Drivers Union Por Por Group - Trotro Tour Of Ghana
  
  
  
  We'll continue with some music by taxi drivers, some honk horn music from Ghana. It's unlike almost anything you've heard, simply consisting of the horns and drums that you might here on the streets as these drivers vie for your trade and seek to attract your attention. This horn group has a 50 year history amongst other things, wielding their honk horns against the colonial regime. They continue to make music from the most unlikely of instuments.
  
  I quite like 'Driver, Take Me, The Train Has Left Me Behind' and the Kpanlogo Por Por Medley but perhaps it is "Trotro Drivers, We Love You So" that is the best song on the album. You can listen to the slightly more conventional yet still exuberant Trotro Tour of Ghana here.

File under: taxi, economics, observation, markets, billing, transaction, costs, pricing, regulation, culture, conversation, technology, automation, adoption, human factors, price discrimination, toli

On Coordination Costs and Human Factors

I reproduce here what I thought would be a short email that I fired off this afternoon discussing the web style. I hope it might gain from wider scrutiny...

• On Coordination Costs
• The Human Factor
• The Gospel of REST
• A Data Digression

On Coordination Costs

In an atypically verbose exposition, Matchmaker Roy Fielding propounded thusly:

Don't get carried away. You won't find a constraint about "nouns" anywhere in my dissertation. It talks about resources, as in resources, because that is what we want from a distributed hypermedia system (the ability to reuse those information sources through the provision of links). Services that are merely end-points are allowed within that model, but they aren't very interesting because they only amount to one resource. The really interesting services provide many resources.

Note that this is just another way of restating Reed's law in relation to Metcalfe's law.

Similarly, Layer Stripper Bill de hÓra recently flirted in the same manner:

Some people when faced when a distributed programming problem, think 'I know, I'll expose a new service interface.'

Now they have n-squared problems.

View Sourcerer Joe Gregorio almost in passing shined a light on some cobwebs (on caching and authentication on the web):

"In the process of implementing httplib2 I also discovered some rough spots in HTTP implementations."

Putting these together and handwaving as usual...

It strikes me that the first two statements are all about changing the frame and making economic arguments for REST (Representational State Transfer), namely constraining system design to resources, identifiers and uniform interfaces in order to lower coordination costs... ergo the web style as an enabler of Reed's Law.

I hadn't seen such explicit harkening to Metcalfe and Reed in the past even though there has always been this notion of REST as incorporating end-to-end principles. I too have argued in this vein about a complexity and integration argument for REST.

In a similar thread Benjamin Carlyle put it thusly

Uniformity is key. Simplicity at the network level is key. Managing state transparently as resources is important for its own reasons

Intuitively, the argument about applying architectural constraints to get payoffs in terms of leverage has a lot of appeal to engineers. It seems however that we need some economists to weigh in here with some options pricing theory or other to give more heft to these arguments. Often, decisions about software systems are not made by engineers but rather by financiers and it helps to speak their language.

Instead of Reed's notion of group forming, it seems the argument by analogy for REST is about application integration and the barriers that obtain in that sphere.

Now I like the large numbers that we can throw out in these reformulations. The thing is that Andrew Odlyzko says (pdf) that both Metcalfe and Reed's law are bunk despite their evident appeal and ability to dazzle venture capitalists.

In that paper he sets out to get quantitative measurements and hard data and puts the value of communication networks at nlog(n) which is nothing to sneeze at, better than Sarnoff's linearity but far less than Metcalfe and Reed's estimates. Now Odlyzko was measuring the utility of the internet which encompasses more than the web and you can argue, following Sam Ruby, that the email and peer-to-peer styles, whether expressed as, Bittorrent, Skype or usenet, are the true winners in his numbers... Also you could argue with his methodology and I have my own quibbles, but it's a brave man who takes on Odlyzko... Thus I'll take his numbers in my handwaving, acknowledging after all that the web was the key enabler and popularizer of the internet.

The Human Factor

This gets me to the third quote from Joe Gregorio, namely the perennial rough spots and implementation quirks that are our daily bread as engineers trying to design and produce systems for the web.

We see daily abuse of HTTP and there are annoying glitches with the libraries and implementations that exist and what is deployed in the real world. Perhaps this is because REST is the web style rather than the programming model and consequently enforces very few prescriptions. We are only now seeing good frameworks geared toward REST; historically, HTTP client and server libraries have been minimalist.

Now it seems to me that this is about the place where theory meets practice and we get into the realm of pragmatism and leverage. In the wild we see

• the difficulties of interoperation
• differing interpretations of specifications if indeed specs are read
• backward compatibility constraints e.g. for leverage and adoption, HTTP 1.1 had to accomodate some of the pitfalls in HTTP 1.0
• difficulties in authoring structured data
• configuration and deployment issues (mime types, content negotiation etc.)
• competition with other styles, the web style exists in a marketplace of architectures
• vested interests and economic models e.g. limits imposed by shared hosting providers, asymetry of some broadband networks etc

With this in mind, I wonder if I can come up with a stab towards Koranteng's postulates on coordination costs

1. There is a natural dampening factor in the utility of distributed computing
   
   We can use Odlyzko's numbers as the lower bound in practice of network effects and Reed's law as the theoretical limit (with Metcalfe being a great popularizer).
   
   I happen to be reading Graham Greene's The Human Factor and, looking through some of the issues that hinder adoption, many of them could be summarized as comprehension or human variability hence I'll characterize the issue as the human factor. All that is left is to augment with some Black-Scholes options thinking and financial derivatives to package to CEOs
2. the human factor in technology adoption is sizable and its effect can be measured. Moreover I would argue that it should be recognized as an explicit architectural constraint in the design on software systems.
3. In the realm of distributed computing, this human factor is bounded by Odlyzko's limit and Reed's law.
   Mathematicians can derive the correct coefficient for me... 1/nlog(n) ?

The rest as they say is advocacy and implementation details...

We are operating with imperfect specifications, imperfect frameworks and imperfect implementations. REST as laissez faire distributed computing doesn't acknowledge these costs as architectural constraints but rather seems to go about it by encouraging best practices and hoping that, by existence proof, people will come to it... One can look at the high level requirements that have been articulated

• Simple protocols for authoring and data transfer
• textual formats for protocol and some exchanged hypermedia
• Sensitive to user-perceived latency
• Mark Baker's talk about "principled sloppiness" (i.e. "must-ignore style extensibility")

We don't tend to enforce many of these things in the deployed protocols. I wonder what other best practices can lower coordination costs and whether they can be encoded in protocol to remove the human factor...

Anyway food for thought...

The Gospel of REST

If anything this enables me to add Reed's insight to my nascent taxonomy (or is it theology?) of the web style which some may have come across... namely:

There's a tag: REST

There's a slogan: the web style

There's a Holy Book: Architectural Styles and the Design of Network-based Software Architectures

There's a Reverend: HTTP

There's a choir: the HUHXtable quartet (HTTP, URI, HTML, XML)

There are Four Horsemen: GET, POST, PUT, DELETE

There are prophets: (you know who you are)

There are pillars: Resource Modeling, Idempotency etc.

There are priests and tax collectors: the caching and other intermediaries. Ergo "Render unto Caesar that which is Caesar's" recast as the notion of "giving visibility to intermediaries".

There are angels and demons: a band of Apaches and various HTTP libraries which are alternately sources of delight and exasperation.

There's a Messiah: the browser (which comes with various pretenders: Firefoxes, Great Explorers, Viking Operas and Fruity Safaris).

There are red herrings: url opacity etc.

There are false gods: WS-*, crusty old architectures of appropriation etc.

There's the wilderness and prodigal children: WebDAV?

There's Mary Magdalene and the disciples: HTML and Forms.

There's immaculate conception: the virtuous XML.

There are worldly travellers: the three mobile kings JavaScript, Java Applet and ActiveX (some discredited) and a Flashy pretender.

There are scrappy offspring: Atom, RSS and Atompub.

There are gruesome Philistines: implementation details such as Structured Data, Character Encoding and Security.

There are elevator pitches, Cliff Notes and ballads: Sir Tim's lullaby of Web Architecture 101 is quite reasonable as a Song of Solomon

There's myrrh and frankincense: the web as conversation engine

And now there's the Promised Land ©: Reed's Law as the proverbial milk and honey

The parts I'm missing are the Apocrypha and Gnostic gospels (with Judas in the news this week)... but those should be forthcoming... As will the eventual accommodation by Rome as the official religion but then Bill de Hóra has noted that we are almost there.

[Update] Ernie Prabakar suggests that "Lo-Rest" works as apocrypha and that "SOAP is really gnostic - it focuses on the divinity of XML, to the denial of its incarnation in HTML." One wonders who Rome is in the technology world, perhaps Microsoft like he suggests... I'd note in passing that I've heard in corridors that the IBM Software Group Architecture Board is "looking at REST" anew. That's got to qualify as progress... Pretty soon I'll be able to publish an official gospel from my muddy trenches. Looking further down the line, there will likely be a split between the Catholic and Orthodox churches as the empire suffers from navel gazing and an East/West axis of discontent and eventually there'll be Martin Luther and the Reformation... I wonder whether I'll live see to see the Protestants of REST and if I'll recognize them.

A Data Digression

I noticed last year that Roy Fielding produced a white paper about JSR 170 (Java Content Repository) for his day job (pun intended) applying principled constraints to the modeling of content repositories.

I've been curious about the surprising inertia behind that specification having played with IBM implementations in the past few years. Perhaps however, the immaturity of implementations in that space is a tribute to some of these arguments about coordination costs applied to the marketplace of data (relational, object relational, XML, SQL, XPath, XQuery, ActiveRecord, ODMA, Spring, Hibernate, SDO etc).

I wonder if the Atom store dream is the way to go, namely rather than apply the constraint of an API and a language, Java, in a world in which we have a Tower of Babel of languages and persistence frameworks, it makes more sense to focus on wire protocol (as in Atom Publishing protocol) and wire format say Atom. In other words the greater payoff would be not in establishing a programming model (the JCR) but rather in moving to Atompub which is agnostic on the underlying programming model and lowers the coordination costs by stripping a layer of comprehension from the mix. All this of course is modulo the quirks of compound documents, media collections etc...

The web worked because it was an overlay system that acknowledged existing systems and encoded much of its benefits in protocol rather than API. At the current stage of development in the software industry, it appears that the combination of protocol and data formats rather than API is the more effective approach to lowering coordination costs and dampening the human factor.

File under: REST, design, architecture, technology, coordination, economics, web, human factors, adoption, comprehension, costs, theory, systems, software, leverage, optimization, language, data, jcr, jsr170, toli