Category / Reading Lists

by Joel Spolsky

How to demo software

It’s already all a blur. 26 cities. 6 weeks. 2913 attendees. $160,000. 23 hotels, one Cambridge college, one British library, and a “Sociëteit Het Meisjeshuis.” (“Gesundheit!”)

Somewhere, I don’t know where, I’m standing exhausted outside a hotel ballroom right after the umpteenth demo, and someone is giving me some ridiculous objection. “Well, it’s all good and fine what FogBugz does, but we won’t use it, because we need PROJECT MANAGEMENT.”

Excuse me, SIR? Do you have some kind of SUDDEN AMNESIA? Traumatic HEAD INJURY maybe? Did you WATCH the demo?

(I didn’t really say that.)

While I was trying to think of a nice way to reply, another potential customer, standing right there, says to the guy, “Why not try it out on a little project? Won’t cost you anything.”

A bit flips. The guy suddenly stops shaking his head and starts nodding it. “Yeah, that’s a good idea. I’ll do that,” he says, smiling. SOLD.

WTF just happened.

No matter how much I talk, I’m just one person. And no matter how much I try to sell people on FogBugz, it’s all coming from me, so that can only add up to a certain amount of credibility, and it just wasn’t passing the credibility threshold for Mr. Amnesia. It wouldn’t matter what I said. He was in “I object!” mode, groping around for some reason not to buy FogBugz, even if he couldn’t come up with anything rational.

The minute a second person—his doppelganger! Same height! Same grey hair! Dressed just like him!—said something, BLING! It was like triangulation. Oooooh! Now he’s seeing it from two different angles. It’s 3D. Must not be an optical illusion.

Social proof, Robert Cialdini calls it. That gave me an idea. I knew from the registration forms that in every city, about 30% of the attendees were already using FogBugz. I started asking a question at the beginning of the demo: “How many people here use FogBugz?” Hands go up. That’s nice. Everybody looks around. Wow, they think. People actually use this software. It’s not just some downloadable piece of shareware some guy wrote in his basement. I started getting comments like, “I didn’t realize so many people in Austin were already using FogBugz!”

The one thing you can say about the 26 public FogBugz demos that I just did is that the first one (Vancouver) was pretty weak, and the last one (Copenhagen) was much, much better, and it was pretty much continuous improvement along the way. If you ever have to do a public demo of your software, here are some of those things that I learned.

Biggest turnouts

FogBugz World Tour

  1. London
  2. Toronto
  3. Seattle
  4. Austin
  5. Boston
  6. Arlington, VA
  7. Amsterdam
  8. Vancouver
  9. Dublin
  10. Denver (Boulder)
  11. Cambridge, England
  12. San Francisco
  13. Mountain View, CA
  14. Dallas
  15. New York
  16. Atlanta
  17. Copenhagen
  18. San Diego
  19. Waterloo
  20. Emeryville, CA

Picking cities

It’s a good thing we did a survey to figure out where to go, because the number of attendees in each city was nothing like we expected. If you can only go to five cities, go to London, Toronto, Seattle, Austin, and Boston. Notice I didn’t say San Francisco or Silicon Valley. Those were 12 and 13 on our list, respectively. I have no explanation for this, other than that the huge tech community in the valley has so many damn opportunities to go to tech demos that they find them boring. Shown at right are the 20 biggest turnouts we got for the FogBugz demo.

Booking the room

If you have any control whatsoever over the place where the demo is going to take place, here are three things you absolutely have to do.

  1. Get the nicest venue in town. Big, shiny, sparkly, modern, glass and marble and wood everywhere. Your prospective customers start out with no visual image to associate with your company. The demo is the one image that’s going to stick in their head. It has to be nice. We weren’t as careful about this as we should have been, and booked a couple of frightful old relics before we realized what a bad impression we were making. Before you try hotels, look for libraries, museums, and universities: many of went into debt building beautiful, modern lecture halls and now they’re trying to rent them out to pay for all that nice blond wood paneling and the 265 built-in powered Bose speakers.
  2. Get a room that is exactly the right size. You’d much rather have a packed room with a people standing in the back and the hotel staff rushing to set up a few more rows of chairs. This is far better than a half-empty room where the audience feels like maybe this isn’t really the hottest tech event ever to hit Kitchener, Ontario. Most hotel rooms can be set up “theater style” (just rows of chairs) or “classroom style” (chairs and desks). They can fit in twice as many chairs theater style. That gives you plenty of flexibility after you book the room to change the layout so the room feels full.
  3. Get a room with very high ceilings. You’re going to be doing a demo on screen. Everyone has to be able to see it. Usually hotels have two kinds of rooms: smaller meeting rooms, with low ceilings, and ballrooms, with high ceilings. In the meeting rooms, it’s impossible to put the screen high enough for everyone to see it. Don’t trust the hotel on this. We were careful to ask every hotel if the screen was going to be visible throughout the room. They always told us it would. They were almost always lying. Just ask for the ceiling height of the room. They’re not smart enough to lie about that.

Setting the stage

Serve coffee. Coffee contains caffeine, which makes people cheerful. If you’re lucky, they’ll attribute their cheeriness to your software instead of the caffeine.

Play upbeat music while you’re waiting for everyone to arrive. The kind of popular, upbeat, Margaritaville music Americans love to listen to when they’re on vacations in warm places. Give people name tags so they introduce themselves to one another and socialize while they’re waiting. Crank up the music so they have to speak loudly. Loud music and loud conversation and a crowded room adds up to the sensation that this is the hot event.

Cover the place in professionally-produced, high-quality logo stuff. We had brochures, pens, pads, and big FogBugz banners. Wall-to-wall kiwis.

Dress exactly one level better than your audience. Too dressy, and you’ll look like you think you’re better than your customers. Not dressy enough, and the audience will get the feeling that you don’t really care.

With geeks, it’s probably enough to put on a nice Banana Republic black jacket over your polo shirt or turtleneck. Do NOT, for the LOVE OF ALL THAT IS GOOD, wear any clothing with writing on the outside. I know how much you love your JavaOne T-shirt, with the happy little waving tooth. Wear that to your wedding or something, not when you’re on stage. Lose the sneakers, too.

Set the screen to 800 x 600. Make everything as big as possible. If you’re demoing an application that needs more than a half million pixels, go back home and redesign the app.

Notice the lights shining on the screen? That’ll be a problem. Find the guy who can turn them off. Sometimes there’s no switch for those particular lights. Find the guy who will come with a ladder and unscrew them.

Lock the doors until the room is ready. Otherwise people will start wandering in an hour and a half before the demo is due to start watching you change out of your beloved t-shirt, running around taping cables down on the floor, and putting brochures on every chair. This makes you look like a gopher and removes some of the authority you’re going to need to convince people to buy your software.

Bring someone with you to take care of mechanical details: passing out nametags, setting up microphones. The more people you have with you, the more legit you’ll look.

Blow them away

A common, but boring, way to design a demo is to start by stating the problem, and then explaining how your magical software solves that problem. Another boring way to design a demo is with PowerPoint slides and lots of bullet points. An incredibly boring way to design a demo is to talk about your company and how many employees you have and how many millions of kroner of revenue you make every year. Nobody cares.

The only interesting way to design a demo is to make it a story. You have a protagonist, and the protagonist has a problem, and they use the software, and they… almost solve the problem, but not quite, and then everybody is in suspense, while you tell them some boring stuff that doesn’t fit anywhere else, but they’re still listening raptly because they’re waiting to hear the resolution to the suspenseful story, and then (ah!) you solve the protagonists last problem, and all is well. There is a reason people have been sitting around telling stories around campfires for the last million years or so: people like stories.

One of the stories from the FogBugz demo: Your boss asks you when you’re going to ship, and you look at the EBS report and discover that you only have a 6% chance of making it on time, so you suggest ditching low priority features, and that doesn’t go over very well, so you drill down to the individual developer’s schedules and… (pause for long lecture on EBS algorithm) …you realize that Milton needs some help making his estimates better, and Jane needs to give some of her work to Brandon, and then you can ship on time. Ta da!

As you go along, be sure to accidentally bump into all the nice little “fit and finish” features of your product. Oh look, that column is halfway off screen. No problem. I’ll just drag it over. (“Wha!” the audience gasps, “you dragged a column in HTML?”) Oh, look, this feature is supposed to be done by next Tuesday. I’ll type “next tuesday” in the due date box. (“OMG!” they squeal. You typed “next tuesday” and it was replaced with “11/20/2007”). Those nice little touches you put so much hard work into are not the meat of the demo, so don’t talk about them, just act nonchalant. What, doesn’t every web app let you resize and drag columns?

As you go through your speech, make sure you say all the important points two ways. People tend to daydream a bit. They may have missed your point the first time. They might not be native speakers—maybe one of the words or expressions that you used is not in their vocabulary. Don’t repeat the exact same sentence twice, which is annoying and pompous. Word it differently the second time.

If you’re not an experienced public speaker, watch a videotape of yourself. Have your colleagues give you brutal and honest feedback. You may be discover that you’re doing really annoying things while you speak: fidgeting with a pen, scratching your nose (on the outside!), whatever.

As you do demos, pay close attention to what works, and what doesn’t. Vary things a little bit every time… you might stumble on better ways of doing things. The first FogBugz demo in Vancouver started with two (lame) jokes. By the time I got to Copenhagen, I had stumbled on about ten jokes that made the whole audience laugh. I had better answers to questions. I even discovered better ways to do things in FogBugz. As time goes on, if you let the demo evolve, it’ll get better and better. You can practice in front of a mirror or your colleagues, and indeed, you should, but that only gets you so far… there’s nothing like a live audience to refine a demo. (By the way, that’s why you still find Jerry Seinfeld showing up unannounced at little hole-in-the-wall comedy clubs in New York. He’s testing material.)

