Coding Horror

I recently read Predictably Irrational.

It's a fascinating examination of why human beings are wired and conditioned to react irrationally. We human beings are a selfish bunch, so it's all the more surprising to see how easily we can be manipulated to behave in ways that run counter to our own self-interest.

This isn't just a "gee-whiz" observation; understanding how and why we behave irrationally is important. If you don't understand how these irrational behaviors are triggered, the marketing weasels will use them against you.

In fact, it's already happening. Witness 10 Irrational Human Behaviors and How to Leverage Them to Improve Web Marketing. Don't say I didn't warn you.

Let's take a look at the various excerpts presented in that article, and consider how we can avoid falling into the rut of predictably irrational behavior – and defend ourselves from those vicious marketing weasels.

1. Encourage false comparisons

When Williams-Sonoma introduced bread machines, sales were slow. When they added a "deluxe" version that was 50% more expensive, they started flying off the shelves; the first bread machine now appeared to be a bargain

When contemplating the purchase of a $25 pen, the majority of subjects would drive to another store 15 minutes away to save $7. When contemplating the purchase of a $455 suit, the majority of subjects would not drive to another store 15 minutes away to save $7. The amount saved and time involved are the same, but people make very different choices. Watch out for relative thinking; it comes naturally to all of us.

• Realize that some premium options exist as decoys – that is, they are there only to make the less expensive options look more appealing, because they're easy to compare. Don't make binding decisions solely based on how easy it is to compare two side-by-side options from the same vendor. Try comparing all the alternatives, even those from other vendors.
• Don't be swayed by relative percentages for small dollar amounts. Yes, you saved 25%, but how much effort and time did you expend on that seven bucks?

2. Reinforce Anchoring

Savador Assael, the Pearl King, single-handedly created the market for black pearls, which were unknown in the industry before 1973. His first attempt to market the pearls was an utter failure; he didn't sell a single pearl. So he went to his friend, Harry Winston, and had Winston put them in the window of his 5th Avenue store with an outrageous price tag attached. Then he ran full page ads in glossy magazines with black pearls next to diamonds, rubies, and emeralds. Soon, black pearls were considered precious.

Simonsohn and Loewenstein found that people who move to a new city remain anchored to the prices they paid in their previous city. People who move from Lubbock to Pittsburgh squeeze their families into smaller houses to pay the same amount. People who move from LA to Pittsburgh don't save money, they just move into mansions.

• Scale your purchases to your needs, not your circumstances or wallet size. What do you actually use? How much do you use it, and how frequently?
• Try to objectively measure the value of what you're buying; don't be tricked into measuring relative to similar products or competitors. How much does buying this save you or your company? How much benefit will you get out of it? Attempt to measure that benefit by putting a concrete dollar amount on it.

3. It's "Free"!

Ariely, Shampanier, and Mazar conducted an experiment using Lindt truffles and Hershey's Kisses. When a truffle was $0.15 and a kiss was $0.01, 73% of subjects chose the truffle and 27% the Kiss. But when a truffle was $0.14 and a kiss was free, 69% chose the kiss and 31% the truffle.

According to standard economic theory, the price reduction shouldn't have lead to any behavior change, but it did.

Ariely's theory is that for normal transactions, we consider both upside and downside. But when something is free, we forget about the downside. "Free" makes us perceive what is being offered as immensely more valuable than it really is. Humans are loss-averse; when considering a normal purchase, loss-aversion comes into play. But when an item is free, there is no visible possibility of loss

• You will tend to overestimate the value of items you get for free. Resist this by viewing free stuff skeptically rather than welcoming it with open arms. If it was really that great, why would it be free?
• Free stuff often comes with well hidden and subtle strings attached. How will using a free service or obtaining a free item influence your future choices? What paid alternatives are you avoiding by choosing the free route, and why?
• How much effort will the free option cost you? Are there non-free options which would cost less in time or effort? How much is your time worth?
• When you use a free service or product, you are implicitly endorsing and encouraging the provider, effectively beating a path to their door. Is this something you are comfortable with?

4. Exploit social norms

The AARP asked lawyers to participate in a program where they would offer their services to needy employees for a discounted price of $30/hour. No dice. When the program manager instead asked if they'd offer their services for free, the lawyers overwhelmingly said they would participate

• Companies may appeal to your innate sense of community or public good to convince you to do their work at zero pay. Consider carefully before choosing to participate; what do you get out of contributing your time and effort? Is this truly a worthy cause? Would this be worth doing if it was a paid gig?
• When it comes to the web, make sure you aren't being turned into a digital sharecropper.

