Month / May 2000

by Joel Spolsky

2000/05/26

Seth Gordon emailed me some great tips for reading other people’s source code. Reading Code is Like Reading the Talmud

Ramon Garcia Fernandez writes:

In your essay ‘Things you should never do, Part I’ you are against rewriting source code. But, what if the author of some source code is not available? What methods would you recommend to understand code written by another programmer? This situation is often encountered in the free software world, where you would rather reuse an existing program than write one from scratch, but it is difficult to read code written by another programmer.

My response:

I think the best way to read somebody else’s code is just to SLOW DOWN… it’s like deciphering a code, not like reading. Most people have trouble reading code because their eyes are used to reading at a certain speed from reading text written in human languages. But code is much more dense than English, and contains ‘secrets’ that need to be deciphered by looking elsewhere: for example, when you see that function call that says UpdateData(FALSE), unless you remember how UpdateData() works, you have to go look for it to figure out what the first argument is and what FALSE means.
It takes some skill to learn how to read code slowly and carefully, and many programmers are not patient enough (so they wind up rewriting the code from scratch). But you have to remember that it’s still faster to read than to rewrite!

While we’re at it, Lou Montulli, one of the founding engineers of Netscape and the creator of Lynx, sent me the following response to my plea never to start over from scratch in ‘Things You Should Never Do’:

I agree completely, it’s one of the major reasons I resigned from Netscape. In 1998, after wasting a year wanking, a group of new but experienced programmers, and one of our misguided founders, decided it was a good idea to rewrite everything. I had alot of vested interest since I had done most of the original design work on Navigator, but I was unable to supply enough visions of doom to divert the effort. The original design had degenerated substantially due to the integration of Java and the rapid pace of zig zag development that went on over the course of 4 years. There was good reason for a large change, but rewriting everything was a bit overboard to say the least. I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.

Alfie Kohn: While rewards are effective at producing temporary compliance, they are strikingly ineffective at producing lasting changes in attitudes or behavior.

by Joel Spolsky

Strategy Letter II: Chicken and Egg Problems

The idea of advertising is to lie without getting caught. Most companies, when they run an advertising campaign, simply take the most unfortunate truth about their company, turn it upside down (“lie”), and drill that lie home. Let’s call it “proof by repeated assertion.” For example, plane travel is cramped and uncomfortable and airline employees are rude and unpleasant, indeed the whole commercial air system is designed as a means of torture. So almost all airline ads are going to be about how comfortable and pleasant it is to fly and how pampered you will be every step of the way. When British airways showed an ad with a businessman in a plane seat dreaming that he was a baby in a basket, all sense of reasonableness was gone for good. 

Need another example? Paper companies are completely devastating our national forests, clear cutting old growth forest which they don’t even own. So when they advertise, they inevitably show some nice old pine forest and talk about how much they care about the environment. Cigarettes cause death, so their ads show life, like all the ads with happy smiling healthy people exercising outdoors. And so on.

When the Macintosh first came out, there was no software available for it. So obviously, Apple created a giant glossy catalog listing all the great software that was “available”. Half of the items listed said, in fine print, “under development,” and the other half couldn’t be had for love or money. Some were such lame products nobody would buy them. But even having a thick glossy catalog with one software “product” per page described in glowing prose couldn’t disguise the fact that you just could not buy a word processor or spreadsheet to run on your 128KB Macintosh. There were similar “software product guides” for NeXT and BeOS. (Attention, NeXT and BeOS bigots: I don’t need any flak about your poxy operating systems, OK? Write your own column.) The only thing a software product guide tells you is that there is no software available for the system. When you see one of these beasts, run fleeing in the opposite direction.

Amiga, Atari ST, Gem, IBM TopView, NeXT, BeOS, Windows CE, General Magic, the list of failed “new platforms” goes on and on. Because they are platforms, they are, by definition, not very interesting in and of themselves without juicy software to run on them. But, with very few exceptions (and I’m sure I’ll get a whole host of email from tedious supporters of arcane and unloved platforms like the Amiga or RSTS-11), no software developer with the least bit of common sense would intentionally write software for a platform with 100,000 users on a good day, like BeOS, when they could do the same amount of work and create software for a platform with 100,000,000 users, like Windows. The fact that anybody writes software for those oddball systems at all proves that the profit motive isn’t everything: religious fervor is still alive and well. Good for you, darling. You wrote a nice microEmacs clone for the Timex Sinclair 1000. Bravo. Here’s a quarter, buy yourself a treat.

So. If you’re in the platform creation business, you are probably going to suffer from what is commonly known as the chicken and egg problem. Nobody is going to buy your platform until there’s good software that runs on it, and nobody is going to write software until you have a big installed base. Ooops. It’s sort of like a Gordian Knot, although a Gordian Death Spiral might be more descriptive.