Follow up

Ever wonder what the difference is between sales and marketing?

The official definition is that marketing creates demand, while sales fulfils demand.

Giving demos is marketing, not sales.

You need both the pull of marketing and the push of sales to actually sell products. It’s like trying to clean out the inside of an alligator with a rope: one guy has to pull on the rope from the back, the other guy has to feed the rope in the front. Following up means contacting people who came to the demo, finding out if they have questions, answering their objections, and doing a normal sales process. It doesn’t mean being pushy or slimy. It’s just recognizing that even the people who showed up and liked your product might go back to the office and have other things to work on, and weeks might pass and they might forget the warm fuzzy feeling they got from seeing your great thing, and they might never buy it unless you call them and ask for the sale.

I screwed up the sales part. I didn’t really plan in advance for the dramatic increase in customer interest in FogBugz 6.0 that the world tour drummed up, so right now there aren’t enough people at Fog Creek to follow up with every lead… we’re struggling to keep our heads above water just answering incoming questions, which have roughly tripled since 6.0 shipped. We’re getting thousands of people making FogBugz trials, so while I was in Malmö, Babak and Michael put $65,000 worth of new servers on my credit card to handle the demand. This is what I always told myself would be “a good problem to have,” but it’s a problem, nonetheless. As a bootstrapped company we didn’t really have the luxury of hiring in advance of anticipated demand, but now that the demand has materialized, we gotta hire some more great people, stat. If you’re smart and get things done, please apply for a job at Fog Creek.

by Joel Spolsky

Evidence Based Scheduling

Software developers don’t really like to make schedules. Usually, they try to get away without one. “It’ll be done when it’s done!” they say, expecting that such a brave, funny zinger will reduce their boss to a fit of giggles, and in the ensuing joviality, the schedule will be forgotten.

Most of the schedules you do see are halfhearted attempts. They’re stored on a file share somewhere and completely forgotten. When these teams ship, two years late, that weird guy with the file cabinet in his office brings the old printout to the post mortem, and everyone has a good laugh. “Hey look! We allowed two weeks for rewriting from scratch in Ruby!”

Hilarious! If you’re still in business.

You want to be spending your time on things that get the most bang for the buck. And you can’t figure out how much buck your bang is going to cost without knowing how long it’s going to take. When you have to decide between the “animated paperclip” feature and the “more financial functions” feature, you really need to know how much time each will take.

Why won’t developers make schedules? Two reasons. One: it’s a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it’s not going to be right?

Over the last year or so at Fog Creek we’ve been developing a system that’s so easy even our grouchiest developers are willing to go along with it. And as far as we can tell, it produces extremely reliable schedules. It’s called Evidence-Based Scheduling, or EBS. You gather evidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date. It looks like this:

The steeper the curve, the more confident you are that the ship date is real.

Here’s how you do it.

1) Break ‘er down

When I see a schedule measured in days, or even weeks, I know it’s not going to work. You have to break your schedule into very small tasks that can be measured in hours. Nothing longer than 16 hours.

This forces you to actually figure out what you are going to do. Write subroutine foo. Create this dialog box. Parse the Fizzbott file. Individual development tasks are easy to estimate, because you’ve written subroutines, created dialogs, and parsed files before.

If you are sloppy, and pick big three-week tasks (e.g., “Implement Ajax photo editor”), then you haven’t thought about what you are going to do. In detail. Step by step. And when you haven’t thought about what you’re going to do, you can’t know how long it will take.

Setting a 16-hour maximum forces you to design the damn feature. If you have a hand-wavy three week feature called “Ajax photo editor” without a detailed design, I’m sorry to be the one to break it to you but you are officially doomed. You never thought about the steps it’s going to take and you’re sure to be forgetting a lot of them.

2) Track elapsed time

It’s hard to get individual estimates exactly right. How do you account for interruptions, unpredictable bugs, status meetings, and the semiannual Windows Tithe Day when you have to reinstall everything from scratch on your main development box? Heck, even without all that stuff, how can you tell exactly how long it’s going to take to implement a given subroutine?

You can’t, really.

So, keep timesheets. Keep track of how long you spend working on each task. Then you can go back and see how long things took relative to the estimate. For each developer, you’ll be collecting data like this:

Each point on the chart is one completed task, with the estimate and actual times for that task. When you divide estimate by actual, you get velocity: how fast the task was done relative to estimate. Over time, for each developer, you’ll collect a history of velocities.

  • The mythical perfect estimator, who exists only in your imagination, always gets every estimate exactly right. So their velocity history is {1, 1, 1, 1, 1, …}
  • A typical bad estimator has velocities all over the map, for example {0.1, 0.5, 1.7, 0.2, 1.2, 0.9, 13.0}
  • Most estimators get the scale wrong but the relative estimates right. Everything takes longer than expected, because the estimate didn’t account for bug fixing, committee meetings, coffee breaks, and that crazy boss who interrupts all the time. This common estimator has very consistent velocities, but they’re below 1.0. For example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}

As estimators gain more experience, their estimating skills improve. So throw away any velocities older than, say, six months.

If you have a new estimator on your team, who doesn’t have a track record, assume the worst: give them a fake history with a wide range of velocities, until they’ve finished a half-dozen real tasks.

3) Simulate the future

Rather than just adding up estimates to get a single ship date, which sounds right but gives you a profoundly wrong result, you’re going to use the Monte Carlo method to simulate many possible futures. In a Monte Carlo simulation, you can create 100 possible scenarios for the future. Each of these possible futures has 1% probability, so you can make a chart of the probability that you will ship by any given date.

While calculating each possible future for a given developer, you’re going divide each task’s estimate by a randomly-selected velocity from that developer’s historical velocities, which we’ve been gathering in step 2. Here’s one sample future:

Estimate: 4 8 2 8 16
Random Velocity: 0.6 0.5 0.6 0.6 0.5 Total:
E/V: 6.7 16 3.3 13.3 32 71.3

Do that 100 times; each total has 1% probability, and now you can figure out the probability that you will ship on any given date.

Now watch what happens:

  • In the case of the mythical perfect estimator, all velocities are 1. Dividing by a velocity which is always 1 has no effect. Thus, all rounds of the simulation give the same ship date, and that ship date has 100% probability. Just like in the fairy tales!
  • The bad estimator’s velocities are all over the map. 0.1 and 13.0 are just as likely. Each round of the simulation is going to produce a very different result, because when you divide by random velocities you get very different numbers each time. The probability distribution curve you get will be very shallow, showing an equal chance of shipping tomorrow or in the far future. That’s still useful information to get, by the way: it tells you that you shouldn’t have confidence in the predicted ship dates.
  • The common estimator has a lot of velocities that are pretty close to each other, for example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}. When you divide by these velocities you increase the amount of time something takes, so in one iteration, an 8-hour task might 13 hours; in another it might take 15 hours. That compensates for the estimators perpetual optimism. And it compensates precisely, based exactly on this developers actual, proven, historical optimism. And since all the historical velocities are pretty close, hovering around 0.6, when you run each round of the simulation, you’ll get pretty similar numbers, so you’ll wind up with a narrow range of possible ship dates.

In each round of the Monte Carlo simulation, of course, you have to convert the hourly data to calendar data, which means you have to take into account each developer’s work schedule, vacations, holidays, etc. And then you have to see, for each round, which developer is finishing last, because that’s when the whole team will be done. These calculations are painstaking, but luckily, painstaking is what computers are good at.

Obsessive-compulsive disorder not required

What do you do about the boss who interrupts you all the time with long-winded stories about his fishing trips? Or the sales meetings you’re forced to go to even though you have no reason to be there? Coffee breaks? Spending half a day helping the new guy get his dev environment set up?

When Brett and I were developing this technique at Fog Creek, we worried a lot about things that take real time but can’t be predicted in advance. Sometimes, this all adds up to more time than writing code. Should you have estimates for this stuff too, and track it on a time sheet?

Well, yeah, you can, if you want. And Evidence Based Scheduling will work.

But you don’t have to.

It turns out that EBS works so well that all you have to do is keep the clock running on whatever task you were doing when the interruption occurred. As disconcerting as this may sound, EBS produces the best results when you do this.

Let me walk you through a quick example. To make this example as simple as possible, I’m going to imagine a very predictable programmer, John, whose whole job is writing those one-line getter and setter functions that inferior programming languages require. All day long this is all he does:

private int width;
public int getWidth () { return width; }
public void setWidth (int _width} { width = _width; }

I know, I know… it’s a deliberately dumb example, but you know you’ve met someone like this.

Anyway. Each getter or setter takes him 2 hours. So his task estimates look like this:

{2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, … }

Now, this poor guy has a boss who interrupts him every once in a while with a two-hour conversation about marlin fishing. Now, of course, John could have a task on his schedule called “Painful conversations about marlin,” and put that on his timesheet, but this might not be politically prudent. Instead, John just keeps the clock running. So his actual times look like this:

{2, 2, 2, 2, 4, 2, 2, 2, 2, 4, 2, … }

And his velocities are:

{1, 1, 1, 1, 0.5, 1, 1, 1, 1, 0.5, 1, … }

Now think about what happens. In the Monte Carlo simulation, the probability that each estimate will be divided by 0.5 is exactly the same as the probability that John’s boss would interrupt him during any given feature. So EBS produces a correct schedule!

In fact, EBS is far more likely to have accurate evidence about these interruptions than even the most timesheet-obsessive developer. Which is exactly why it works so well. Here’s how I explain this to people. When developers get interrupted, they can either

  1. make a big stink about putting the interruption on their timesheet and in their estimates, so management can see just how much time is being wasted on fishing conversation, or
  2. make a big stink about refusing to put it on their timesheet, just letting the feature they were working on slip, because they refuse to pad their estimates which were perfectly correct with stupid conversation about fishing expeditions to which they weren’t even invited,

