The Old Schoolhouse

I recently had my 10 year business school reunion. Being the business nerds we are, we had additional classes. Here are some thoughts from one of those:

Behavior Finance by Professor Malcolm Baker

From the session summary:
“At the foundation of finance theory is the idea that investors and managers act rationally… behavioral finance proposes a broader role for social, cognitive, and emotional biases”

Think of it as a bridge between psychology and economics. Economists, basically, work to find the underlying models that best describe how we make decisions in our lives. They don’t believe that we actually do complex math when deciding whether to buy the Tall vs. Grande, but they say, that on average, we all behave as if we were actually doing the the math. Do you wake up and think about your “Expected Utility”? You act like it. Psychologists focus more upon the times when individual act against their best interests. In other words, when their emotions or biases make them behave against the economists model. The press likes to point out the gap between the economists and psychologists, but it isn’t as wide as they paint.

One Hour Crash Course on Behavior Finance

Modified Kaynes Quote:

If you owe your your bank a hundred dollars, you have problem, but if you owe bank a billion dollars, the bank has a problem.

The market can stay irrational longer than you can stay solvent.

So are people rational? Here are a couple of possible observations and possible ways of answers:

* No, but this is the basis for our intuition.
* So ask yourself, do most homebuyers have good intuition for ARMs when buying a home?
Well, maybe. By metaphor, think about the expert pool/billiards player. He plays as if he were an expert in physics, but he isn’t. Economists like to work on the physics problems of billiards. Psychologists like to focus on the time when he chokes if he isn’t wearing he lucky socks.

* No, but we delegate this process to advisers, that do act rationally.
Should you delegate the deicsion to advisers? Imagine that you are thinking about buying a house. Your banks will push you buy, your agent will push you to buy, everyone but maybe your fianancial advisor will push you to buy. My wife and I recently bought a house a house and, apparently easily qualified for a mortgage (this is after the recent financial crisis). Now, the kicker is that the bank didn’t know about some additional income that I used to calculate our budget, because it wasn’t part of a salary. As far as our advisors knew, they were putting us into a house that we simply couldn’t afford, and they were doing this even after the recent financial crisis – so you can not trust your advisors when their interests are conflicted.

* No, but this is the way “smart money” makes decisions.
Do the capital markets price these correctly?

Framing matters:
So, when asked, people will have very different answer to a question when it is just framed differently.
So, imagine the following scenario: Given the recent H1N1 outbreak, which course of treatment, if you were the president, would you take:
Framing One Way:
*Option 1) A treatment where 400,000 people out of 1M will die, or 38%
*Option 2) 1/3 chance that no one will die and 2/3 chance that all 600,000 will die: 62%

Framing another way:
* Option 1) 200,000 people will be saved: 62%
* Option 2) 1/3 chance that 600,000 people will be saved, and 2/3 chance 400,000 will be saved: 38%

When a two groups of students where asked their recommended course of action, the percent of students that chose Option 1 when the question was framed the first exactly matched the percent of students that chose Option 2 when the question was framed the second way. Now, if you look at the two framings, they both represent the exact same outcomes, so there is no logical reason for the percentages to flip – it is just how it is presented.

Saturday Galla at Boston Public Library

So, how can we apply these insights into human nature to software development?

I would argue that this is important to software development in a couple of ways, namely for project management, technical risk assessment, and marketing.

Project Management:
Programmers are notorious for over-estimating their own productivity. When asked to estimate how long feature X will take to build, they will routinely be off by several hundred percent. Granted, often with good reason. Sometimes management changes the spec because managers greatly over-estimate their own ability to deliver a perfect and unchanging spec.. Sometimes more urgent project cause frequent interruptions, seriously undermining concentration and flow.

Framing: I’ve observed that when I have freelancers bid on a project, the price is quite different between when I am vague, but still accurate, and when I specify, in detail, the project details. The estimated price increases significantly by bidders by several hundred percent, even though, the detailed spec actually significantly lowers bidding risk.

Category framing: effort to do the project vs. the effort to do each identifiable effort.
When a bunch of students, about 160 of them, where asked to estimate what the temperates would be during March and April, they would artificially group their answers in large chunks according to the month instead of thinking about the pretty smooth change in weather between each day.

First Group: March 12th: 37.5F, March 24: 39.0 ( a 1.5F change over 12 days – but within same month).
Second group: March 24.5F, April 5, 48.8 (an insanely high 24.3 degree increase during 12 days, but the this last date they were asked to estimate was in a ‘hot’ month – so they cranked their estimates up to 11!)

Take away: the march / april barrier caused the estimators to pool their answers into two distinct groups instead of thinking about the answers as lying on a continuous scale, which they clearly were. People think about stuff in large categories, not on a continuous or high-resolution scale. For software developers, this makes us, I think, underestimate the work in involved for poorly specified projects and over-estimate the involved in well specified projects. I’ve observed this several times when outsources projects to freelancers. When I’m sort of vague, but accurate, about a project, the prices seem sort of low. When super well specified, the price for the same project inflates greatly. Unscrupulous Publishers might be able to take advantage of naive freelancers and consultants, and vice versa. Basically, be aware, and act accordingly, to avoid all around pain.

Self worth bias (most people think that they are above average): Time for somebody to do a project = 2X, time for me to do a project = 1X. How much should I be paid to do that project if I charge a fixed fee? What if I charge per hour? What is my hourly rate? What has my hourly rate actually been. Let’s call the Implied Rate the hourly wage calculated by taking the total project cost divided by how many hours a project took. I guess we figure there is no reason to track our time if we aren’t charging by the hour. In my experience, we programmers show a large internal inconsistency in our proclaimed hourly rate depending upon how the project is setup, hourly vs. flat fee, and we don’t go back to calculated our implied rate, even when taking things into considerations such as payment risk, self insurance, etc.

So, what can do about this?
Well, I’m certainly not in a position to fix the whole software development lifecycle problem, but I feel like I can suggest a couple of courses of action.
1 – Track your hours, even when working on own projects or flat-fee projects
2 – After every project, conduct a post-mortem to analyze why the project went off schedule (they all go off schedule)
3 – Develop and grow your own well-vetted library of software components to minimize custom develop of technology. Keep the custom development, and thus the schedule risk, to just the new business logic of the project.
4 – Do mockups to vet with the customer/stakeholders what, precisely, needs to be built before the code starts flying. Fixing mistakes in the design phase, as we know, is ten times cheaper than fixing them after coded.
5 – Well, I could go on.

I’m working on a new client project and I’m trying hard to apply these principles, but it isn’t easy. My client gave me a great spec, and I’m working on turning that into a working mock-up, to work out some previously unforeseen UI issues. I’m also refining my own library with an eye towards workflow. This might be a long process, but, in the long run, well worth it.

Further Reading
Books: Nudge, The upside of irrationality, Animal Spirit, Predictably Irrational
I haven’t read this yet, but it was referenced in the talk.

Video: Nova: Mind Over Money
This was my first introduction to modern Behavioral Finance. Really an easy way to quickly grasp the whole field. Recommended.

Innumeracy: Mathematical Illiteracy and Its Consequences (Maybe a stretch, but I really liked this when I first read it. It was a hit in its day but seems to have since faded.