The chicken and egg problem, and variants thereof, is the most important element of strategy to understand. Well, OK, you can probably live without understanding it: Steve Jobs practically made a career out of not understanding the chicken and egg problem, twice. But the rest of us don’t have Jobs’ Personal Reality Distortion Field at our disposal, so we’ll have to buckle down and study hard.

Lesson one. The classic domain of chicken and egg problems is in software platforms. But here’s another chicken and egg problem: every month, millions of credit card companies mail out zillions of bills to consumers in the mail. People write paper checks, stuff them in trillions of envelopes, and mail them back. The envelopes are put in big boxes and taken to countries where labor is cheap to be opened and processed. But the whole operation costs quite a bit: the last figure I heard was that it is more than $1 per bill.

To us Internet wise-guys, that’s a joke. “Email me my bill”, you say. “I’ll pay it online!” You say. “It’ll only cost, say, 1/100000th of a penny. You’ll save millions” Or something like that.

And you’re right. So a lot of companies have tried to get into this field, which is technically known as Bill Presentment. One example is (guess who) Microsoft. Their solution, TransPoint, looks like this: it’s a web site. You go there, and it shows you your bills. You pay them. 

So, now, if you get your bills on this Microsoft system, you have to visit the web page every few days to see if any bills have arrived so you don’t miss them. If you get, say, 10 bills a month, this might not be too big a hassle. Therein lies the other problem: there are only a small handful of merchants that will bill you over this system. So for all your other bills, you’ll have to go elsewhere.

End result? It’s not worth it. I would be surprised if 10,000 people are using this system. Now, Microsoft has to go to merchants and say, “bill your customers over our system!” And the merchants will say, “OK! How much will it cost?” And Microsoft will say, “50 cents! But it’s a lot cheaper than $1!” And the merchants will say, “OK. Anything else?” And Microsoft will say, “Oh yes, it will cost you about $250,000 to set up the software, connect our systems to your systems, and get everything working.”

And since Microsoft has so few dang users on this system, it’s hard to imagine why anyone would pay $250,000 to save 50 cents on 37 users. Aha! The chicken and egg problem has reared its ugly head! Customers won’t show up until you have merchants, and merchants won’t show up until you have customers! Eventually, Microsoft is just going to spend their way out of this predicament. For smaller companies, that’s not an option. So what can you do?

Software platforms actually gives us some nice hints as to how to roast your chicken and egg problem. Let’s look a bit at the history of personal computer software platforms in the years since the IBM-PC came out; maybe we’ll discover something!

Most people think that the IBM-PC required PC-DOS. Not true. When the IBM-PC first came out, you had a choice of three operating systems: PC-DOS, XENIX (a wimpy 8 bit version of UNIX published by, and I am not making this up, Microsoft), and something called UCSD P-System, which was, if you can believe this, just like Java: nice, slow, portable bytecodes, about 20 years before Java.

Now, most people have never heard of XENIX or UCSD’s weirdo stuff. You kids today probably think that this is because Microsoft took over the market for dinky operating systems through marketing muscle or something. Absolutely not true; Microsoft was tiny in those days. The company with the marketing muscle was Digital Research, which had a different operating system.  So, why was PC-DOS the winner of the three way race?

Before the PC, the only real operating system you could get was CP/M, although the market for CP/M based computers, which cost about $10,000, was too small. They were cranky and expensive and not very user friendly. But those who did buy them, did so to use as word processors, because you could get a pretty good word processor called WordStar for CP/M, and the Apple II just could not do word processing (it didn’t have lower case, to begin with).

Now, here’s a little known fact: even DOS 1.0 was designed with a CP/M backwards compatibility mode built in. Not only did it have its own spiffy new programming interface, known to hard core programmers as INT 21, but it fully supported the old CP/M programming interface. It could almost run CP/M software. In fact,  WordStar was ported to DOS by changing one single byte in the code. (Real Programmers can tell you what that byte was, I’ve long since forgotten).

That bears mentioning again. WordStar was ported to DOS by changing one single byte in the code.  Let that sink in.

There.

Got it?

DOS was popular because it had software from day one. And it had software because Tim Paterson had thought to include a CP/M compatibility feature in it, because way back in the dark ages somebody was smart about chicken and egg problems.

Fast forward. In the entire history of the PC platform, there have only been two major paradigm shifts that took along almost every PC user: we all switched to Windows 3.x, and then we all switched to Windows 95. Only a tiny number of people ever switched to anything else on the way. Microsoft conspiracy to take over the world? Fine, you’re welcome to think that. I think it’s for another, more interesting reason, which just comes back to the chicken and the egg.

We all switched to Windows 3.x. The important clue in that sentence is the 3. Why didn’t we all switch to Windows 1.0? Or Windows 2.0?  Or Windows 286 or Windows 386 which followed? Is it because it takes Microsoft five releases to “get it right”? No.