… and in either case, EBS gives the same, exactly correct results, no matter which type of passive-aggressive developer you have.

4) Manage your projects actively

Once you’ve got this set up, you can actively manage projects to ship on time. For example, if you sort features out into different priorities, it’s easy to see how much it would help the schedule if you could cut the lower priority features.

You can also look at the distribution of possible ship dates for each developer:

Some developers (like Milton in this picture) may be causing problems because their ship dates are so uncertain: they need to work on learning to estimate better. Other developers (like Jane) have very precise ship dates that are just too late: they need to have some of their work taken off their plate. Other developers (me! yay!) are not on the critical path at all, and can be left in peace.

Scope creep

Assuming you had everything planned down to the last detail when you started work, EBS works great. To be honest, though, you may do some features that you hadn’t planned. You get new ideas, your salespeople sell features you don’t have, and somebody on the board of directors comes up with a cool new idea to make your golf cart GPS application monitor EKGs while golfers are buzzing around the golf course. All this leads to delays that could not have been predicted when you did the original schedule.

Ideally, you have a bunch of buffer for this. In fact, go ahead and build buffer into your original schedule for:

  1. New feature ideas
  2. Responding to the competition
  3. Integration (getting everyone’s code to work together when it’s merged)
  4. Debugging time
  5. Usability testing (and incorporating the results of those tests into the product).
  6. Beta tests

So now, when new features come up, you can slice off a piece of the appropriate buffer and use it for the new feature.

What happens if you’re still adding features and you’ve run out of buffer? Well, now the ship dates you get out of EBS start slipping. You should take a snapshot of the ship date confidence distribution every night, so that you can track this over time:

The x-axis is when the calculation was done; the y-axis is the ship date. There are three curves here: the top one is the 95% probability date, the middle is 50% and the bottom is 5%. So, the closer the curves are to one another, the narrower the range of possible ship dates.

If you see ship date getting later and later (rising curves), you’re in trouble. If it’s getting later by more than one day per day, you’re adding work faster than you’re completing work, and you’ll never be done. You can also look and see if the ship date confidence distribution is getting tighter (the curves are converging), which it should be if you’re really converging on a date.

While we’re at it

Here are a few more things I’ve learned over the years about schedules.

1) Only the programmer doing the work can create the estimate. Any system where management writes a schedule and hands it off to programmers is doomed to fail. Only the programmer who is going to implement a feature can figure out what steps they will need to take to implement that feature.

2) Fix bugs as you find them, and charge the time back to the original task. You can’t schedule a single bug fix in advance, because you don’t know what bugs you’re going to have. When bugs are found in new code, charge the time to the original task that you implemented incorrectly. This will help EBS predict the time it takes to get fully debugged code, not just working code.

3) Don’t let managers badger developers into shorter estimates. Many rookie software managers think that they can “motivate” their programmers to work faster by giving them nice, “tight” (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I’m behind schedule, I feel doomed and depressed and unmotivated. When I’m working ahead of schedule, I’m cheerful and productive. The schedule is not the place to play psychological games.

Why do managers try this?

When the project begins, the technical managers go off, meet with the business people, and come up with a list of features they think would take about three months, but which would really take twelve. When you think of writing code without thinking about all the steps you have to take, it always seems like it will take n time, when in reality it will probably take more like 4n time. When you do a real schedule, you add up all the tasks and realize that the project is going to take much longer than originally thought. The business people are unhappy.

Inept managers try to address this by figuring out how to get people to work faster. This is not very realistic. You might be able to hire more people, but they need to get up to speed and will probably be working at 50% efficiency for several months (and dragging down the efficiency of the people who have to mentor them).

You might be able to get 10% more raw code out of people temporarily at the cost of having them burn out 100% in a year. Not a big gain, and it’s a bit like eating your seed corn. Of course, when you overwork people, debugging time doubles and a late project becomes later. Splendid karma.

But you can never get 4n from n, ever, and if you think you can, please email me the stock symbol for your company so I can short it.

4) A schedule is a box of wood blocks. If you have a bunch of wood blocks, and you can’t fit them into a box, you have two choices: get a bigger box, or remove some blocks. If you wanted to ship in six months, but you have twelve months on the schedule, you are either going to have to delay shipping, or find some features to delete. You just can’t shrink the blocks, and if you pretend you can, then you are merely depriving yourself of a useful opportunity to actually see into the future by lying to yourself about what you see there.

Now that I mention it, one of the great benefits of realistic schedules is that you are forced to delete features. Why is this good?

Suppose you have two features in mind. One is really useful and will make your product really great. The other is really easy and the programmers can’t wait to code it up (”Look! <blink>!”), but it serves no useful purpose.

If you don’t make a schedule, the programmers will do the easy/fun feature first. Then they’ll run out of time, and you will have no choice but to slip the schedule to do the useful/important feature.

If you do make a schedule, even before you start working, you’ll realize that you have to cut something, so you’ll cut the easy/fun feature and just do the useful/important feature. By forcing yourself to chose some features to cut, you wind up making a more powerful, better product with a better mix of good features that ships sooner.

Way back when I was working on Excel 5, our initial feature list was huge and would have gone way over schedule. “Oh my!” we thought. “Those are all super important features! How can we live without a macro editing wizard?”

As it turns out, we had no choice, and we cut what we thought was “to the bone” to make the schedule. Everybody felt unhappy about the cuts. To make people feel better, we told ourselves that we weren’t cutting the features, we were simply deferring them to Excel 6.

As Excel 5 was nearing completion, I started working on the Excel 6 spec with a colleague, Eric Michelman. We sat down to go through the list of “Excel 6” features that had been punted from the Excel 5 schedule. Guess what? It was the shoddiest list of features you could imagine. Not one of those features was worth doing. I don’t think a single one of them ever was. The process of culling features to fit a schedule was the best thing we could have done. If we hadn’t done this, Excel 5 would have taken twice as long and included 50% useless crap features that would have had to be supported, for backwards compatibility, until the end of time.

Summary

Using Evidence-Based Scheduling is pretty easy: it will take you a day or two at the beginning of every iteration to produce detailed estimates, and it’ll take a few seconds every day to record when you start working on a new task on a timesheet. The benefits, though, are huge: realistic schedules.

Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.

P.S.

Evidence Based Scheduling is built into FogBugz 6.0.

by Joel Spolsky

Strategy Letter VI

IBM just released an open-source office suite called IBM Lotus Symphony. Sounds like Yet Another StarOffice distribution. But I suspect they’re probably trying to wipe out the memory of the original Lotus Symphony, which had been hyped as the Second Coming and which fell totally flat. It was the software equivalent of Gigli.

In the late 80s, Lotus was trying very hard to figure out what to do next with their flagship spreadsheet and graphics product, Lotus 1-2-3. There were two obvious ideas: first, they could add more features. Word processing, say. This product was called Symphony. Another idea which seemed obvious was to make a 3-D spreadsheet. That became 1-2-3 version 3.0.

Both ideas ran head-first into a serious problem: the old DOS 640K memory limitation. IBM was starting to ship a few computers with 80286 chips, which could address more memory, but Lotus didn’t think there was a big enough market for software that needed a $10,000 computer to run. So they squeezed and squeezed. They spent 18 months cramming 1-2-3 for DOS into 640K, and eventually, after a lot of wasted time, had to give up the 3D feature to get it to fit. In the case of Symphony, they just chopped features left and right.

Neither strategy was right. By the time 123 3.0 was shipping, everybody had 80386s with 2M or 4M of RAM. And Symphony had an inadequate spreadsheet, an inadequate word processor, and some other inadequate bits.

“That’s nice, old man,” you say. “Who gives a fart about some old character mode software?”

Humor me for a minute, because history is repeating itself, in three different ways, and the smart strategy is to bet on the same results.

Limited-memory, limited-CPU environments

From the beginning of time until about, say, 1989, programmers were extremely concerned with efficiency. There just wasn’t that much memory and there just weren’t that many CPU cycles.

In the late 90s a couple of companies, including Microsoft and Apple, noticed (just a little bit sooner than anyone else) that Moore’s Law meant that they shouldn’t think too hard about performance and memory usage… just build cool stuff, and wait for the hardware to catch up. Microsoft first shipped Excel for Windows when 80386s were too expensive to buy, but they were patient. Within a couple of years, the 80386SX came out, and anybody who could afford a $1500 clone could run Excel.

As a programmer, thanks to plummeting memory prices, and CPU speeds doubling every year, you had a choice. You could spend six months rewriting your inner loops in Assembler, or take six months off to play drums in a rock and roll band, and in either case, your program would run faster. Assembler programmers don’t have groupies.

So, we don’t care about performance or optimization much anymore.

Except in one place: JavaScript running on browsers in AJAX applications. And since that’s the direction almost all software development is moving, that’s a big deal.

A lot of today’s AJAX applications have a meg or more of client side code. This time, it’s not the RAM or CPU cycles that are scarce: it’s the download bandwidth and the compile time. Either way, you really have to squeeze to get complex AJAX apps to perform well.

History, though, is repeating itself. Bandwidth is getting cheaper. People are figuring out how to precompile JavaScript.

The developers who put a lot of effort into optimizing things and making them tight and fast will wake up to discover that effort was, more or less, wasted, or, at the very least, you could say that it “conferred no long term competitive advantage,” if you’re the kind of person who talks like an economist.

The developers who ignored performance and blasted ahead adding cool features to their applications will, in the long run, have better applications.

A portable programming language

The C programming language was invented with the explicit goal of making it easy to port applications from one instruction set to another. And it did a fine job, but wasn’t really 100% portable, so we got Java, which was even more portable than C. Mmmhmm.