5. Design for Procrastination

Ariely conducted an experiment on his class. Students were required to write three papers. Ariely asked the first group to commit to dates by which they would turn in each paper. Late papers would be penalized 1% per day. There was no penalty for turning papers in early. The logical response is to commit to turning all three papers in on the last day of class. The second group was given no deadlines; all three papers were due in the last day of class. The third group was directed to turn their papers in on the 4th, 8th, and 12th weeks.

The results? Group 3 (imposed deadlines) got the best grades. Group 2 (no deadlines) got the worst grades, and Group 1 (self-selected deadlines) finished in the middle. Allowing students to pre-commit to deadlines improved performance. Students who spaced out their commitments did well; students who did the logical thing and gave no commitments did badly.

• Steer clear of offers of low-rate trial periods which auto-convert into automatic recurring monthly billing. They know that most people will procrastinate and forget to cancel before the recurring billing kicks in.
• Either favor fixed-rate, fixed-term plans – or become meticulous about cancelling recurring services when you're not using them.

6. Utilize the Endowment Effect

Ariely and Carmon conducted an experiment on Duke students, who sleep out for weeks to get basketball tickets; even those who sleep out are still subjected to a lottery at the end. Some students get tickets, some don't. The students who didn't get tickets told Ariely that they'd be willing to pay up to $170 for tickets. The students who did get the tickets told Ariely that they wouldn't accept less than $2,400 for their tickets.

There are three fundamental quirks of human nature. We fall in love with what we already have. We focus on what we might lose, rather than what we might gain. We assume that other people will see the transaction from the same perspective as we do.

• The value of what you've spent so far on a service, product, or relationship – in effort or money – is probably far less than you think. Be willing to walk away.
• Once you've bought something, never rely on your internal judgment to assess its value, because you're too close to it now. Ask other people what they'd pay for this service, product, or relationship. Objectively research what others pay online.

7. Capitalize on our Aversion to Loss