The actual reason was even more subtle than that, and it has to do with a very arcane hardware features that first showed up on the Intel 80386 chip which Windows 3.0 required.

  • Feature one: old DOS programs put things on the screen by writing directly to memory locations which corresponded to character cells on the screen. This was the only way to do output fast enough to make your program look good. But Windows ran in graphics mode. On older Intel chips, the Microsoft engineers had no choice but to flip into full screen mode when they were running DOS programs. But on the 80386, they could set up virtual memory blocks and set interrupts so that the operating system was notified whenever a program tried to write to screen memory. Windows could then write the equivalent text into a graphical window on the screen instantly.
  • Feature two: old DOS programs assumed they had the run of the chip. As a result, they didn’t play well together. But the Intel 80386 had the ability to create “virtual” PCs, each of them acting like a complete 8086, so old PC programs could pretend like they had the computer to themselves, even while other programs were running and, themselves, pretending they had the whole computer to themselves.

So Windows 3.x on Intel 80386s was the first version that could run multiple DOS programs respectably. (Technically, Windows 386 could too, but 80386s were rare and expensive until about the time that Windows 3.0 came out.) Windows 3.0 was the first version that could actually do a reasonable job running all your old software.

Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.

You should be starting to get some ideas about how to break the chicken and egg problem: provide a backwards compatibility mode which either delivers a truckload of chickens, or a truckload of eggs, depending on how you look at it, and sit back and rake in the bucks.

Ah. Now back to bill presentment. Remember bill presentment? The chicken-egg problem is that you can only get your Con Ed bills, so you won’t use the service. How can you solve it? Microsoft couldn’t figure it out. PayMyBills.com (and a half dozen other Silicon Valley startups) all figured it out at the same time. You provide a backwards compatibility mode: if the merchant won’t support the system, just get the merchant to mail their damn paper bills to University Avenue, in Palo Alto, where a bunch of actual human beings will open them and scan them in. Now you can get all your bills on their web site. Since every merchant on earth is available on the system, customers are happy to use it, even if it is running in this weird backwards compatibility mode where stupid Visa member banks send the bill electronically to a printer, print it out on paper, stuff it in an envelope, ship it 1500 miles to California, where it is cut open, the stupid flyers harping worthless “free” AM clock radios that actually cost $9.95 are thrown into a landfill somewhere, and the paper bill is scanned back into a computer and stuck up on the web where it should have been sent in the first place. But the stupid backwards compatibility mode will eventually go away, because PayMyBills.com, unlike Microsoft, can actually get customers to use their system, so pretty soon they’ll be able to go to the stupid Visa member banks and say, “hey, I’ve got 93,400 of your customers. Why don’t you save yourselves $93,400 each month with a direct wire connection to me?” And suddenly PayMyBills.com is very profitable while Microsoft is still struggling to sign up their second electric utility, maybe one serving Georgia would be a nice change of pace.

Companies that fail to recognize the Chicken and Egg problem can be thought of as boil the ocean companies: their business plan requires 93,000,000 humans to cooperate with their crazy business scheme before it actually works. One of the most outrageously stupid ideas I ever encountered was called ActiveNames. Their boneheaded idea was that everybody in the world would install a little add-in to their email client which looked up people’s names on their central servers to get the actual email address. Then instead of telling people that your email address is kermit@sesame-street.com, you would tell them that your ActiveName is “spolsky”, and if they want to email you, they need to install this special software. Bzzzzzt. Wrong answer. I can’t even begin to list all the reasons this idea is never going to work.

Conclusion: if you’re in a market with a chicken and egg problem, you better have a backwards-compatibility answer that dissolves the problem, or it’s going to take you a loooong time to get going (like, forever).

There are a lot of other companies that recognized the chicken and egg problem face on and defeated it intelligently. When Transmeta unveiled their new CPU, it was the first time in a long time that a company that was not Intel finally admitted that if you’re a CPU, and you want a zillion people to buy you, you gotta run x86 code. This after Hitachi, Motorola, IBM, MIPS, National Semiconductor, and who knows how many other companies deceived themselves into thinking that they had the right to invent a new instruction set. The Transmeta architecture assumes from day one that any business plan that calls for making a computer that doesn’t run Excel is just not going anywhere.

by Joel Spolsky

Strategy Letter I: Ben and Jerry’s vs. Amazon

Building a company? You’ve got one very important decision to make, because it affects everything else you do. No matter what else you do, you absolutely must figure out which camp you’re in, and gear everything you do accordingly, or you’re going to have a disaster on your hands.

The decision? Whether to grow slowly, organically, and profitably, or whether to have a big bang with very fast growth and lots of capital.

The organic model is to start small, with limited goals, and slowly build a business over a long period of time. I’m going to call this the Ben and Jerry’s model, because Ben and Jerry’s fits this model pretty well.

The other model, popularly called “Get Big Fast” (a.k.a. “Land Grab”), requires you to raise a lot of capital, and work as quickly as possible to get big fast without concern for profitability. I’m going to call this the Amazon model, because Jeff Bezos, the founder of Amazon, has practically become the celebrity spokesmodel for Get Big Fast.