Right now the big hole in the portability story is — tada! — client-side JavaScript, and especially the DOM in web browsers. Writing applications that work in all different browsers is a friggin’ nightmare. There is simply no alternative but to test exhaustively on Firefox, IE6, IE7, Safari, and Opera, and guess what? I don’t have time to test on Opera. Sucks to be Opera. Startup web browsers don’t stand a chance.

What’s going to happen? Well, you can try begging Microsoft and Firefox to be more compatible. Good luck with that. You can follow the p-code/Java model and build a little sandbox on top of the underlying system. But sandboxes are penalty boxes; they’re slow and they suck, which is why Java Applets are dead, dead, dead. To build a sandbox you pretty much doom yourself to running at 1/10th the speed of the underlying platform, and you doom yourself to never supporting any of the cool features that show up on one of the platforms but not the others. (I’m still waiting for someone to show me a Java applet for phones that can access any of the phone’s features, like the camera, the contacts list, the SMS messages, or the GPS receiver.)

Sandboxes didn’t work then and they’re not working now.

What’s going to happen? The winners are going to do what worked at Bell Labs in 1978: build a programming language, like C, that’s portable and efficient. It should compile down to “native” code (native code being JavaScript and DOMs) with different backends for different target platforms, where the compiler writers obsess about performance so you don’t have to. It’ll have all the same performance as native JavaScript with full access to the DOM in a consistent fashion, and it’ll compile down to IE native and Firefox native portably and automatically. And, yes, it’ll go into your CSS and muck around with it in some frightening but provably-correct way so you never have to think about CSS incompatibilities ever again. Ever. Oh joyous day that will be.

High interactivity and UI standards

The IBM 360 mainframe computer system used a user interface called CICS, which you can still see at the airport if you lean over the checkin counter. There’s an 80 character by 24 character green screen, character mode only, of course. The mainframe sends down a form to the “client” (the client being a 3270 smart terminal). The terminal is smart; it knows how to present the form to you and let you input data into the form without talking to the mainframe at all. This was one reason mainframes were so much more powerful than Unix: the CPU didn’t have to handle your line editing; it was offloaded to a smart terminal. (If you couldn’t afford smart terminals for everyone, you bought a System/1 minicomputer to sit between the dumb terminals and the mainframe and handle the form editing for you).

Anyhoo, after you filled out your form, you pressed SEND, and all your answers were sent back to the server to process. Then it sent you another form. And on and on.

Awful. How do you make a word processor in that kind of environment? (You really can’t. There never was a decent word processor for mainframes).

That was the first stage. It corresponds precisely to the HTML phase of the Internet. HTML is CICS with fonts.

In the second stage, everybody bought PCs for their desks, and suddenly, programmers could poke text anywhere on the screen wily-nily, anywhere they wanted, any time they wanted, and you could actually read every keystroke from the users as they typed, so you could make a nice fast application that didn’t have to wait for you to hit SEND before the CPU could get involved. So, for example, you could make a word processor that automatically wrapped, moving a word down to the next line when the current line filled up. Right away. Oh my god. You can do that?

The trouble with the second stage was that there were no clear UI standards… the programmers almost had too much flexibility, so everybody did things in different ways, which made it hard, if you knew how to use program X, to also use program Y. WordPerfect and Lotus 1-2-3 had completely different menu systems, keyboard interfaces, and command structures. And copying data between them was out of the question.

And that’s exactly where we are with Ajax development today. Sure, yeah, the usability is much better than the first generation DOS apps, because we’ve learned some things since then. But Ajax apps can be inconsistent, and have a lot of trouble working together — you can’t really cut and paste objects from one Ajax app to another, for example, so I’m not sure how you get a picture from Gmail to Flickr. Come on guys, Cut and Paste was invented 25 years ago.

The third phase with PCs was Macintosh and Windows. A standard, consistent user interface with features like multiple windows and the Clipboard designed so that applications could work together. The increased usability and power we got out of the new GUIs made personal computing explode.

So if history repeats itself, we can expect some standardization of Ajax user interfaces to happen in the same way we got Microsoft Windows. Somebody is going to write a compelling SDK that you can use to make powerful Ajax applications with common user interface elements that work together. And whichever SDK wins the most developer mindshare will have the same kind of competitive stronghold as Microsoft had with their Windows API.

If you’re a web app developer, and you don’t want to support the SDK everybody else is supporting, you’ll increasingly find that people won’t use your web app, because it doesn’t, you know, cut and paste and support address book synchronization and whatever weird new interop features we’ll want in 2010.

Imagine, for example, that you’re Google with GMail, and you’re feeling rather smug. But then somebody you’ve never heard of, some bratty Y Combinator startup, maybe, is gaining ridiculous traction selling NewSDK, which combines a great portable programming language that compiles to JavaScript, and even better, a huge Ajaxy library that includes all kinds of clever interop features. Not just cut ‘n’ paste: cool mashup features like synchronization and single-point identity management (so you don’t have to tell Facebook and Twitter what you’re doing, you can just enter it in one place). And you laugh at them, for their NewSDK is a honking 232 megabytes … 232 megabytes! … of JavaScript, and it takes 76 seconds to load a page. And your app, GMail, doesn’t lose any customers.

But then, while you’re sitting on your googlechair in the googleplex sipping googleccinos and feeling smuggy smug smug smug, new versions of the browsers come out that support cached, compiled JavaScript. And suddenly NewSDK is really fast. And Paul Graham gives them another 6000 boxes of instant noodles to eat, so they stay in business another three years perfecting things.

And your programmers are like, jeez louise, GMail is huge, we can’t port GMail to this stupid NewSDK. We’d have to change every line of code. Heck it’d be a complete rewrite; the whole programming model is upside down and recursive and the portable programming language has more parentheses than even Google can buy. The last line of almost every function consists of a string of 3,296 right parentheses. You have to buy a special editor to count them.

And the NewSDK people ship a pretty decent word processor and a pretty decent email app and a killer Facebook/Twitter event publisher that synchronizes with everything, so people start using it.

And while you’re not paying attention, everybody starts writing NewSDK apps, and they’re really good, and suddenly businesses ONLY want NewSDK apps, and all those old-school Plain Ajax apps look pathetic and won’t cut and paste and mash and sync and play drums nicely with one another. And Gmail becomes a legacy. The WordPerfect of Email. And you’ll tell your children how excited you were to get 2GB to store email, and they’ll laugh at you. Their nail polish has more than 2GB.

Crazy story? Substitute “Google Gmail” with “Lotus 1-2-3”. The NewSDK will be the second coming of Microsoft Windows; this is exactly how Lotus lost control of the spreadsheet market. And it’s going to happen again on the web because all the same dynamics and forces are in place. The only thing we don’t know yet are the particulars, but it’ll happen.

by Joel Spolsky

Font smoothing, anti-aliasing, and sub-pixel rendering

Apple and Microsoft have always disagreed in how to display fonts on computer displays. Today, both companies are using sub-pixel rendering to coax sharper-looking fonts out of typical low resolution screens. Where they differ is in philosophy.

  • Apple generally believes that the goal of the algorithm should be to preserve the design of the typeface as much as possible, even at the cost of a little bit of blurriness.
  • Microsoft generally believes that the shape of each letter should be hammered into pixel boundaries to prevent blur and improve readability, even at the cost of not being true to the typeface.

Now that Safari for Windows is available, which goes to great trouble to use Apple’s rendering algorithms, you can actually compare the philosophies side-by-side on the very same monitor and see what I mean. I think you’ll notice the difference. Apple’s fonts are indeed fuzzy, with blurry edges, but at small font sizes, there seems to be much more variation between different font families, because their rendering is truer to what the font would look like if it were printed at high resolution.

(Note: To see the following illustration correctly, you need to have an LCD monitor with pixels arranged in R,G,B order, like mine. Otherwise it’s going to look different and wrong.)

The difference originates from Apple’s legacy in desktop publishing and graphic design. The nice thing about the Apple algorithm is that you can lay out a page of text for print, and on screen, you get a nice approximation of the finished product. This is especially significant when you consider how dark a block of text looks. Microsoft’s mechanism of hammering fonts into pixels means that they don’t really mind using thinner lines to eliminate blurry edges, even though this makes the entire paragraph lighter than it would be in print.

The advantage of Microsoft’s method is that it works better for on-screen reading. Microsoft pragmatically decided that the design of the typeface is not so holy, and that sharp on-screen text that’s comfortable to read is more important than the typeface designer’s idea of how light or dark an entire block of text should feel. Indeed Microsoft actually designed font faces for on-screen reading, like Georgia and Verdana, around the pixel boundaries; these are beautiful on screen but don’t have much character in print.

Typically, Apple chose the stylish route, putting art above practicality, because Steve Jobs has taste, while Microsoft chose the comfortable route, the measurably pragmatic way of doing things that completely lacks in panache. To put it another way, if Apple was Target, Microsoft would be Wal-Mart.

Now, on to the question of what people prefer. Jeff Atwood’s post from yesterday comparing the two font technologies side-by-side generated rather predictable heat: Apple users liked Apple’s system, while Windows users liked Microsoft’s system. This is not just standard fanboyism; it reflects the fact that when you ask people to choose a style or design that they prefer, unless they are trained, they will generally choose the one that looks most familiar. In most matters of taste, when you do preference surveys, you’ll find that most people don’t really know what to choose, and will opt for the one that seems most familiar. This goes for anything from silverware (people pick out the patterns that match the silverware they had growing up) to typefaces to graphic design: unless people are trained to know what to look for, they’re going to pick the one that is most familiar.

Which is why Apple engineers probably feel like they’re doing a huge service to the Windows community, bringing their “superior” font rendering technology to the heathens, and it explains why Windows users are generally going to think that Safari’s font rendering is blurry and strange and they don’t know why, they just don’t like it. Actually they’re thinking… “Whoa! That’s different. I don’t like different. Why don’t I like these fonts? Oh, when I look closer, they look blurry. That must be why.“

 