Ariely and Shin conducted an experiment on MIT students. They devised a computer game which offered players three doors: Red, Blue, and Green. You started with 100 clicks. You clicked to enter a room. Once in a room, each click netted you between 1-10 cents. You could also switch rooms (at the cost of a click). The rooms were programmed to provide different levels of rewards (there was variation within each room's payoffs, but it was pretty easy to tell which one provided the best payout).

Players tended to try all three rooms, figure out which one had the highest payout, and then spend all their time there. (These are MIT students we're talking about). Then, however, Ariely introduced a new wrinkle: Any door left unvisited for 12 clicks would disappear forever. With each click, the unclicked doors shrank by 1/12th.

Now, players jumped from door to door, trying to keep their options open.They made 15% less money; in fact, by choosing any of the doors and sticking with it, they could have made more money.

Ariely increased the cost of opening a door to 3 cents; no change–players still seemed compelled to keeping their options open. Ariely told participants the exact monetary payoff of each door; no change. Ariely allowed participants as many practice runs as they wanted before the actual experiment; no change. Ariely changed the rules so that any door could be "reincarnated" with a single click; no change.

Players just couldn't tolerate the idea of the loss, and so they did whatever was necessary to prevent their doors from closing, even though disappearance had no real consequences and could be easily reversed. We feel compelled to preserve options, even at great expense, even when it doesn't make sense.

• If your choices are artificially narrowed, don't passively get funneled towards the goal they're herding you toward. Demand choice, even if it means switching vendors or allegiances.
• Don't pay extra for options, unless you can point to hard evidence that you need those options. Some options exist just to make you doubt yourself, so you'll worry about not having them.

8. Engender Unreasonable Expectations

Ariely, Lee, and Frederick conducted yet another experiment on MIT students. They let students taste two different beers, and then choose to get a free pint of one of the brews. Brew A was Budweiser. Brew B was Budweiser, plus 2 drops of balsamic vinegar per ounce.

When students were not told about the nature of the beers, they overwhelmingly chose the balsamic beer. When students were told about the true nature of the beers, they overwhelmingly chose the Budweiser. If you tell people up front that something might be distasteful, the odds are good they'll end up agreeing with you–because of their expectations.

• Whatever you've heard about a brand, company, or product – there's no substitute for your own hands-on experience. Let your own opinions guide you, not the opinions of others.
• Just because something is labelled "premium" or "pro" or "award-winning" doesn't mean it is. Research these claims; don't let marketing set your expectations. Rely on evidence and facts.

9. Leverage Pricing Bias

Ariely, Waber, Shiv, and Carmon made up a fake painkiller, Veladone-Rx. An attractive woman in a business suit (with a faint Russian accent) told subjects that 92% of patients receiving VR reported significant pain relief in 10 minutes, with relief lasting up to 8 hours.

When told that the drug cost $2.50 per dose, nearly all of the subjects reported pain relief. When told that the drug cost $0.10 per dose, only half of the subjects reported pain relief. The more pain a person experienced, the more pronounced the effect. A similar study at U Iowa showed that students who paid list price for cold medications reported better medical outcomes than those who bought discount (but clinically identical) drugs.

• Price often has nothing to do with value. Expensive is not synonymous with quality. Investigate whether the price is justified; never accept it at face value.
• Don't fall prey to the "moneymoon"; just because you paid for something doesn't mean it's automatically worthwhile. Not everything we pay money for works well, or was even worth what we spent for it. We all make mistakes when buying things, but we don't want to admit it.

What I learned from Predictably Irrational is that everyone is irrational sometimes, and that's OK. We're not perfectly logical Vulcans, after all. The trick is training yourself to know when you're most likely to make irrational choices, and to resist those impulses.

If you aren't at least aware of our sad, irrational human condition, well … that's exactly where the marketing weasels want you.

Are you familar with happy talk?

If you're not sure whether something is happy talk, there's one sure-fire test: if you listen very closely while you're reading it, you can actually hear a tiny voice in the back of your head saying "Blah blah blah blah blah...."

A lot of happy talk is the kind of self-congratulatory promotional writing that you find in badly written brochures. Unlike good promotional copy, it conveys no useful information, and focuses on saying how great we are, as opposed to delineating what makes us great.

Happy talk is the kudzu of the internet; the place is lousy with the stuff.

And then there's the visual equivalent of happy talk. Those cloying, meaningless stock photos of happy users doing ... something ... with a computer.

What is going on here? Given the beatific expressions, you'd think they were undergoing some kind of nerd rapture. Maybe they're getting a sneak preview of the singularity, I don't know.

It's unclear to me why companies (and even some individuals) think they need happy talk, stock photos of multicultural computer users, or the occasional headset hottie. Jason Cohen provides an explanation:

Even before I had a single customer, I "knew" it was important to look professional. My website would need to look and feel like a "real company." I need culture-neutral language complimenting culturally-diverse clip-art photos of frighteningly chipper co-workers huddled around a laptop, awash with the thrill and delight of configuring a JDBC connection to SQL Server 2008.

It also means adopting typical "marketing-speak," so my "About Us" page started with:

Smart Bear is the leading provider of enterprise version control data-mining tools. Companies world-wide use Smart Bear's Code Historian software for risk-analysis, root-cause discovery, and software development decision-support.

"Leading provider?" "Data mining?" I'm not even sure what that means. But you have to give me credit for an impressive quantity of hyphens.

That's what you're supposed to do, right? That's what other companies do, so it must be right. Who am I to break with tradition?

I'm not sure where we got our ideas about this stuff, but it is true that some large companies promote a kind of doublespeak "professionalism". Kathy Sierra describes her experiences at Sun:

By the time I got to Sun, using the word "cool" in a customer training document was enough to warrant an entry in your annual performance eval. And not in a good way.

I cannot count the times I heard the word "professionalism" used as justification for why we couldn't do something. But I can count the few times I heard the word "passion" used in a meeting where the goal was to get developers to adopt our newest Java technologies. What changed?

Some argue that by maintaining strict professionalism, we can get the more conservative, professional clients and thus grow the business. Is this true? Do we really need these clients? Isn't it possible that we might even grow more if we became braver?

It's a shame that this misguided sense of professionalism is sometimes used as an excuse to put up weird, Orwellian communication barriers between yourself and the world. At best it is a facade to hide behind; at worst it encourages us to emulate so much of what is wrong with large companies. Allow me to paraphrase the simple advice of Elmore Leonard:

If it looks corporate, change it.

The next time you find yourself using professional text, or professional stock images, consider the value of this "professionalism". Is it legitimately helping you communicate? Or is it getting in the way?

The Gamasutra article Dirty Coding Tricks is a fantastic read. One part of it in particular rang true for me.

Consider the load of pain I found myself in when working on a conversion of a 3D third person shooter from the PC to the original PlayStation.

Now, the PS1 has no support for floating point numbers, so we were doing the conversion by basically recompiling the PC code and overloading all floats with fixed point. That actually worked fairly well, but were it fell apart was in collision detection.

The level geometry that was supplied to us worked reasonably well in the PC version of the game, but when converted to fixed point, all kinds of seams, T-Junctions and other problems were nudged into existence by the microscopic differences in values between fixed and floats. This problem would manifest itself by the main character (called "Damp") simply falling through those tiny holes, into the abyss below the level.

We patched the holes we found, tweaking the geometry until Damp no longer fell through. But then the game went into test at the publisher, and suddenly a flood of "falling off the world" bugs were delivered to us. Every day a fresh batch of locations were found with these little holes that Damp could slip through. We would fix that bit of geometry, then the next day they would send us ten more. This went on for several days. The publisher's test department employed one guy whose only job was to jump around the world for ten hours a day, looking for places he could fall through.

The problem here was that the geometry was bad. It was not tight and seamless geometry. It worked on the PC, but not on the PS1, where the fixed point math vastly magnified the problems. The ideal solution was to fix the geometry to make it seamless.

However, this was a vast task, impossible to do in the time available with our limited resources, so we were relying on the test department to find the problem areas for us.

There's never time to do it right, but there's always time to do it over. If this sounds familiar, you're not alone. I have at times found myself slipping into this pattern, continually patching the same code over and over. It's the kind of code that, when submitted for code review, you're tempted to self-deprecatingly introduce as have you met my dog, patches?

While "patchiness" isn't always a bad thing -- the venerable Apache HTTP Server is testament to that -- it's probably an exception.

the original FAQ on the Apache Server project's website, from 1996 to 2001, claimed that "The result after combining [the NCSA httpd patches] was a patchy server."

Reading the Gamasutra article shamed me into to attacking a section of extra-patchy Stack Overflow code. Code which I constantly had to tweak in various ongoing ways to get it to work right. But first, I had to get over my fear. Fear. That's what led to all the patching in the first place. It was obvious this was working code which had become crufty over time, but it was working. And it's one of the core bits of functionality in the site. In those circumstances, it's easy to mentally justify "just this small change, just this once" rather than the fundamental rewrite you really need.

When you finally realize you've spent the last six months telling yourself the same "just this small change, just this once" lie, then you've met your dog patches, too.

Now what are you going to do about that rascally scamp?

We may kid ourselves into thinking we're writing out of some sense of public good, or to create connections, or contribute some small bit of knowledge to the world. But let's face it. Most of us blog because we're raving egomaniacs. We not only love to hear ourselves talk, we're incredibly eager to hear other people talk about us, and the more the better. I think Dale Carnegie put it best.

Nothing is sweeter to someone's ears than their own name.

So it should come as no surprise that I have an automatic Google ego search set up for my name. Nothing special about that. It is considered neighborly to have your ear to the ground (within reason), and to politely comment on relevant articles mentioning you and your "stuff". All very standard, banal, ego-fluffing stuff.

But of all the mentions I've gotten, nobody has utterly nailed it in the way that Brian Gianforcaro has.

Right on. That's one thing you and I have in common, burny.

As a software developer, you are your own worst enemy. The sooner you realize that, the better off you'll be. In fact, that's the tipping point between amateurs and professionals in our industry: the professionals realize everything they write sucks.

So, to the extent that I can become a conduit for other programmers to have that same epiphany in their own programming careers, that means it's working.

Do you remember Microsoft Bob? If you do, you probably remember it as an intensely marketed but laughable failure – what some call the "number one flop" at Microsoft.

There's no question that Microsoft Bob was nothing short of an unmitigated disaster. But that's the funny thing about failures – they often lead to later successes. Take it from someone who lived and breathed the Bob project:

I was the one who sent Bill Gates email at the height of the positive Bob-mania that said we were likely to face a horrible backlash. Tech influentials had started telling me that they were going to bury Bob. They not only didn't like it, they were somehow angry that it had even been developed. It was personal.

And that's exactly what happened. Bob got killed. But first, it was ridiculed and stomped.

For Microsoft, it was a costly mistake. For the people who worked on it, Bob taught many lessons. Lessons that came into play for subsequent products that made a big impact, both at Microsoft and beyond.

How many people know that the lead developer for Bob 2.0 was also the co-founder of Valve and the development lead for Half-Life, which became an industry phenomenon, winning more than 50 Game of the Year awards and selling more than 10 million copies?

Or that Darrin Massena - development lead for Bob 1.0, most recently named Technical Innovator of the Year here in Washington State - and Valve co-founder Mike Harrington are the co-founders and partners behind Picnik - which is now the world's leading online photo editor, attracting almost 40 million visits a month and a million unique users a day.

And then, of course, I'd be remiss if I didn't mention that Melinda French – Bill Gates' future wife – managed the Microsoft Bob project at one point. Bob was the first Microsoft consumer project that Bill Gates personally had a hand in launching. Well, at least he got a wife out of it.

Yes, Bob was an obvious, undisputed and epic failure. We can point and laugh at Bob. But to me, Bob is less of a comic figure than a tragic one.

Unless you're an exceptionally lucky software developer, you've probably worked on more projects that failed than projects that succeeded. Failure is de rigeur in our industry. Odds are, you're working on a project that will fail right now. Oh sure, it may not seem like a failure yet. Maybe it'll fail in some completely unanticipated way. Heck, maybe your project will buck the odds and even succeed.

But I doubt it.

I own a boxed copy of Microsoft Bob. I keep it on my shelf to remind me that these kinds of relentless, inevitable failures aren't the crushing setbacks they often appear from the outside. On the contrary; I believe it's impossible to succeed without failing.

Charles Bosk, a sociologist at the University of Pennsylvania, once conducted a set of interviews with young doctors who had either resigned or been fired from neurosurgery-training programs, in an effort to figure out what separated the unsuccessful surgeons from their successful counterparts.

He concluded that, far more than technical skills or intelligence, what was necessary for success was the sort of attitude that Quest has – a practical-minded obsession with the possibility and the consequences of failure. "When I interviewed the surgeons who were fired, I used to leave the interview shaking," Bosk said. "I would hear these horrible stories about what they did wrong, but the thing was that they didn't know that what they did was wrong. In my interviewing, I began to develop what I thought was an indicator of whether someone was going to be a good surgeon or not. It was a couple of simple questions: Have you ever made a mistake? And, if so, what was your worst mistake? The people who said, 'Gee, I haven't really had one,' or, 'I've had a couple of bad outcomes but they were due to things outside my control' – invariably those were the worst candidates. And the residents who said, 'I make mistakes all the time. There was this horrible thing that happened just yesterday and here's what it was.' They were the best. They had the ability to rethink everything that they'd done and imagine how they might have done it differently."

I recently watched the documentary Tilt: The Battle to Save Pinball.

It's a gripping story of a pinball industry in crisis. In order to save it, the engineers at Williams – the only remaining manufacturer of pinball machines in the United States – were given a herculean task: invent a new form of pinball so compelling that it makes all previous pinball machines seem obsolete. I don't want to spoil the whole documentary, so I'll gloss over exactly how that happened, but astoundingly enough – they succeeded.

And then were promptly laid off en masse, as Williams shut down its pinball operations.

Unlike Microsoft Bob, the Williams engineers built an almost revolutionary product that was both critically acclaimed and sold well – but none of that mattered. It's sobering to watch the end reel of Tilt, as the engineers involved mournfully discuss the termination of their bold and seemingly successful project.

Everyone was in awe. They couldn't understand why it happened. Here we'd just done this thing that from all we could tell was a total success. Why would they do that?

We succeeded. Management gave us an impossible goal, and we sat there and we actually did what they thought we couldn't do.

You know, we didn't really win... we lost. I gave it everything I had. I think that those fifty guys that worked on it, they also passionately did everything that they could.

Sometimes, even when your project succeeds, you've failed. Due to forces entirely beyond your control. It's depressing, but it's reality.

The trailout isn't all doom and gloom. It also documents the ways in which these talented pinball engineers went on to practice their craft after being laid off. Most of them still work in the video game or pinball industry. Some freelance. Others formed their own companies. A few went on to work at Stern Pinball, which figured out how to make a small number of pinball machines and still turn a profit.

These two stories, these two projects – the abject failure of Microsoft Bob, and the aborted success of Pinball 2000 – have something in common beyond mere failure. All the engineers involved not only survived these failures, but often went on to greater success afterwards. Possibly as a direct result of their work on these "failures".

Failure is a wonderful teacher. But there's no need to seek out failure. It will find you. Whatever project you're working on, consider it an opportunity to learn and practice your craft. It's worth doing because, well, it's worth doing. The journey of the project should be its own reward, regardless of whatever happens to lie at the end of that journey.

The only truly failed project is the one where you didn't learn anything along the way.