Let’s look at some of the differences between these models. The first thing to ask is: are you going into a business that has competition, or not?

Ben and Jerry’s Amazon
Lots of established competitors New technology, no competition at first

If you don’t have any real competition, like Amazon, there is a chance that you can succeed at a “land grab”, that is, get as many customers as quickly as possible, so that later competitors will have a serious barrier to entry. But if you’re going into an industry where there is already a well-established set of competitors, the land-grab idea doesn’t make sense. You need to create your customer base by getting customers to switch over from competitors. 

In general, venture capitalists aren’t too enthusiastic about the idea of going into a market with pesky competitors. Personally, I’m not so scared of established competition; perhaps because I worked on Microsoft Excel during a period when it almost completely took over Lotus 123, which virtually had the market to themselves. The number one word processor, Word, displaced WordPerfect, which displaced WordStar, all of which had been near monopolies at one time or another. And Ben and Jerry’s grew to be a fabulous business, even though it’s not like you couldn’t get ice cream before they came along. It’s not impossible to displace a competitor, if that’s what you want to do. (I’ll talk about how to do that in a future Strategy Letter).

Another question about displacing competitors has to do with network effects and lock-in:

Ben and Jerry’s Amazon
No network effect; weak customer lock-in Strong network effect, strong customer lock-in

A “network effect” is a situation where the more customers you have, the more customers you will get. It’s based on Metcalfe’s Law: the value of a network is equal to the number of users squared.

A good example is eBay. If you want to sell your old Patek Philippe watch, you’re going to get a better price on eBay, because there are more buyers there. If you want to buy a Patek Philippe watch, you’re going to look on eBay, because there are more sellers there.

Another extremely strong network effect is proprietary chat systems like ICQ or AOL Instant Messenger. If you want to chat with people, you have to go where they are, and ICQ and AOL have the most people by far. Chances are, your friends are using one of those services, not one of the smaller ones like MSN Instant Messenger. With all of Microsoft’s muscle, money, and marketing skill, they are just not going to be able to break into auctions or instant messaging, because the network effects there are so strong.

“Lock-in” is where there is something about the business that makes people not want to switch. Nobody wants to switch their Internet provider, even if the service isn’t very good, because of the hassle of changing your email address and notifying everyone of the new email address. People don’t want to switch word processors if their old files can’t be read by the new word processor.

Even better than lock-in is the sneaky version I call stealth lock-in: services which lock you in without your even realizing it. For example, all those new services like PayMyBills.com which receive your bills for you, scan them in, and show them to you on the Internet. They usually come with three months free service. But when the three months are up, if you don’t want to continue with the service, you have no choice but to contact every single bill provider and ask them to change the billing address back to your house. The sheer chore of doing this is likely to prevent you from switching away from PayMyBills.com — better just to let them keep sucking $8.95 out of your bank account every month. Gotcha!

If you are going into a business that has natural network effects and lock-in, and there are no established competitors, then you better use the Amazon model, or somebody else will, and you simply won’t be able to get a toehold.

Quick case study. In 1998, AOL was spending massively to grow at a rate of a million customers every five weeks.  AOL has nice features like chat rooms and instant messaging that provide stealth lock-in. Once you’ve found a group of friends you like to chat with, you are simply not going to switch Internet providers. That’s like trying to get all new  friends. In my mind that’s the key reason that AOL can charge around $22 a month when there are plenty of $10 a month Internet providers. 

While I was working at Juno, management just failed to understand this point, and they missed their best opportunity to overtake AOL during a land rush when everyone was coming online: they didn’t spend strongly enough on customer acquisition because they didn’t want to dilute existing shareholders by raising more capital, and they didn’t think strategically about chat and IM, so they never developed any software features to provide the kind of stealth lock-in that AOL has. Now Juno has around 3 million people paying them an average of $5.50 a month, while AOL has around 21 million people paying them an average of $17 a month. “Oops.”

Ben and Jerry’s Amazon
Little capital required; break even fast Outrageous amounts of capital required; profitability can take years

Ben and Jerry’s companies start on somebody’s credit card. In their early months and years, they have to use a business model that becomes profitable extremely quickly, which may not be the ultimate business model that they want to achieve. For example, you may want to become a giant ice cream company with $200,000,000 in annual sales, but for now, you’re going to have to settle for opening a little ice cream shop in Vermont, hope that it’s profitable, and, if it is, reinvest the profits to expand business steadily. The Ben and Jerry’s corporate history says they started with a $12,000 investment. ArsDigita says that they started with an $11,000 investment. These numbers sound like a typical MasterCard credit limit. Hmmm.

Amazon companies raise money practically as fast as anyone can spend it. There’s a reason for this. They are in a terrible rush. If they are in a business with no competitors and network effects, they better get big super-fast. Every day matters. And there are lots of ways to substitute money for time (see sidebar). Nearly all of them are fun.