by Joel Spolsky

A game of inches

“Did someone leave the radio on in the bathroom?” I asked Jared. There was a faint sound of classical music.

“No. It’s coming from outside. It started while you were away and happens every night.”

We live in an apartment building in New York. There are neighbors on all sides. We’re used to hearing TV shows from below, and the little kid in the apartment directly above us has a favorite game: throwing a bunch of marbles on the floor and then throwing himself around the room violently. I’m not sure how you keep score. As I write this, he’s running rapidly from room to room crashing into things. I can’t wait until he’s old enough for paintball.

Anyway. This classical-music-late-at-night thing had never happened before.

Worse, it was some kind of sturm-und-drang romantic crap that was making me angry right when I wanted to fall asleep.

Eventually, the music stopped, and I was able to drift off to sleep. But the next night, when the music resumed at midnight, I was really worn out, and it was more self-important Wagner rubbish, with pompous crescendos that consistently woke me up every time I finally drifted off to sleep, and I had no choice but to go sit in the living room and look at pictures of lolcats until it stopped, which it finally did, around 1 am.

The next night I had had enough. When the music started at about midnight, I got dressed and started exploring the apartment building. I crept around the halls, listening at every door, trying to figure out where the music came from. I poked my head out windows and found an unlocked door leading to an airshaft where the music was amazingly loud. I climbed up and down the stairs, and listened closely from the window on each and every landing, until I was pretty convinced that the problem was from dear old Mrs. C’s apartment, #2B, directly below us.

I didn’t think Mrs. C, who is probably in her 60s, was even awake that late, let alone listening to music loudly, but I briefly entertained the possibility that the local classical music station was doing the Ring Cycle or something and she was staying up late to hear it.

Not bloody likely.

One thing I had noticed was that the music seemed to go on at midnight every night, and off at 1:00 am. Somehow, that made me think it was a clock radio, which probably had the alarm factory set to 12:00.

I couldn’t bring myself to wake up an old lady downstairs on the mere suspicion that music was coming from her apartment. Frustrated, I went back to my apartment and caught up on xkcd. I was depressed and angry, because I hadn’t solved the problem. I festered and scowled all the next day.

The next evening, I knocked on Mrs. C’s door. The super had told me she was going away for the entire summer the next day so if the problem was coming from her apartment I better find out pronto.

“Sorry to bother you,” I said. “I’ve noticed that every night around midnight there’s loud classical music coming from the airshaft behind our apartments and it’s keeping me awake.”

“Oh no, it’s not me!” she insisted, as I suspected she would. Of course not: she probably goes to sleep at a completely normal hour and certainly never plays loud music that bothers the neighbors!

I thought she was a little hard of hearing and probably never noticed the thing blaring away from her spare room in the middle of the night. Or maybe she was a good sleeper.

It took a few minutes, but I finally convinced her to check if there was any kind of clock radio in the room below my window.

Turns out there was. Right in an open window beneath my own bedroom window. When I saw that it was tuned to 96.3, WQXR, I knew I had found the culprit.

“Oh, that thing? I have no idea how to use that thing. I never use it,” she said. “I’ll disconnect it completely.”

“Not necessary,” I said, and turned off the alarm, set the volume to zero, and, in my late-onset OCD, set the clock to the exact time.

Mrs. C was terribly apologetic, but it really wasn’t her fault. It took me—me!—quite a while to figure out how to operate the damn clock radio, and let me tell you, sonny boy, I know a thing or two about clock radios.  The UI was terrible. Your average little old lady didn’t stand a chance.

Is it the clock radio’s fault? Sort of. It was too hard to use. It had an alarm that continued to go off daily even if nobody touched it the day before, which is not the greatest idea. And there’s no reason to reset the alarm time to midnight after a power outage. 7:00 am would be a completely civilized default.

Somehow, over the last few weeks, I’ve become hypercritical. I’m always looking for flaws in things, and when I find them, I become single-minded about fixing them. It’s a particular frame of mind, actually, that software developers get into when they’re in the final debugging phase of a new product.

Over the last few weeks, I’ve been writing all the documentation for the next big version of FogBugz. As I write things, I try them out, either to make sure they work the way I think they should, or to get screenshots. And every hour or so, bells go off. “Wait a minute! What just happened? That’s not supposed to work like that!”

And since it’s software, I can always fix it. HA HA! Just kidding! I can’t make head or tail out of the code any more. I enter a bug and someone with a clue fixes it.

Dave Winer says, “To create a usable piece of software, you have to fight for every fix, every feature, every little accommodation that will get one more person up the curve. There are no shortcuts. Luck is involved, but you don’t win by being lucky, it happens because you fought for every inch.“

Commercial software—the kind you sell to other people—is a game of inches.

Every day you make a tiny bit of progress. You make one thing just a smidgen better. You make the alarm clock default to 7:00am instead of 12:00 midnight. A tiny improvement that will barely benefit anyone. One inch.

There are thousands and tens of thousands of these tiny things.

It takes a mindset of constant criticism to find them. You have to reshape your mind until you’re finding fault with everything. Your significant others go nuts. Your family wants to kill you. When you’re walking to work and you see a driver do something stupid, it takes all your willpower to resist going up to the driver and explaining to him why he nearly killed that poor child in the wheelchair.

And as you fix more and more of these little details, as you polish and shape and shine and craft the little corners of your product, something magical happens. The inches add up to feet, the feet add up to yards, and the yards add up to miles. And you ship a truly great product. The kind of product that feels great, that works intuitively, that blows people away. The kind of product where that one-in-a-million user doing that one-in-a-million unusual thing finds that not only does it work, but it’s beautiful: even the janitor’s closets of your software have marble floors and solid core oak doors and polished mahogany wainscoting.

And that’s when you know it’s great software.

Congratulations to the FogBugz 6.0 team, outlandishly good players of the game of inches, who shipped their first beta today, on track for final release at the end of the summer. This is the best product they’ve ever produced. It will blow you away.

by Joel Spolsky

Seven steps to remarkable customer service

As a bootstrapped software company, Fog Creek couldn’t afford to hire customer service people for the first couple of years, so Michael and I did it ourselves. The time we spent helping customers took away from improving our software, but we learned a lot and now we have a much better customer service operation.

Here are seven things we learned about providing remarkable customer service. I’m using the word remarkable literally—the goal is to provide customer service so good that people remark.

1. Fix everything two ways

Almost every tech support problem has two solutions. The superficial and immediate solution is just to solve the customer’s problem. But when you think a little harder you can usually find a deeper solution: a way to prevent this particular problem from ever happening again.

Sometimes that means adding more intelligence to the software or the SETUP program; by now, our SETUP program is loaded with special case checks. Sometimes you just need to improve the wording of an error message. Sometimes the best you can come up with is a knowledge base article.

We treat each tech support call like the NTSB treats airliner crashes. Every time a plane crashes, they send out investigators, figure out what happened, and then figure out a new policy to prevent that particular problem from ever happening again. It’s worked so well for aviation safety that the very, very rare airliner crashes we still get in the US are always very unusual, one-off situations.

This has two implications.

One: it’s crucial that tech support have access to the development team. This means that you can’t outsource tech support: they have to be right there at the same street address as the developers, with a way to get things fixed. Many software companies still think that it’s “economical” to run tech support in Bangalore or the Philippines, or to outsource it to another company altogether. Yes, the cost of a single incident might be $10 instead of $50, but you’re going to have to pay $10 again and again.

When we handle a tech support incident with a well-qualified person here in New York, chances are that’s the last time we’re ever going to see that particular incident. So with one $50 incident we’ve eliminated an entire class of problems.

Somehow, the phone companies and the cable companies and the ISPs just don’t understand this equation. They outsource their tech support to the cheapest possible provider and end up paying $10 again and again and again fixing the same problem again and again and again instead of fixing it once and for all in the source code. The cheap call centers have no mechanism for getting problems fixed; indeed, they have no incentive to get problems fixed because their income depends on repeat business, and there’s nothing they like better than being able to give the same answer to the same question again and again.

The second implication of fixing everything two ways is that eventually, all the common and simple problems are solved, and what you’re left with is very weird uncommon problems. That’s fine, because there are far fewer of them, and you’re saving a fortune not doing any rote tech support, but the downside is that there’s no rote tech support left: only serious debugging and problem solving. You can’t just teach new support people ten common solutions: you have to teach them to debug.

For us, the “fix everything two ways” religion has really paid off. We were able to increase our sales tenfold while only doubling the cost of providing tech support.

2. Suggest blowing out the dust

Microsoft’s Raymond Chen tells the story of a customer who complains that the keyboard isn’t working. Of course, it’s unplugged. If you try asking them if it’s plugged in, “they will get all insulted and say indignantly, ‘Of course it is! Do I look like an idiot?’ without actually checking.”

“Instead,” Chen suggests, “say ‘Okay, sometimes the connection gets a little dusty and the connection gets weak. Could you unplug the connector, blow into it to get the dust out, then plug it back in?’

“They will then crawl under the desk, find that they forgot to plug it in (or plugged it into the wrong port), blow out the dust, plug it in, and reply, ‘Um, yeah, that fixed it, thanks.’”

Many requests for a customer to check something can be phrased this way. Instead of telling them to check a setting, tell them to change the setting and then change it back “just to make sure that the software writes out its settings.”

3. Make customers into fans

Every time we need to buy logo gear here at Fog Creek, I get it from Lands’ End.

Why?

Let me tell you a story. We needed some shirts for a trade show. I called up Lands’ End and ordered two dozen, using the same logo design we had used for some knapsacks we bought earlier.

When the shirts arrived, to our dismay, you couldn’t read the logo.

It turns out that the knapsacks were brighter than the polo shirts. The thread color that looked good on the knapsacks was too dark to read on the shirts.