Ways to substitute money for time:

  • Use prebuilt, furnished executive offices instead of traditional office space. Cost: about 3 times as much. Time saved: several months to a year, depending on market.
  • Pay outrageous salaries or offer programmers BMWs as starting bonuses. Cost: about 25% extra for technical staff. Time saved: you can fill openings in 3 weeks instead of the more typical 6 months.
  • Hire consultants instead of employees. Cost: about 3 times as much. Time saved: you can get consultants up and running right away.
  • Having trouble getting your consultants to give you the time and attention you need? Bribe them with cash until they only want to work for you.
  • Spend cash freely to spot-solve problems. If your new star programmer isn’t getting a lot of work done because they are busy setting up their new house and relocating, hire a high class relocation service to do it for them. If it’s taking forever to get phones installed in your new offices, buy a couple of dozen cellular phones. Internet access problems slowing people down? Just get two redundant providers. Provide a concierge available to all employees for picking up dry cleaning, getting reservations, arranging for limos to the airport, etc.

Ben and Jerry’s companies just can’t afford to do this, so they have to settle for growing slowly.

Ben and Jerry’s Amazon
Corporate culture is important Corporate culture is impossible

When you are growing faster than about 100% per year, it is simply impossible for mentors to transmit corporate values to new hires. If a programmer is promoted to manager and suddenly has 5 new reports, hired just yesterday, it is simply impossible for there to be very much mentoring. Netscape is the most egregious example of this, growing from 5 to about 2000 programmers in one year. As a result, their culture was a mishmash of different people with different values about the company, all tugging in different directions.

For some companies, this might be OK. For other companies, the corporate culture is an important part of the raison-d’être of the company. Ben and Jerry’s exists because of the values of the founders, who would not accept growing faster than the rate at which that culture can be promulgated. 

Let’s take a hypothetical software example. Suppose you want to break into the market for word processors. Now, this market seems to be pretty sewn up by Microsoft, but you see a niche for people who, for whatever reason, absolutely cannot have their word processors crashing on them. You are going to make a super-robust, industrial strength word processor that just won’t go down and sell it at a premium to people who simply depend on word processors for their lives. (OK, it’s a stretch. I said this was a hypothetical example).

Now, your corporate culture probably includes all kinds of techniques for writing highly-robust code: unit testing, formal code reviews, coding conventions, large QA departments, and so on. These techniques are not trivial; they must be learned over a period of time. While a new programmer is learning how to write robust code, they need to be mentored and coached by someone more experienced.

As soon as you try to grow so fast that mentoring and coaching is impossible, you are simply going to stop transmitting those values. New hires won’t know better and will write unreliable code. They won’t check the return value from malloc(), and their code will fail in some bizarre case that they never thought about, and nobody will have time to review their code and teach them the right way to do it, and your entire competitive advantage over Microsoft Word has been squandered.

Ben and Jerry’s Amazon
Mistakes become valuable lessons Mistakes are not really noticed

A company that is growing too fast will simply not notice when it makes a big mistake, especially of the spend-too-much-money kind. Amazon buys Junglee, a comparison shopping service, for around $180,000,000 in stock, and then suddenly realizes that comparison shopping services are not very good for their business, so they just shut it down. Having piles and piles of cash makes stupid mistakes easy to cover up.

Ben and Jerry’s Amazon
It takes a long time to get big You get big very fast

Getting big fast gives the impression (if not the reality) of being successful. When prospective employees see that you’re hiring 30 new people a week, they will feel like they are part of something big and exciting and successful which will IPO. They may not be as impressed by a “sleepy little company” with 12 employees and a dog, even if the sleepy company is profitable and is building a better long-term company.


A sleepy little company in Albuquerque

As a rule of thumb, you can make a nice place to work, or you can promise people they’ll get rich quick. But you have to do one of those, or you won’t be able to hire.

Some of your employees will be impressed by a company with a high chance of an IPO that gives out lots of stock options. Such people will be willing to put in three or four years at a company like this, even if they hate every minute of their working days, because they see the pot at the end of the rainbow.

If you’re growing slowly and organically, the pot may be farther off. In that case, you have no choice but to make a work environment where the journey is the reward. It can’t be hectic 80 hour workweeks. The office can’t be a big noisy loft jammed full of folding tables and hard wooden chairs. You have to give people decent vacations. People have to be friends with their co-workers, not just co-workers. Sociology and community at work matter. Managers have to be enlightened and get off people’s backs, they can’t be Dilbertesque micromanagers. If you do all this, you’ll attract plenty of people who have been fooled too many times by dreams of becoming a millionaire in the next IPO; now they are just looking for something sustainable.

Ben and Jerry’s Amazon
You’ll probably succeed. You certainly won’t lose too much money. You have a tiny chance of becoming a billionaire, and a high chance of just failing.

With the Ben and Jerry’s model, if you’re even reasonably smart, you’re going to succeed. It may be a bit of a struggle, there may be good years and bad years, but unless we have another depression, you’re certainly not going to lose too much money, because you didn’t put in too much to begin with.