I called up Lands’ End. As usual, a human answered the phone even before it started ringing. I’m pretty sure that they have a system where the next agent in the queue is told to standby, so customers don’t even have to wait one ringy-dingy before they’re talking to a human.

I explained that I screwed up.

They said, “Don’t worry. You can return those for a full credit, and we’ll redo the shirts with a different color thread.”

I said, “The trade show is in two days.”

They said they would Fedex me a new box of shirts and I’d have it tomorrow. I could return the old shirts at my convenience.

They paid shipping both ways. I wasn’t out a cent. Even though they had no possible use for a bunch of Fog Creek logo shirts with an illegible logo, they ate the cost.

And now I tell this story to everyone who needs swag. In fact I tell this story every time we’re talking about telephone menu systems. Or customer service. By providing remarkable customer service, they’ve gotten me to remark about it.

When customers have a problem and you fix it, they’re actually going to be even more satisfied than if they never had a problem in the first place.

It has to do with expectations. Most people’s experience with tech support and customer service comes from airlines, telephone companies, cable companies, and ISPs, all of whom provide generally awful customer service. It’s so bad you don’t even bother calling any more, do you? So when someone calls Fog Creek, and immediately gets through to a human, with no voice mail or phone menus, and that person turns out to be nice and friendly and actually solves their problem, they’re apt to think even more highly of us than someone who never had the opportunity to interact with us and just assumes that we’re average.

Now, I wouldn’t go so far as to actually make something go wrong, just so we have a chance to demonstrate our superior customer service. Many customers just won’t call; they’ll fume quietly.

But when someone does call, look at it as a great opportunity to create fanatically devoted customer, one who will prattle on and on about what a great job you did.

4. Take the blame

One morning I needed an extra set of keys to my apartment, so on the way to work, I went to the locksmith around the corner.

13 years living in an apartment in New York City has taught me never to trust a locksmith; half of the time their copies don’t work. So I went home to test the new keys, and, lo and behold, one didn’t work.

I took it back to the locksmith.

He made it again.

I went back home and tested the new copy.

It still didn’t work.

Now I was fuming. Squiggly lines were coming up out of my head. I was a half hour late to work and had to go to the locksmith for a third time. I was tempted just to give up on him. But I decided to give this loser one more chance.

I stomped into the store, ready to unleash my fury.

“It still doesn’t work?” he asked. “Let me see.”

He looked at it.

I was sputtering, trying to figure out how best to express my rage at being forced to spend the morning going back and forth.

“Ah. It’s my fault,” he said.

And suddenly, I wasn’t mad at all.

Mysteriously, the words “it’s my fault” completely defused me. That was all it took.

He made the key a third time. I wasn’t mad any more. The key worked.

And, here I was, on this planet for forty years, and I couldn’t believe how much the three words “it’s my fault” had completely changed my emotions in a matter of seconds.

Most locksmiths in New York are not the kinds of guys to admit that they’re wrong. Saying “it’s my fault” was completely out of character. But he did it anyway.

5. Memorize awkward phrases

I figured, OK, since the morning is shot anyway, I might as well go to the diner for some breakfast.

It’s one of those classic New York diners, like the one on Seinfeld. There’s a thirty page menu and a kitchen the size of a phone booth. It doesn’t make sense. They must have Star Trek technology to get all those ingredients into such a small space. Maybe they rearrange atoms on the spot.

I was sitting by the cash register.

An older woman came up to pay her check. As she was paying, she said to the owner, “you know, I’ve been coming here for years and years, and that waiter was really rather rude to me.”

The owner was furious.

“What do you mean? No he wasn’t! He’s a good waiter! I never had a complaint!’

The customer couldn’t believe it. Here she was, a loyal customer, and she wanted to help out the owner by letting him know that one of his waiters needed a little bit of help in the manners department, but the owner was arguing with her!

“Well, that’s fine, but I’ve been coming here for years, and everybody is always very nice to me, but that guy was rude to me,” she explained, patiently.

“I don’t care if you’ve been coming here forever. My waiters are not rude.” The owner proceeded to yell at her. “I never had no problems. Why are you making problems?”

“Look, if you’re going to treat me this way I won’t come back.”

“I don’t care!” said the owner. One of the great things about owning a diner in New York is that there are so many people in the city that you can offend every single customer who ever comes into your diner and you’ll still have a lot of customers. “Don’t come back! I don’t want you as a customer!”

Good for you, I thought. Here’s a 60-something year old man, owner of a diner, and you won some big moral victory against a little old lady. Are you proud of yourself? How macho do you have to be? Does the moral victory make you feel better? Did you really have to lose a repeat customer?

Would it have made you feel totally emasculated to say, “I’m so sorry. I’ll have a word with him?”

It’s easy to get caught up in the emotional heat of the moment when someone is complaining.

The solution is to memorize some key phrases, and practice saying them, so that when you need to say them, you can forget your testosterone and make a customer happy.

“I’m sorry, it’s my fault.”

“I’m sorry, I can’t accept your money. The meal’s on me.”

“That’s terrible, please tell me what happened so I can make sure it never happens again.”

It’s completely natural to have trouble saying “It’s my fault.” That’s human. But those three words are going to make your angry customers much happier. So you’re going to have to say them. And you’re going to have to sound like you mean it.

So start practicing.

Say “It’s my fault” a hundred times one morning in the shower, until it starts to sound like syllabic nonsense. Then you’ll be able to say it on demand.

One more point. You may think that admitting fault is a strict no-no that can get you sued. This is nonsense. The way to avoid getting sued is not to have people who are mad at you. The best way to do this is to admit fault and fix the damn problem.

6. Practice puppetry

The angry diner owner clearly took things very personally, in a way that the locksmith didn’t. When an irate customer is complaining, or venting, it’s easy to get defensive.

You can never win these arguments, and if you take them personally, it’s going to be a million times worse. This is when you start to hear business owners saying, “I don’t want an asshole like you for a customer!” They get excited about their Pyrrhic victory. Wow, isn’t it great? When you’re a small business owner you get to fire your customers. Charming.

The bottom line is that this is not good for business, and it’s not even good for your emotional well-being. When you win a victory with a customer by firing them, you still end up feeling riled up and angry, they’ll get their money back from the credit card company anyway, and they’ll tell a dozen friends. As Patrick McKenzie writes, “You will never win an argument with your customer.”

There is only one way to survive angry customers emotionally: you have to realize that they’re not angry at you; they’re angry at your business, and you just happen to be a convenient representative of that business.

And since they’re treating you like a puppet, an iconic stand-in for the real business, you need to treat yourself as a puppet, too.

Pretend you’re a puppeteer. The customer is yelling at the puppet. They’re not yelling at you. They’re angry with the puppet.

Your job is to figure out, “gosh, what can I make the puppet say that will make this person a happy customer?”

You’re just a puppeteer. You’re not a party to the argument. When the customer says, “what the hell is wrong with you people,” they’re just playing a role (in this case, they’re quoting Tom Smykowski in the movie Office Space). You, too, get to play a role. “I’m sorry. It’s my fault.” Figure out what to make the puppet do that will make them happy and stop taking it so dang personally.

7. Greed will get you nowhere

Recently I was talking with the people who have been doing most of the customer service for Fog Creek over the last year, and I asked what methods they found most effective for dealing with angry customers.

“Frankly,” they said, “we have pretty nice customers. We haven’t really had any angry customers.”

Well, OK, we do have nice customers, but it seems rather unusual that in a year of answering the phones, nobody was angry. I thought the nature of working at a call center was dealing with angry people all day long.

“Nope. Our customers are nice.”

Here’s what I think. I think that our customers are nice because they’re not worried. They’re not worried because we have a ridiculously liberal return policy: “We don’t want your money if you’re not amazingly happy.”

Customers know that they have nothing to fear. They have the power in the relationship. So they don’t get abusive.

The no-questions-asked 90-day money back guarantee was one of the best decisions we ever made at Fog Creek. Try this: use Fog Creek Copilot for a full 24 hours, call up three months later and say, “hey guys, I need $5 for a cup of coffee. Give me back my money from that Copilot day pass,” and we’ll give it back to you. Try calling on the 91st or 92nd or 203rd day. You’ll still get it back. We really don’t want your money if you’re not satisfied. I’m pretty sure we’re running the only job listing service around that will refund your money just because your ad didn’t work. This is unheard of, but it means we get a lot more ad listings, because there’s nothing to lose.

Over the last six years or so, letting people return software has cost us 2%.

2%.

And you know what? Most customers pay with credit cards, and if we didn’t refund their money, a bunch of them would have called their bank. This is called a chargeback. They get their money back, we pay a chargeback fee, and if this happens too often, our processing fees go up.

Know what our chargeback rate is at Fog Creek?

0%.

I’m not kidding.

If we were tougher about offering refunds, the only thing we would possibly have done is pissed a few customers off, customers who would have ranted and whined on their blogs. We wouldn’t even have kept more of their money.

I know of software companies who are very explicit on their web site that you are not entitled to a refund under any circumstances, but the truth is, if you call them up, they will eventually return your money because they know that if they don’t, your credit card company will. This is the worst of both worlds. You end up refunding the money anyway, and you don’t get to give potential customers the warm and fuzzy feeling of knowing Nothing Can Possibly Go Wrong, so they hesitate before buying. Or they don’t buy at all.

8. (Bonus!) Give customer service people a career path

The last important lesson we learned here at Fog Creek is that you need very highly qualified people talking to customers. A salesperson at Fog Creek needs to have significant experience with the software development process and needs to be able to explain why FogBugz works the way it does, and why it makes software development teams function better. A tech support person at Fog Creek can’t get by on canned answers to common questions, because we’ve eliminated the common questions by fixing the software, so tech support here has to actually troubleshoot which often means debugging.