The trouble with the Amazon model is that all anybody thinks about is Amazon. And there’s only one Amazon. You have to think of the other 95% of companies which spend an astonishing amount of venture capital and then simply fail because nobody wants to buy their product. At least, if you follow the Ben and Jerry’s model, you’ll know that nobody wants your product long before you spend more than one MasterCard’s worth of credit limit on it.

The Worst Thing You Can Do

The worst thing you can do is fail to decide whether you’re going to be a Ben and Jerry’s company or an Amazon company.

If you’re going into a market with no existing competition, lock-in, and network effects, you better use the Amazon model, or you’re going the way of Wordsworth.com, which started two years before Amazon, and nobody’s ever heard of them. Or even worse, you’re going to be a ghost site like MSN Auctions with virtually no chance of ever overcoming ebay. (Read Wordsworth’s reply )

If you’re going into an established market, getting big fast is a fabulous way of wasting tons of money, as did BarnesandNoble.com. Your best hope is to do something sustainable and profitable, so that you have years to slowly take over your competition.

Still can’t decide? There are other things to consider. Think of your personal values. Would you rather have a company like Amazon or a company like Ben and Jerry’s? Read a couple of corporate histories – Amazon and Ben and Jerry’s for starters, even though they are blatant hagiographies, and see which one jibes more with your set of core values. Actually, an even better model for a Ben and Jerry’s company is Microsoft, and there are lots of histories of Microsoft. Microsoft was, in a sense, “lucky” to land the PC-DOS deal, but the company was profitable and growing all along, so they could have hung around indefinitely waiting for their big break.

Think of your risk/reward profile. Do you want to take a shot at being a billionaire by the time you’re 35, even if the chances of doing that make the lottery look like a good deal? Ben and Jerry’s companies are not going to do that for you.

Probably the worst thing you can do is to decide that you have to be an Amazon company, and then act like a Ben and Jerry’s company (while in denial all the time). Amazon companies absolutely must substitute cash for time whenever they can. You may think you’re smart and frugal by insisting on finding programmers who will work at market rates. But you’re not so smart, because that’s going to take you six months, not two months, and those 4 months might mean you miss the Christmas shopping season, so now it cost you a year, and probably made your whole business plan unviable. You may think that it’s smart to have a Mac version of your software, as well as a Windows version, but if it takes you twice as long to ship while your programmers build a compatibility layer, and you only get 15% more customers, well, you’re not going to look so smart, then, are you?

Both models work, but you’ve got to pick one and stick to it, or you’ll find things mysteriously going wrong and you won’t quite know why.

Further reading: The Motley Fool review

by Joel Spolsky

2000/05/12

Are you a Ben and Jerry’s company or an Amazon company?

In Strategy Letter I, I talk about two different kinds of startups. If you don’t know which one you are, you’re going to make lots of mistakes and you won’t even know why.

Sometimes, my kind readers resort to tricks to find out if I’m awake! Like this suggestion from Hanan. It sounds good at first, but after a minute you realize it might be a minefield.

by Joel Spolsky

2000/05/10

Despite the fact that raging search, an AltaVista spinoff, is a blatant ripoff of Google in every way, it still produces pathetic search results. (Compare the result of searching for President Clinton on raging and google and you’ll see what I mean.)

From Juno’s latest “Privacy” statement:
In addition to the data you may provide through the Member Profile and other surveys, we may collect information relating to how you use the Service (including, for example, information relating to your frequency of use, navigational information such as the uniform resource locator (URL) of the Web pages you visit, configuration information such as the type of Web browser you are using, your Internet Protocol (IP) address, processor type and operating system, and information relating to the display of any advertisements transmitted to you).
This steady erosion of privacy dismays me. The Juno database will have your name and address and the web pages you visited, for 3 million Americans who use the service every month.

If I had still been working at Juno, I would have probably been assigned to implement this feature. I would like to think that I would have refused on principle, even if it cost me my job. Maybe my taking a stand would have inspired other people to refuse to go along (not that that would have changed anything — management would just gather us all in a room and scream at us.)

Then again, it’s hard to say “I would have taken a stand,” since I wasn’t really there, and I didn’t really take a stand. Lucky for me, I quit way back in November, and so my integrity never stood the test.

Don’t worry, I’m not retired now just because the UI book is done. I’ve still got a half dozen articles in the pipeline! Then I can retire 😉

by Joel Spolsky

The Process of Designing a Product

We’ve talked about the principles of good design, but principles only give you a way to evaluate and improve an existing design. But… how do you figure out what the dang design should be in the first place? Many people write big, functional outlines of all the features they thought up. Then they design each one, and hang it off of a menu item (or web page). When they’re done, the program (or web site) has all the functionality they wanted, but it doesn’t flow right. People sit down and they don’t know what it does, and they don’t know how to accomplish what they want.