Many qualified people get bored with front line customer service, and I’m OK with that. To compensate for this, I don’t hire people into those positions without an explicit career path. Here at Fog Creek, customer support is just the first year of a three-year management training program that includes a master’s degree in technology management at Columbia University. This allows us to get ambitious, smart geeks on a terrific career path talking to customers and solving their problems. We end up paying quite a bit more than average for these positions (especially when you consider $25,000 a year in tuition), but we get far more value out of them, too.

by Joel Spolsky

Copilot 2.0 ships!

Hoorah! Fog Creek Copilot 2.0 is now online, with three, no wait, five, no, three new features.

Well, I guess it depends how you count. In a moment I’ll count ‘em. In the meantime, a little background.

Fog Creek Copilot is a remote tech support service that lets one person control another computer remotely, much like VNC or RDC, with the advantage that it requires zero configuration, works through firewalls, and installs nothing.

Two summers ago, we had four interns here who built it, all by themselves, over the course of their 12 week internship. The only thing we gave them was a spec, some desks, and computers. They put together the web site, the documentation, all the code for five major components, came up with the marketing plan, did usability testing, and demoed to the public at a trade show. They kept a blog, which you can still read, and someone even made a documentary movie made about their summer.

(Sidebar: One of the reasons they were able to accomplish so much in one summer is that they used open source software as a starting point. Of course, everything they did, with the exception of our proprietary back end server code, is available under the GPL license.)

OK. New features!

1. Support for Mac! OMG! All versions of Mac OS X from 10.2 on are now supported. I’m fairly confident that our Mac remote desktop implementation is second to none.

Oh, wait. Interruption. You may be wondering, if the interns did the whole thing over a summer, who wrote all this new code?

The answer is that two of the interns accepted full-time jobs at Fog Creek, Tyler and Ben. Tyler extended his summer until December, and then headed off for a leave of absence to finish his Masters degree at Stanford. Ben graduated from Duke last summer and has been cranking away on 2.0 since then. Ben, by the way, is the only person I know who writes code in C, C++, C#, and Objective C all in the same day, while writing a book about Smalltalk at night. We also had a Mac programming guru, Daniel Jalkut, get us started with the Mac port.

OK, next new big feature:

2. Direct Connect! We’ve always done everything we can to make sure that Fog Creek Copilot can connect in any networking situation, no matter what firewalls or NATs are in place. To make this happen, both parties make outbound connections to our server, which relays traffic on their behalf. Well, in many cases, this isn’t necessary. So version 2.0 does something rather clever: it sets up the initial connection through our servers, so you get connected right away with 100% reliability. But then once you’re all connected, it quietly, in the background, looks for a way to make a direct connection. If it can’t, no big deal: you just keep relaying through our server. If you can make a direct peer-to-peer connection, it silently shifts your data onto the direct connection. You won’t notice anything except, probably, much faster communication.

3. File transfer! An easy-to-use file upload and download feature makes this the PERFECT application for installing Firefox on all your relatives’ computers. It’s especially handy for tech support scenarios. Imagine this: your new software works great everywhere but this one guy has a wacky system that makes your software keep crashing. So you use Fog Creek Copilot to take over his system, and then you use the file transfer feature to copy new builds to his computer as you try to fix the problem.

4. Does this count as a feature? We lowered the price for day passes–24 hours of usage—from $10 to no, not $9, not $8, not $7, would you believe it’s only FIVE DOLLARS? That’s right, unlimited usage for 24 hours for five lonely bucks.