Microsoft’s solution to this is something called Activity Based Planning. (As far as I can tell, this concept was invented by Mike Conte on the Excel team, who got bored with that and went on to a second career as a race car driver). The key insight is to figure out the activity that the user is doing, and focus on making it easy to accomplish that activity. This is best illustrated with an example.

You’ve decided to make a web site that lets people create greeting cards. Using a somewhat naïve approach, you might come up with a list of features like this:

1. Add text to card
2. Add picture to card
3. Get predesigned card from library
4. Send card:
           a. Using email
           b. By printing it out

For lack of any better way of thinking about the problem, this might lead itself to a typical Macintosh user interface, circa-1984: a program that starts out with a blank card, with menu items for adding text, pictures, loading cards from a library, and sending cards. And then what the user is going to have to do is sit down and browse through the menus, trying to figure out all the commands available, and then do their own synthesis of how to put these atomic commands together to create a card.

Now, activity based planning says that you need to come up with a list of activities that users might do. So, you talk to your potential users, and you come up with this “top three” list:

  1. Birthday Greeting
  2. Party Invitation
  3. Anniversary Greeting

Now, instead of thinking about your program like a programmer (in terms of what features you need to have to make a card), you’re thinking about it like the user, in terms of, what activities is the user doing, specifically:

  1. Sending a birthday card
  2. Planning a party, and inviting people to it
  3. Sending an anniversary card

Suddenly, all kinds of ideas will rush into your head. Instead of starting with a blank card, you might start with a menu like this:

What do you want to do?

  • Send a birthday card
  • Send an anniversary card
  • Send a party invitation
  • Start with a blank card

Suddenly users will find it much easier to get started with your program, without browsing around on the menus, since the program will virtually lead them through the steps to complete the activity. (There is a risk that if you didn’t pick the activities correctly, you will alienate or confuse users who might have been able to use your program, say, to send a Hanukah card, but don’t see that as a choice. So be careful in picking activities that blanket the majority of the market you want to target.)

Just looking at our list of three activities suggests some great features which you might want to add. For example, if you’re sending a birthday or anniversary card, you might want to be reminded next year to send a card to the same person… so you might add a checkbox that says “remind me next year”. And a party invitation needs a way to RSVP, so you might add a feature that lets you collect RSVPs from people electronically. Both of these feature ideas almost fell out of looking at the activity that users were performing instead of the features in the application.

This example is trivial; for any serious application, the rewards of activity based planning are even greater. When you’re designing a program from scratch, you already have a vision of what activities your users are going to be doing. Figuring out this vision is not hard at all, it takes almost no effort at all to do some brainstorming with coworkers, write down a list of potential activities, and then decide which ones you want to focus on. But forcing yourself to list these activities on paper will help your overall design enormously. 

Activity based planning is even more important when you are working on version two of a product that people are already using. Here, it may be a matter of observing a sample of customers to see what they are using your program for. 

In the days of Excel 1.0 through 4.0, most people at Microsoft thought that the most common user activity was doing financial what-if scenarios, where you do things like change the inflation rate and see how this affects your profitability. 

When we were designing Excel 5.0, the first major release to use serious activity-based planning, we only had to watch about five customers using the product before we realized that an enormous number of people just use Excel to keep lists. They are not entering any formulas or doing any calculation at all! We hadn’t even considered this before. Keeping lists turned out to be far more popular than any other activity with Excel. And this led us to invent a whole slew of features that make it easier to keep lists: easier sorting, automatic data entry, the AutoFilter feature which helps you see a slice of your list, and multi-user features which let several people work on the same list at the same time while Excel automatically reconciles everything.

While Excel 5 was being designed, Lotus had shipped a “new paradigm” spreadsheet called Improv. According to the press releases, Improv was a whole new generation of spreadsheet, which was going to blow away everything that existed before it. For various strange reasons, Improv was first available on the NeXT, which certainly didn’t help its sales, but a lot of smart people believed that Improv would be to NeXT as VisiCalc was to the Apple II: it would be the killer app that made people go out and buy all new hardware just to run one program.

Of course, Improv is now a footnote in history. Search for it on the web, and the only links you’ll find are from very over-organized storeroom managers who have, for some reason, made a web site with an inventory of all the stuff they have collecting dust.

Why? Because in Improv, it was almost impossible to just make lists. The Improv designers thought that people were using spreadsheets to create complicated multi-dimensional financial models. Turns out, if they asked people, they would discover that making lists was so much more common than multi-dimensional financial models, and in Improv, making lists was a downright chore, if not impossible.

So activity based planning is helpful in the initial version of your application, where you have to make guesses about what people want to do, but it’s even more helpful when you’re planning the upgrade, because you understand what your customers are doing.

Another example, from the web, is the evolution of deja.com, which started out as an huge, searchable index of Usenet called dejanews. The original interface basically had an edit box and said “search Usenet for blah,” and that was it. In 1999 a bit of activity based planning showed that one common user activity was doing research on a product or service, of the “which car should I buy” nature. Deja was completely reorganized, and today, it is more of a product opinion research service: the Usenet searching ability is almost completely hidden. This annoyed the small number of users who were using the site to search for whether their Matrox video card worked with Redhat Linux 5.1, but it delighted the much larger population of users who just wanted to buy the best digital camera.

The other great thing about activity based planning is that it lets you make a list of what features not to do. When you create any kind of software, the reality is that you will come up with three times as many features as you have time to do. And one of the best ways to decide which features get done, and which features get left out, is to evaluate which features support the most important user activities.

Imaginary Users.

The very best UI designers in the industry all agree on one thing: you have to invent and describe some imaginary users before you can design your UI. You may remember back in the introduction to this book, I introduced an imaginary user Pete:

Pete is an accountant for a technical publisher who has used Windows for six years at the office and a bit at home. He is fairly competent and technical. He installs his own software; he reads PC Magazine, and he has even programmed some simple Word macros to help the secretaries in his office send invoices. He’s getting a cable modem at home. Pete has never used a Macintosh. “They’re too expensive,” he’ll tell you. “You can get a 700 Mhz PC with 128 Meg RAM for the price of…” OK, Pete. We get it.

When you read this, you can almost imagine a user. I could also have invented quite another type of user:

Patricia is an English professor who has written several well-received books of poetry. She has been using computers for word processing since 1980, although the only two programs she ever used are Nota Bene (an ancient academic word processor) and Microsoft Word. She doesn’t want to spend time learning the theory of how the computer works, and she tends to store all her documents in whatever directory they would go in if you didn’t know about directories.

Obviously, designing software for Pete is quite different from designing software for Patricia, who in turn is quite different from Mike, a 16 year old who runs Linux at home, talks on IRC for hours, and uses no “Micro$oft” software.

When you invent these users, thinking about whether your design is appropriate becomes much easier. For example, a lot of programmers tend to overestimate the ability of the typical user to figure things out. Whenever I write something about command line interfaces being hard to use, I get the inevitable email barrage saying that command line interfaces are ultra-powerful because you can do things like ‘gunzip foo.tar.gz | tar xvf -‘. But as soon as you have to think about getting Patricia to type “gunzip…” it becomes obvious that that kind of interface just isn’t going to serve her needs, ever. Thinking about a “real” person gives you the empathy you need to make a feature that serves that person’s need. (Of course, if you’re making Linux backup software for advanced sysadmins, you need to invent a character like “Frank” who refuses to touch Windows, which he only refers to as an “operating system” in quotation marks, uses his own personally modified version of tcsh, and runs X11 with four tiled xterms all day long. And about 11 xperfs.)

To summarize, designing good software takes about six steps:

  1. Invent some users

  2. Figure out the important activities

  3. Figure out the user model — how the user will expect to accomplish those activities

  4. Sketch out the first draft of the design

  5. Iterate over your design again and again, making it easier and easier until it’s well within the capabilities of your imaginary users

  6. Watch real humans trying to use your software. Note the areas where people have trouble, which probably demonstrate areas where the program model isn’t matching the user model.

Good UI sells software, but it also makes people happy, because people are happy when they accomplish the task they wanted to accomplish. Which is why UI design is such a satisfying field to be in. Where else are you going to get a chance to make millions of people just a little bit happier?

by Joel Spolsky

2000/05/09

We’ve talked about the principles of good design, but principles only give you a way to evaluate and improve an existing design. But… how do you figure out what the dang design should be in the first place? Many people write big, functional outlines of all the features they thought up. Then they design each one, and hang it off of a menu item (or web page). When they’re done, the program (or web site) has all the functionality they wanted, but it doesn’t flow right. People sit down and they don’t know what it does, and they don’t know how to accomplish what they want.

Microsoft’s solution to this is something called Activity Based Planning. (As far as I can tell, this concept was invented by Mike Conte on the Excel team, who got bored with that and went on to a second career as a race car driver). The key insight is to figure out the activity that the user is doing, and focus on making it easy to accomplish that activity.

Read all about it in Chapter 9, the final installment of my book on UI design.

by Joel Spolsky

2000/05/08

Human aptitude tends towards the bell curve. Maybe 98% of your friends are smart enough to use a television set. About 70% of them can use Windows. 15% can use Linux. 1% can program. But only 0.1% of them can program in a language like C++. And only 0.01% of them can figure out Microsoft ATL programming.

The effect of this sharp drop-off is that whenever you “lower the bar” by even a small amount, making your program, say, 10% easier to use, you dramatically increase the number of people who can use it, say, by 50%.

Chapter 8 of my UI design series is now online!

News of the vile: Cubicles are getting smaller. The good news? If you’re willing to spend more to provide humane office space, you should have no problem recruiting people.

A response to a reader’s question on using Excel for schedules: Juggling Tasks in Excel.