I guess I should explain the reasoning behind that. First of all, the direct connect feature (#2) should reduce our bandwidth bills in many situations, so we can pass that savings on.

Second, we don’t want anyone to have an excuse not to use Fog Creek Copilot. To avoid paying $10, you might actually be crazy enough to try to just talk your mom into uninstalling Norton Utilities, punching the appropriate holes in the Windows firewall, and setting up appropriate port-forwarding rules on her broadband router… but for $5, why go through the trouble? Or you might be willing to set up your own server outside the firewall, with VNC running as a listener, and walk your customers through setting up VNC and connecting back to you, but again, why bother for five bucks?

We think that’s a negligible price to pay to know that all you need to tell your mom, or your customer, is “Go to copilot.com, type in this number, and download and run the program you find there.” And to know that it will Just Work.

We’re betting that the lower price will lead to more users, which will lead to more corporate subscriptions, which will lead to higher total revenues.

So. Congratulations to Tyler and Ben for a fantastic upgrade!

by Joel Spolsky

The Big Picture

A review of Dreaming in Code, by Scott Rosenberg.

Eyes work using a page fault mechanism. They’re so good at it that you don’t even notice.

You can only see at a high-resolution in a fairly small area, and even that has a big fat blind spot right exactly in the middle, but you still walk around thinking you have a ultra-high resolution panoramic view of everything. Why? Because your eyes move really fast, and, under ordinary circumstances, they are happy to jump instantly to wherever you need them to jump to. And your mind provides this really complete abstraction, providing you with the illusion of complete vision when all you really have is a very small area of high res vision, a large area of extremely low-res vision, and the ability to page-fault-in anything you want to see—so quickly that you walk around all day thinking you have the whole picture projected internally in a little theatre in your brain.

This is really, really useful, and lots of other things work this way, too. Your ears are good at tuning in important parts of conversations. Your fingers reach around and touch anything they need to, whether it’s a fine merino wool sweater or the inside of your nose, giving you a full picture of what everything feels like. When you dream, your mind asks all kinds of questions that it’s used to asking the senses (what’s that? Look over there!) but your senses are temporarily turned off (you are, after all, asleep), so they get back sort-of random answers, which you combine into a funny story in your brain called a dream. And then when you try to recount the dream to your boyfriend in the morning, even though it seemed totally, completely realistic, you suddenly realize that you don’t know what happened, actually, so you have to make shit up. If you had stayed asleep for another minute or two your brain would have asked your senses what kind of mammal was swimming with you in the rose bush, and gotten back some retarded, random answer (a platypus!), but you woke up, so until you tried to tell the story, you didn’t even realize that you needed to know what was in the rose bushes with you to make the story coherent to your partner. Which it never is. So please don’t tell me about your dreams.

One of the unfortunate side effects is that your mind gets into a bad habit of overestimating how clearly it understands things. It always thinks it has The Big Picture even when it doesn’t.

This is a particularly dangerous trap when it comes to software development. You get some big picture idea in your head for what you want to do, and it all seems so crystal clear that it doesn’t even seem like you need to design anything. You can just dive in and start implementing your vision.

Say, for example, that your vision is to rebuild an old DOS personal information manager, which was really really great but totally unappreciated. It seems easy. Everything about how the whole thing works seems so obvious, you don’t even try to design the thing… you just hire a bunch of programmers and start banging out code.

Now you’ve made two mistakes.

Number one, you fell for that old overconfidence trick of your mind. “Oh, yeah, we totally know how to do this! It’s all totally clear to us. No need to spec it out. Just write the code.”

Number two, you hired programmers before you designed the thing. Because the only thing harder than trying to design software is trying to design software as a team.

I can’t tell you how many times I’ve been in a meeting with even one or two other programmers, trying to figure out how something should work, and we’re just not getting anywhere. So I go off in my office and take out a piece of paper and figure it out. The very act of interacting with a second person was keeping me from concentrating enough to design the dang feature.

What kills me is the teams who get into the bad habit of holding meetings every time they need to figure out how something is going to work. Did you ever try to write poetry in a committee meeting? It’s like a bunch of fat construction guys trying to write an opera while sitting on the couch watching Baywatch. The more fat construction guys you add to the couch, the less likely you are to get opera out of it.

At least turn off the TV!

Now, it would be shockingly presumptuous of me to try to guess what happened on the Chandler team, and why it’s taken them millions of dollars and several years to get to where they are now, which is, they have a pretty buggy and incomplete calendar application that’s not very impressive compared to the 58 me-too Web 2.0 calendars that came out last year, each of which was developed by two college kids in their spare time, one of whom really mostly just drew mascots.

Chandler doesn’t even have a mascot!

Like I say, I can’t presume to know what went wrong. Maybe nothing. Maybe they feel like they’re right on track. Scott Rosenberg’s excellent new book, which was supposed to be a Soul of a New Machine for the hottest open source startup of the decade, ends up, in frustration, with Scott cutting the story short because Chandler 1.0 was just not going to happen any time soon (and presumably Rosenberg couldn’t run the risk that we wouldn’t be using books at all by the time it shipped, opting instead to absorb knowledge by taking a pill).

Still, it’s a great look at one particular type of software project: the kind that ends up spinning and spinning its wheels without really going anywhere because the vision was too grand and the details were a little short. Near as I can tell, Chandler’s original vision was pretty much just to be “revolutionary.” Well, I don’t know about you, but I can’t code “revolutionary.” I need more details to write code. Whenever the spec describes the product in terms of adjectives (“it will be extremely cool”) rather than specifics (“it will have brushed-aluminum title bars and all the icons will be reflected a little bit, as if placed on a grand piano”) you know you’re in trouble.

The only concrete design ideas, as far as I could tell from Rosenberg’s book, were “peer-to-peer,” “no silos,” and “natural language date interpretation.” This may be the a limitation of the book, but the initial design sure seemed to be extremely vague.

“Peer-to-peer” was the raison-d’être of Chandler… why should you have to buy Microsoft Exchange Server to coordinate schedules? It turned out that peer-to-peer synchronization was too hard, or something, and this feature was cut. Now there’s a server called Cosmo.

“No Silos” was supposed to mean that instead of having your email in one silo, and your calendar in another silo, and your reminder notes in a third, there would just be a single unified silo holding everything.

As soon as you start asking questions about “No Silos,” you realize it’s not going to work. Do you put your email on the calendar? Where? On the day when it arrived? So now I have 200 Viagra ads on Friday obscuring the one really important shareholder meeting?

Eventually “No Silos” got designed into this idea of stamps, so, for example, you could “stamp” any document or note or calendar item with an email stamp and suddenly that item could be mailed to anyone. Guess what? That feature has been in Microsoft Office for the last decade or so. They finally took it out in Office 2007 because nobody cared. There are too many easy ways to email people things.

Indeed, I think the idea of “No Silos” is most appealing to architecture astronauts, the people who look at subclasses and see abstract base classes, and who love to move functionality from the subclass into the base class for no good reason other than architectural aesthetics. This is usually a terrible user interface design technique. The way you make users understand your program model is with metaphors. When you make things look, feel, and most importantly, behave like things in the real world, users are more likely to figure out how to use the program, and the app will be easier to use. When you try to combine two very dramatically different real-world items (email and appointments) into the same kind of thing in the user interface, usability suffers because there’s no longer a real-world metaphor that applies.

The other cool thing that Kapor kept telling everyone who would listen is that Agenda would let you type things like “Next Tuesday” and magically you’d get an appointment for next Tuesday. This is slicker than heck, but every half-decent calendar program for the last decade has done this. Not revolutionary.

The Chandler team also overestimated how much help they would get from volunteers. Open source doesn’t quite work like that. It’s really good at implementing copycat features, because there’s a spec to work from: the implementation you’re copying. It’s really good at Itch Scratching features. I need a command line argument for EBCDIC, so I’ll add it and send in the code. But when you have an app that doesn’t do anything yet, nobody finds it itchy. They’re not using it. So you don’t get volunteers. Almost everyone on the Chandler dev team got paid.

Again I must forcefully apologize to the Chandler team if Rosenberg missed the point somehow, or if he gave a completely incorrect impression of what was really holding up progress, and my bias—to blame these kinds of debacles on a failure to design—is showing.

All that said, one good thing did come out of the project: a fascinating book in the style of Soul of a New Machine or Showstopper about a software development project that failed to converge. Highly recommended.

by Joel Spolsky

Elegance

Alain de Botton, writing in The Architecture of Happiness (Pantheon Books, 2006) has a section on elegance that any software designer will find familiar.

He compares the Salginatobel Bridge, in Switzerland…

  

…to the Clifton Suspension Bridge, in England:

… in one of the most amazing books about architecture I’ve ever read:

“Both Robert Maillart’s Salginatobel and Isambard Brunel’s Clifton Suspension bridges are structures of strength; both attract our veneration for carrying us safely across a fatal drop—and yet Maillart’s bridge is the more beautiful of the pair for the exceptionally nimble, apparently effortless way in which it carries out its duty. With its ponderous masonry and heavy steel chains, Brunel’s construction has something to it of a stocky middle-aged man who hoists his trousers and loudly solicits the attention of others before making a jump between two points, whereas Maillart’s bridge resembles a lithe athlete who leaps without ceremony and bows demurely to his audience before leaving the stage. Both bridges accomplish daring feats, but Maillart’s possesses the added virtue of making its achievement look effortless—and because we sense it isn’t, we wonder at it and admire it all the more. The bridge is endowed with a subcategory of beauty we can refer to as elegance, a quality present whenever a work of architecture succeeds in carrying out an act of resistance—holding, spanning, sheltering—with grace and economy as well as strength; when it has the modesty not to draw attention to the difficulties it has surmounted.”

In that context, I’d like revisit my recent themes of choices and simplicity and add a third concept, elegance.

People, for the most part, are not playing with their software because they want to. They’re using the software as a tool to accomplish something else that they would like to do. Maybe they are using a chat program to try and seem witty, in hopes that the person they are chatting with will want to spend time with them, so that, ultimately, they have a better chance of getting laid, so that, ultimately, their selfish DNA will get to replicate itself. Maybe they are using a spreadsheet to try and figure out if they can afford a bigger apartment, so that, ultimately, dates will be more impressed when they come over, increasing their chance of getting laid, again, benefitting the DNA. Maybe they’re working on a PowerPoint for the boss so that they will get a promotion so that they’ll have more money which they can use to rent a larger apartment that would attract mates, thus increasing their chance of getting laid, (getting the idea yet?) so the selfish DNA can replicate. Maybe they are looking for a recipe for goat cheese ravioli on the Internet, etc., etc., … DNA.

Unless they’re software reviewers for a living, they don’t really care about the software itself, and the more they notice it, the more annoyed they’re going to be.

Choices, therefore, can be good or bad. They’re good when they support the task the user is trying to accomplish fairly directly. I want to be able to choose who to chat with (duh.) They’re bad when they represent an intrusion into the user’s actual DNA-replication goals. Every few days some crappy software I can’t even remember installing pops up noisy bulletins asking me if I want to upgrade something or other. I could not care LESS. I’m doing something. Leave me alone! I’m sure that the team at Sun Microsystems who just released this fabulous new version of the Java virtual machine have been thinking about the incremental release night and day for months and months, but the other 5,000,000,000 of us here on the planet really don’t give a flying monkey. You just cannot imagine how little I want to spend even three seconds of my life thinking about whether or not to install that new JVM. Somebody out there is already firing up Gmail to tell me that the JVM mustn’t just upgrade itself “because that might break something.” Yeah, if the entire collective wisdom of the Java development team doesn’t know if it’s going to break something, how am I supposed to know? Sheeesh.

If you’re using the term simplicity to mean “grace and economy” or “elegance,” that’s terrific. A great example of this is the difference between the way you search for music on Rhapsody and the way you search for music on iTunes. Rhapsody makes you decide if you want to search for albums, tracks, or artists. iTunes doesn’t give you any choice: it just searches all fields, which works just as well and is easier. Economy means power, in this case, and it’s a feature.

On the other hand, if you’re using simplicity to mean a lack of power, a lack of features, that’s fine, if you want to be in the paper clip business, good luck with that, but the chances that your product will solve my exact problems starts to shrink and your potential market share does, too.

by Joel Spolsky

Simplicity

Donald Norman concludes that simplicity is overrated: “But when it came time for the journalists to review the simple products they had gathered together, they complained that they lacked what they considered to be ‘critical’ features. So, what do people mean when they ask for simplicity? One-button operation, of course, but with all of their favorite features.”

A long time ago, I wrote: “A lot of software developers are seduced by the old ‘80/20’ rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

“Unfortunately, it’s never the same 20%. Everybody uses a different set of features. In the last 10 years I have probably heard of dozens of companies who, determined not to learn from each other, tried to release ‘lite’ word processors that only implement 20% of the features. This story is as old as the PC. Most of the time, what happens is that they give their program to a journalist to review, and the journalist reviews it by writing their review using the new word processor, and then the journalist tries to find the ‘word count’ feature which they need because most journalists have precise word count requirements, and it’s not there, because it’s in the ‘80% that nobody uses,’ and the journalist ends up writing a story that attempts to claim simultaneously that lite programs are good, bloat is bad, and I can’t use this damn thing ‘cause it won’t count my words.”

Making simple, 20% products is an excellent bootstrapping strategy because you can create them with limited resources and build an audience. It’s a Judo strategy, using your weakness as a strength, like the way the Blair Witch Project, filmed by kids with no money at all, used the only camera they could afford, a handheld video camera, but they invented a plot in which that was actually a virtue. So you sell “simple” as if it were this wonderful thing, when, coincidentally, it’s the only thing you have the resources to produce. Happy coincidence, that’s all, but it really is wonderful!

What works for bootstrapping, I believe, will not work as a good long term strategy, because there’s very little to prevent the next two-person startup from cloning your simple app, and because eventually you can’t fight human nature: “The people want the features,” says Norman. Just because handheld video was perfect for Blair Witch, doesn’t mean every Hollywood blockbuster will use it.

Devotees of simplicity will bring up 37signals and the Apple iPod as anecdotal proof that Simple Sells. I would argue that in both these cases, success is a result of a combination of things: building an audience, evangelism, clean and spare design, emotional appeal, aesthetics, fast response time, direct and instant user feedback, program models which correspond to the user model resulting in high usability, and putting the user in control, all of which are features of one sort, in the sense that they are benefits that customers like and pay for, but none of which can really be described as “simplicity.” For example, the iPod has the feature of being beautiful, which the Creative Zen Ultra Nomad Jukebox doesn’t have, so I’ll take an iPod, please. In the case of the iPod, the way beauty is provided happens to be through a clean and simple design, but it doesn’t have to be. The Hummer is aesthetically appealing precisely because it’s ugly and complicated.

I think it is a misattribution to say, for example, that the iPod is successful because it lacks features. If you start to believe that, you’ll believe, among other things, that you should take out features to increase your product’s success. With six years of experience running my own software company I can tell you that nothing we have ever done at Fog Creek has increased our revenue more than releasing a new version with more features. Nothing. The flow to our bottom line from new versions with new features is absolutely undeniable. It’s like gravity. When we tried Google ads, when we implemented various affiliate schemes, or when an article about FogBugz appears in the press, we could barely see the effect on the bottom line. When a new version comes out with new features, we see a sudden, undeniable, substantial, and permanent increase in revenue.

If you’re using the term “simplicity” to refer to a product in which the user model corresponds closely to the program model, so the product is easy to use, fine, more power to ya. If you’re using the term “simplicity” to refer to a product with a spare, clean visual appearance, so the term is nothing more than an aesthetic description much in the same way you might describe Ralph Lauren clothes as “Southampton WASP,” fine, more power to ya. Minimalist aesthetics are quite hip these days. But if you think simplicity means “not very many features” or “does one thing and does it well,” then I applaud your integrity but you can’t go that far with a product that deliberately leaves features out. Even the iPod has gratuitous Solitaire game. Even Ta-da List supports RSS.

Anyway, I gotta go … it’s time to go upgrade my cellphone to one that includes high speed internet access, email, a podcast catcher, and an MP3 player.