In Defense of Not-Invented-Here Syndrome

Time for a pop quiz.

Copley Square 1. Code Reuse is:

a) Good
b) Bad

2. Reinventing the Wheel is:

a) Good
b) Bad

3. The Not-Invented-Here Syndrome is:

a) Good
b) Bad

Of course, everybody knows that you should always leverage other people’s work. The correct answers are, of course, 1(a) 2(b) 3(b).


Not so fast, there!

The Not-Invented-Here Syndrome is considered a classic management pathology, in which a team refuses to use a technology that they didn’t create themselves. People with NIH syndrome are obviously just being petty, refusing to do what’s in the best interest of the overall organization because they can’t find a way to take credit. (Right?) The Boring Business History Section at your local megabookstore is rife with stories about stupid teams that spend millions of dollars and twelve years building something they could have bought at Egghead for $9.99. And everybody who has paid any attention whatsoever to three decades of progress in computer programming knows that Reuse is the Holy Grail of all modern programming systems.

Right. Well, that’s what I thought, too. So when I was the program manager in charge of the first implementation of Visual Basic for Applications, I put together a careful coalition of four, count them, four different teams at Microsoft to get custom dialog boxes in Excel VBA. The idea was complicated and fraught with interdependencies. There was a team called AFX that was working on some kind of dialog editor. Then we would use this brand new code from the OLE group which let you embed one app inside another. And the Visual Basic team would provide the programming language behind it. After a week of negotiation I got the AFX, OLE, and VB teams to agree to this in principle.

I stopped by Andrew Kwatinetz’s office. He was my manager at the time and taught me everything I know. “The Excel development team will never accept it,” he said. “You know their motto? ‘Find the dependencies — and eliminate them.’ They’ll never go for something with so many dependencies.”

In-ter-est-ing. I hadn’t known that. I guess that explained why Excel had its own C compiler.

By now I’m sure many of my readers are rolling on the floor laughing. “Isn’t Microsoft stupid,” you’re thinking, “they refused to use other people’s code and they even had their own compiler just for one product.”

Not so fast, big boy! The Excel team’s ruggedly independent mentality also meant that they always shipped on time, their code was of uniformly high quality, and they had a compiler which, back in the 1980s, generated pcode and could therefore run unmodified on Macintosh’s 68000 chip as well as Intel PCs. The pcode also made the executable file about half the size that Intel binaries would have been, which loaded faster from floppy disks and required less RAM.

“Find the dependencies — and eliminate them.” When you’re working on a really, really good team with great programmers, everybody else’s code, frankly, is bug-infested garbage, and nobody else knows how to ship on time. When you’re a cordon bleu chef and you need fresh lavender, you grow it yourself instead of buying it in the farmers’ market, because sometimes they don’t have fresh lavender or they have old lavender which they pass off as fresh.

Indeed during the recent dotcom mania a bunch of quack business writers suggested that the company of the future would be totally virtual — just a trendy couple sipping Chardonnay in their living room outsourcing everything. What these hyperventilating “visionaries” overlooked is that the market pays for value added. Two yuppies in a living room buying an e-commerce engine from company A and selling merchandise made by company B and warehoused and shipped by company C, with customer service from company D, isn’t honestly adding much value. In fact, if you’ve ever had to outsource a critical business function, you realize that outsourcing is hell. Without direct control over customer service, you’re going to get nightmarishly bad customer service — the kind people write about in their weblogs when they tried to get someone, anyone, from some phone company to do even the most basic thing. If you outsource fulfillment, and your fulfillment partner has a different idea about what constitutes prompt delivery, your customers are not going to be happy, and there’s nothing you can do about it, because it took 3 months to find a fulfillment partner in the first place, and in fact, you won’t even know that your customers are unhappy, because they can’t talk to you, because you’ve set up an outsourced customer service center with the explicit aim of not listening to your own customers. That e-commerce engine you bought? There’s no way it’s going to be as flexible as what Amazon does with obidos, which they wrote themselves. (And if it is, then Amazon has no advantage over their competitors who bought the same thing). And no off-the-shelf web server is going to be as blazingly fast as what Google does with their hand-coded, hand-optimized server.

This principle, unfortunately, seems to be directly in conflict with the ideal of “code reuse good — reinventing wheel bad.”

The best advice I can offer:

If it’s a core business function — do it yourself, no matter what.

Pick your core business competencies and goals, and do those in house. If you’re a software company, writing excellent code is how you’re going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you’re a pharmaceutical company, write software for drug research, but don’t write your own accounting package. If you’re a web accounting service, write your own accounting package, but don’t try to create your own magazine ads. If you have customers, never outsource customer service.

If you’re developing a computer game where the plot is your competitive advantage, it’s OK to use a third party 3D library. But if cool 3D effects are going to be your distinguishing feature, you had better roll your own.

The only exception to this rule, I suspect, is if your own people are more incompetent than everyone else, so whenever you try to do anything in house, it’s botched up. Yes, there are plenty of places like this. If you’re in one of them, I can’t help you.


Good Software Takes Ten Years. Get Used To it.

Have a look at this little chart:

[Source: Iris Associates]

This is a chart showing the number of installed seats of the Lotus Notes workgroup software, from the time it was introduced in 1989 through 2000. In fact when Notes 1.0 finally shipped it had been under development for five years. Notice just how dang long it took before Notes was really good enough that people started buying it. Indeed, from the first line of code written in 1984 until the hockey-stick part of the curve where things really started to turn up, about 11 years passed. During this time Ray Ozzie and his crew weren’t drinking piña coladas in St Barts. They were writing code.

The reason I’m telling you this story is that it’s not unusual for a serious software application. The Oracle RDBMS has been around for 22 years now. Windows NT development started 12 years ago. Microsoft Word is positively long in the tooth; I remember seeing Word 1.0 for DOS in high school (that dates me, doesn’t it? It was 1983.)

To experienced software people, none of this is very surprising. You write the first version of your product, a few people use it, they might like it, but there are too many obvious missing features, performance problems, whatever, so a year later, you’ve got version 2.0. Everybody argues about which features are going to go into 2.0, 3.0, 4.0, because there are so many important things to do. I remember from the Excel days how many things we had that we just had to do. Pivot Tables. 3-D spreadsheets. VBA. Data access. When you finally shipped a new version to the waiting public, people fell all over themselves to buy it. Remember Windows 3.1? And it positively, absolutely needed long file names, it needed memory protection, it needed plug and play, it needed a zillion important things that we can’t imagine living without, but there was no time, so those features had to wait for Windows 95.

But that’s just the first ten years. After that, nobody can think of a single feature that they really need. Is there anything you need that Excel 2000 or Windows 2000 doesn’t already do? With all due respect to my friends on the Office team, I can’t help but feel that there hasn’t been a useful new feature in Office since about 1995. Many of the so-called “features” added since then, like the reviled ex-paperclip and auto-document-mangling, are just annoyances and O’Reilly is doing a nice business selling books telling you how to turn them off.

So, it takes a long time to write a good program, but when it’s done, it’s done. Oh sure, you can crank out a new version every year or two, trying to get the upgrade revenues, but eventually people will ask: “why fix what ain’t broken?”


Failure to understand the ten-year rule leads to crucial business mistakes.

Mistake number 1. The Get Big Fast syndrome. This fallacy of the Internet bubble has already been thoroughly discredited elsewhere, so I won’t flog it too much. But an important observation is that the bubble companies that were trying to create software (as opposed to pet food shops) just didn’t have enough time for their software to get good. My favorite example is, which had the beginnings of something that would have been great if they had worked on it for 10 years. But the build-to-flip mentality, the huge overstaffing and overspending of the company, and the need to raise VC every ten minutes made it impossible to develop the software over 10 years. And the 1.0 version, like everything, was really morbidly awful, and nobody could imagine using it. But 8.0 might have been seriously cool. We’ll never know.

Mistake number 2. the Overhype syndrome. When you release 1.0, you might want to actually keep it kind of quiet. Let the early adopters find it. If you market it and promote it too heavily, when people see what you’ve actually done, they will be underwhelmed. is an example of this, so is Marimba, and Groove: they had so much hype on day one that people stopped in and actually looked at their 1.0 release, trying to see what all the excitement was about, but like most 1.0 products, it was about as exciting as watching grass dry. So now there are a million people running around who haven’t looked at Marimba since 1996, and who think it’s still a dorky list box that downloads Java applets that was thrown together in about 4 months.

Keeping 1.0 quiet means you have to be able to break even with fewer sales. And that means you need lower costs, which means fewer employees, which, in the early days of software development, is actually a really great idea, because if you can only afford 1 programmer at the beginning, the architecture is likely to be reasonably consistent and intelligent, instead of a big mishmash with dozens of conflicting ideas from hundreds of programmers that needs to be rewritten from scratch (like Netscape, according to the defenders of the decision to throw away all the source code and start over).

Mistake number 3. Believing in Internet Time. Around 1996, the New York Times first noticed that new Netscape web browser releases were coming out every six months or so, much faster than the usual 2 year upgrade cycle people were used to from companies like Microsoft. This led to the myth that there was something called “Internet time” in which “business moved faster.” Which would be nice, but it wasn’t true. Software was not getting created any faster, it was just getting released more often. And in the early stages of a new software product, there are so many important things to add that you can do releases every six months and still add a bunch of great features that people Gotta Have. So you do it. But you’re not writing software any faster than you did before. (I will give the Internet Explorer team credit. With IE versions 3.0 and 4.0 they probably created software about ten times faster than the industry norm. This had nothing to do with the Internet and everything to do with the fact that they had a fantastic, war-hardened team that benefited from 15 years of collective experience creating commercial software at Microsoft.)

Mistake number 4. Running out of upgrade revenues when your software is done. A bit of industry lore: in the early days (late 1980s), the PC industry was growing so fast that almost all software was sold to first time users. Microsoft generally charged about $30 for an upgrade to their $500 software packages until somebody noticed that the growth from new users was running out, and too many copies were being bought as upgrades to justify the low price. Which got us to where we are today, with upgrades generally costing 50%-60% of the price of the full version and making up the majority of the sales. Now the trouble comes when you can’t think of any new features, so you put in the paperclip, and then you take out the paperclip, and you try to charge people both times, and they aren’t falling for it. That’s when you start to wish that you had charged people for one year licenses, so you can make your product a subscription and have permission to keep taking their money even when you haven’t added any new features. It’s a neat accounting trick: if you sell a software package for $100, Wall Street will value that at $100. But if you can sell a one year license for $30, then you can claim that you’re going to get recurring revenue of $30 for the next, say, 10 years, which is worth $200 to Wall Street. Tada! Stock price doubles! (Incidentally, that’s how SAS charges for their software. They get something like 97% renewals every year.)

The trouble is that with packaged software like Microsoft’s, customers won’t fall for it. Microsoft has been trying to get their customers to accept subscription-based software since the early 90’s, and they get massive pushback from their customers every single time. Once people got used to the idea that you “own” the software that you bought, and you don’t have to upgrade if you don’t want the new features, that can be a big problem for the software company which is trying to sell a product that is already feature complete.

Mistake number 5. The “We’ll Ship It When It’s Ready” syndrome. Which reminds me. What the hell is going on with Mozilla? I made fun of them more than a year ago because three years had passed and the damn thing was still not out the door. There’s a frequently-obsolete chart on their web site which purports to show that they now think they will ship in Q4 2001. Since they don’t actually have anything like a schedule based on estimates, I’m not sure why they think this. Ah, such is the state of software development in Internet Time Land.

But I’m getting off topic. Yes, software takes 10 years to write, and no, there is no possible way a business can survive if you don’t ship anything for 10 years. By the time you discount that revenue stream from 10 years in the future to today, you get bupkis, especially since business analysts like to pretend that everything past 5 years is just “residual value” when they make their fabricated, fictitious spreadsheets that convince them that investing in sock puppets at a $100,000,000 valuation is a pretty good idea.

Anyway, getting good software over the course of 10 years assumes that for at least 8 of those years, you’re getting good feedback from your customers, and good innovations from your competitors that you can copy, and good ideas from all the people that come to work for you because they believe that your version 1.0 is promising. You have to release early, incomplete versions — but don’t overhype them or advertise them on the Super Bowl, because they’re just not that good, no matter how smart you are.

Mistake number 6. Too-frequent upgrades (a.k.a. the Corel Syndrome). At the beginning, when you’re adding new features and you don’t have a lot of existing customers, you’ll be able to release a new version every 6 months or so, and people will love you for the new features. After four or five releases like that, you have to slow down, or your existing customers will stop upgrading. They’ll skip releases because they don’t want the pain or expense of upgrading. Once they skip a release, they’ll start to convince themselves that, hey, they don’t always need the latest and greatest. I used Corel PhotoPaint 6.0 for 5 years. Yes, I know, it had all kinds of off-by-one bugs, but I knew all the off-by-one bugs and compensated by always dragging the selection one pixel to the right of where I thought it should be.


Make a ten year plan. Make sure you can survive for 10 years, because the software products that bring in a billion dollars a year all took that long. Don’t get too hung up on your version 1 and don’t think, for a minute, that you have any hope of reaching large markets with your first version. Good software, like wine, takes time.

Strategy Letter IV: Bloatware and the 80/20 Myth

Version 5.0 of Microsoft’s flagship spreadsheet program Excel came out in 1993. It was positively huge: it required a whole 15 megabytes of hard drive space. In those days we could still remember our first 20MB PC hard drives (around 1985) and so 15MB sure seemed like a lot.

By the time Excel 2000 came out, it required a whopping 146MB … almost a tenfold increase! Dang those sloppy Microsoft programmers, right?


I’ll bet you think I’m going to write one of those boring articles you see all over the net  bemoaning “bloatware”.  Whine whine whine, this stuff is so bloated, oh woe is me, edlin and vi are so much better than Word and Emacs because they are svelte, etc.

Ha ha! I tricked you! I’m not going to write that article again, because it’s not true.

In 1993, given the cost of hard drives in those days, Microsoft Excel 5.0 took up about $36 worth of hard drive space.

In 2000, given the cost of hard drives in 2000, Microsoft Excel 2000 takes up about $1.03 in hard drive space.

(These figures are adjusted for inflation and based on hard drive price data from here.)

In real terms, it’s almost like Excel is actually getting smaller!

What is bloatware, exactly? The Jargon File snidely defines it as “software that provides minimal functionality while requiring a disproportionate amount of diskspace and memory. Especially used for application and OS upgrades. This term is very common in the Windows/NT world. So is its cause.”

I guess those guys just hate Windows. I haven’t run out of memory in more than a decade, ever since virtual memory appeared in Windows 386 (1989). And hard drive space is down to $0.0071 per megabyte and still plummeting like a sheep learning to fly by jumping out of a tree.

Maybe Linus Åkerlund can explain it. On his web page, he writes, “The big disadvantage of using these bloated programs is that you have to load this very large program, even if you just want to accomplish one tiny little thing. It eats up all your memory… you’re not using your system in an efficient way. You make the system seem more inefficient than it really is, and this is totally unnecessary.”

Ohhh. It eats up all your memory. I see. Actually, well, no, it doesn’t. Ever since Windows 1.0, in 1987, the operating system only loads pages as they are used. If you have a 15MB executable and you only use code that spans 2MB worth of pages, you will only ever load 2MB from disk to RAM. In fact if you have a modern version of Windows, the OS will automatically rearrange those pages on the hard drive so that they’re consecutive, which makes the program start even faster next time.

And I don’t think anyone will deny that on today’s overpowered, under-priced computers, loading a huge program is still faster than loading a small program was even 5 years ago. So what’s the problem?

RA Downes gives us a clue. It looks like he spent hours dissecting a small Microsoft utility, apparently enraged that it was a whole megabyte in size. (That’s 3.15 cents of hard drive space at the time he wrote the article). In his opinion, the program should have been around 95% smaller. The joke is that the utility he dissected is something called RegClean, which you’ve probably never heard of. This is a program that goes through your Windows registry looking for things that aren’t being used and deleting them. You have to be a little bit on the obsessive-compulsive side to care about cleaning up unused parts of your registry. So I’m starting to suspect that fretting about bloatware is more of a mental health problem than a software problem.

In fact there are lots of great reasons for bloatware. For one, if programmers don’t have to worry about how large their code is, they can ship it sooner. And that means you get more features, and features make your life better (when you use them) and don’t usually hurt (when you don’t). If your software vendor stops, before shipping, and spends two months squeezing the code down to make it 50% smaller, the net benefit to you is going to be imperceptible. Maybe, just maybe, if you tend to keep your hard drive full, that’s one more Duran Duran MP3 you can download. But the loss to you of waiting an extra two months for the new version is perceptible, and the loss to the software company that has to give up two months of sales is even worse.

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. If I had a dollar for every time this has happened I would be very happy.

When you start marketing your “lite” product, and you tell people, “hey, it’s lite, only 1MB,” they tend to be very happy, then they ask you if it has their crucial feature, and it doesn’t, so they don’t buy your product.

Bottom line: if your strategy is “80/20”, you’re going to have trouble selling software. That’s just reality. This strategy is as old as the software industry itself and it just doesn’t pay; what’s surprising is how many executives at fast companies think that it’s going to work.

Jamie Zawinski says it best, discussing the original version of Netscape that changed the world. “Convenient though it would be if it were true, Mozilla [Netscape 1.0] is not big because it’s full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. But being a shining jewel of perfection was not a goal when we wrote Mozilla.”

Big Macs vs. The Naked Chef

Mystery: why is it that some of the biggest IT consulting companies in the world do the worst work?

Why is it that the cool upstart consulting companies start out with a string of spectacular successes, meteoric growth, and rapidly degenerate into mediocrity?

I’ve been thinking about this, and thinking about how Fog Creek Software (my own company) should grow. And the best lessons I can find come from McDonald’s. Yes, I mean the awful hamburger chain.

The secret of Big Macs is that they’re not very good, but every one is not very good in exactly the same way. If you’re willing to live with not-very-goodness, you can have a Big Mac with absolutely no chance of being surprised in the slightest.

The other secret of Big Macs is that you can have an IQ that hovers somewhere between “idiot” and “moron” (to use the technical terms) and you’ll still be able to produce Big Macs that are exactly as unsurprising as all the other Big Macs in the world. That’s because McDonald’s real secret sauce is its huge operations manual, describing in stunning detail the exact procedure that every franchisee must follow in creating a Big Mac. If a Big Mac hamburger is fried for 37 seconds in Anchorage, Alaska, it will be fried for 37 seconds in Singapore – not 36, not 38. To make a Big Mac you just follow the damn rules.

The rules have been carefully designed by reasonably intelligent people (back at McDonald’s Hamburger University) so that dumdums can follow them just as well as smart people. In fact the rules include all kinds of failsafes, like bells that go off if you keep the fries in the oil too long, which were created to compensate for more than a little human frailty. There are stopwatches and timing systems everywhere. There is a system to make sure that the janitor checks if the bathrooms are clean every half hour. (Hint: they’re not.)

The system basically assumes that everybody will make a bunch of mistakes, but the burgers that come out will be, um, consistent, and you’ll always be asked if you want fries with that.

Just for the sake of amusement, let’s compare a McDonald’s cook, who is following a set of rules exactly and doesn’t know anything about food, to a genius like The Naked Chef, the British cutie Jamie Oliver. (If you chose to leave this site now and follow that link to watch the MTV-like videos of The Naked Chef making basil aioli, you have my blessing. Go in good health.) Anyway, comparing McDonald’s to a gourmet chef is completely absurd, but please suspend disbelief for a moment, because there’s something to be learned here.

Now, the Naked Chef doesn’t follow no stinkin’ Operations Manual. He doesn’t measure anything. While he’s cooking, you see a flurry of food tossed around willy-nilly. “We’ll just put a bit of extra rosemary in there, that won’t hurt, and give it a good old shake,” he says. ” Mash it up. Perfect. Just chuck it all over the place.” (Yes, it really looks like he’s just chucking it all over the place. Sorry, but if I tried to chuck it all over the place, it wouldn’t work.) It takes about 14 seconds and he’s basically improvised a complete gourmet meal with roasted slashed fillet of sea-bass stuffed with herbs, baked on mushroom potatoes with a salsa-verde. Yum.

Well, I think it’s pretty obvious that The Naked Chef’s food is better than you get at McDonald’s. Even if it sounds like a stupid question, it’s worth a minute to ask why. It’s not such a stupid question. Why can’t a big company with zillions of resources, incredible scale, access to the best food designers money can buy, and infinite cash flow produce a nice meal?

Imagine that The Naked Chef gets bored doing “telly” and opens a restaurant. Of course, he’s a brilliant chef, the food would be incredible, so the place is hopping with customers and shockingly profitable.

When you have a shockingly profitable restaurant, you quickly realize that even if you fill up every night, and even if you charge $19 for an appetizer and $3.95 for a coke, your profits reach a natural limit, because one chef can only make so much food. So you hire another chef, and maybe open some more branches, maybe in other cities.

Now a problem starts to develop: what we in the technical fields call the scalability problem. When you try to clone a restaurant, you have to decide between hiring another great chef of your caliber (in which case, that chef will probably want and expect to keep most of the extra profits that he created, so why bother), or else you’ll hire a cheaper, younger chef who’s not quite as good, but pretty soon your patrons will figure that out and they won’t go to the clone restaurant.

The common way of dealing with the scalability problem is to hire cheap chefs who don’t know anything, and give them such precise rules about how to create every dish that they “can’t” screw it up. Just follow these here rules, and you’ll make great gourmet food!

Problem: it doesn’t work exactly right. There are a million things that a good chef does that have to do with improvisation. A good chef sees some awesome mangos in the farmer’s market and improvises a mango-cilantro salsa for the fish of the day. A good chef deals with a temporary shortage of potatoes by creating some taro chip thing. An automaton chef who is merely following instructions might be able to produce a given dish when everything is working perfectly, but without real talent and skill, will not be able to improvise, which is why you never see jicama at McDonald’s.

McDonald’s requires a very particular variety of potato, which they grow all over the world, and which they pre-cut and freeze in massive quantities to survive shortages. The precutting and freezing means that the french-fries are not as good as they could be, but they are certainly consistent and require no chef-skills. In fact, McDonald’s does hundreds of things to make sure that their product can be produced with consistent quality, by any moron you can get in the kitchen, even if the quality is “a bit” lower.

Summary, so far:

  1. Some things need talent to do really well.
  2. It’s hard to scale talent.
  3. One way people try to scale talent is by having the talent create rules for the untalented to follow.
  4. The quality of the resulting product is very low.

You can see the exact same story playing out in IT consulting. How many times have you heard this story?

Mike was unhappy. He had hired a huge company of IT consultants to build The System. The IT consultants he hired were incompetents who kept talking about “The Methodology” and who spent millions of dollars and had failed to produce a single thing.

Luckily, Mike found a youthful programmer who was really smart and talented. The youthful programmer built his whole system in one day for $20 and pizza. Mike was overjoyed. He recommended the youthful programmer to all his friends.

Youthful Programmer starts raking in the money. Soon, he has more work than he can handle, so he hires a bunch of people to help him. The good people want too many stock options, so he decides to hire even younger programmers right out of college and “train them” with a 6 week course.

The trouble is that the “training” doesn’t really produce consistent results, so Youthful Programmer starts creating rules and procedures that are meant to make more consistent results. Over the years, the rule book grows and grows. Soon it’s a six-volume manual called The Methodology.

After a few dozen years, Youthful Programmer is now a Huge Incompetent IT Consultant with a capital-M-methodology and a lot of people who blindly obey the Methodology, even when it doesn’t seem to be working, because they have no bloody idea whatsoever what else to do, and they’re not really talented programmers — they’re just well-meaning Poli Sci majors who attended the six-week course.

And Newly Huge Incompetent IT Consultant starts messing up. Their customers are unhappy. And another upstart talented programmer comes and takes away all their business, and the cycle begins anew.

I don’t need to name names, here, this cycle has happened a dozen times. All the IT service companies get greedy and try to grow faster than they can find talented people, and they grow layers upon layers of rules and procedures which help produce “consistent,” if not very brilliant work.

But the rules and procedures only work when nothing goes wrong. Various “data-backed Web site” consulting companies sprouted up in the last couple of years and filled their ranks by teaching rank amateurs the fourteen things you need to know to create a data-backed Web site (“here’s a select statement, kid, build a Web site”). But now that dotcoms are imploding and there’s suddenly demand for high-end GUI programming, C++ skills, and real computer science, the kids who only have select statements in their arsenal just have too steep a learning curve and can’t catch up. But they still keep trying, following the rules in chapter 17 about normalizing databases, which mysteriously don’t apply to The New World. The brilliant founders of these companies could certainly adjust to the new world: they are talented computer scientists who can learn anything, but the company they built can’t adjust because it has substituted a rulebook for talent, and rulebooks don’t adjust to new times.

What’s the moral of the story? Beware of Methodologies. They are a great way to bring everyone up to a dismal, but passable, level of performance, but at the same time, they are aggravating to more talented people who chafe at the restrictions that are placed on them. It’s pretty obvious to me that a talented chef is not going to be happy making burgers at McDonald’s, precisely because of McDonald’s rules. So why do IT consultants brag so much about their methodologies? (Beats me.)

What does this mean for Fog Creek? Well, our goal has never been to become a huge consulting company. We started out doing consulting as a means to an end — the long-term goal was to be a software company that is always profitable, and we achieved that by doing some consulting work to supplement our software income. After a couple of years in business our software revenues grew to the point where consulting was just a low-margin distraction, so now we only do consulting engagements that directly support our software. Software, as you know, scales incredibly well. When one new person buys FogBUGZ, we make more money without spending any more money.

More important is our obsession with hiring the best… we are perfectly happy to stay small if we can’t find enough good people (although with six weeks annual vacation, finding people doesn’t seem to pose a problem). And we refuse to grow until the people we already hired have learned enough to become teachers and mentors of the new crowd.

Wasting Money on Cats

Did you get this little box in the mail this week?

I did. I think it’s because I’m a Wired subscriber. Inside the box was a free “cat”, which is supposed to remind you of a mouse, and Jared says looks like a fox:

The little cat can be used to scan barcodes which appear in magazines like, um, Wired, for example.


And when you scan the cool barcode, presumably, your web browser goes to the Altoids web page.


The number of dumb things going on here exceeds my limited ability to grok all at once. I’m a bit overwhelmed with what a feeble business idea this is.

The cat is called Cue Cat, which I’m supposed to punctuate as so: :CueCat. That’s right, the colon is a part of the name. The software that comes with this cutie says that it’s made by DigitalConvergence.:Com. No, don’t type the colon before the com, that’s merely there to be cute.

The colonated company DigitalConvergence.:Com has, and I kid you not, 200 employees, according to their web page. That means that even on the most moderate estimate, they are burning about a million dollars a month just on salaries. Now, the auditors say that the paid circulation of Wired is around half a million, so mailing this dang thing out is going to cost about a million dollars in postage, if they’re really sending it to everyone. Not to mention the cost of manufacturing the CD with the software; the cable that comes with the thing, and the :Cat itself: this is a company that is burning money at Iridium rates.

What kind of investors are willing to burn money at that rate? Don’t they realize that it’s a dumb idea?

I guess not. But it is. Here’s why.

1. This thing is not solving a problem.

I’ve racked my brain, and I’ve tried to figure out why I would want their cat chasin’ my mouse around the desk. I came up with two “problems” that it solves:

  1. typing URLs is hard. As if. Going to the Altoids web site is not a hard problem that I need solved. We’re talking 7 characters to type, here.
  2. magazines can’t prove to advertisers that people actually look at their ads and go to the URLs mentioned in the ad.

I think that #2 is really where the focus is, because that seems to be where the money is to be made (and that’s who’s going to pay for the cats, which users get for free). But #2 is a falsehood, too. People don’t have cats and they won’t use them. Just to direct mail a bunch of cats, free, to the subscribers of one magazine is going to cost millions, and if it’s like any other direct mail, 99% of them are going straight in the trash. If 1% of Wired’s subscribers install the thing, we’re talking about an installed base of around 5000 cats. So if Wired thinks they are going to impress their advertisers by showing them how 13 people scanned the page and went to the web site, they’re in for a rude awakening.

If you invent something that doesn’t solve a problem, it better be entertaining. Is the :Cat entertaining? Let me entertain you with a quick quote from the instructions that came with this thing:


That’s where I stopped reading. Changing the BIOS settings is not my idea of entertainment. I don’t think I want to install this. There is no possible benefit to the consumer, so no consumer in their right mind will use this.

2. The Cat Suffers from Chicken and Egg Syndrome

No advertiser will bother putting the Cat barcode in their ads unless a lot of people have cats installed on their computers, because, well, it’s just a lot of bother and looks dumb.

Nobody will install a Cat on their computer unless they see Cat barcodes all over the place.

Conclusion: this thing will die an unhappy death of Chicken and Egg Syndrome. You can read all about this syndrome in my earlier article here. This might be a decent business if everybody had cats installed, and it would be a great business if every ad, everywhere, had barcodes, but, uh, they don’t, and they don’t, so it’s not such a great business.

To get around the chicken/egg problem, DigitalConvergence.:Com is spending a fortune giving away the devices. If they send them to all of Wired’s subscribers, well, that’s half a million people. Out of 300 million people on the net, I’m not impressed. And their system lets you scan in UPC symbols, for some bizarre reason, so if you want to go to the Campbell’s Tomato Soup web page, you can do that by scanning the actual can itself. Both of these are half-hearted attempts to solve the mother of all chicken and egg problems.

3. And anyway, what the heck happened to last month’s dumb Wired idea?

About two months ago, Wired magazine had a different technology for going to a URL automatically from an ad. It was some kind of weird thing where you held up the page to your digital camera, took a digital picture, and ran this wacked out software that navigated your browser to the Altoids home page. So now instead of typing 7 letters I have to find my digital camera, turn it on, wait for it to boot up, take a picture of the page, turn off the camera, wait for it to flush its memory to flash, remove the flash card from the camera, take the network card out of the PCMCIA slot, put the compact flash into it’s holder, plug it into the PCMCIA slot, find the picture, run the software which I previously installed, oh, don’t get me started. It would be a half-hour trauma just to go to the damn Altoids web site, where you can’t even buy an Altoids, for heaven’s sake. Curious.

Of course, that idea died so quickly that here it is, two months later, and there’s no sign of it in the pages of this month’s Wired. A mere flash in the primordial soup. I can’t even remember what the damn thing was called. (My readers inform me that it’s called the Digimarc MediaBridge.)

Bottom line: if you’re working for a company that’s spending millions of dollars trying to get people to do something with absolutely no benefit to them, and which suffers from chicken and egg problems, don’t be counting your stock options just yet.

[June 16, 2001: Digital Convergence lays off most employees.]

Strategy Letter III: Let Me Go Back!

When you’re trying to get people to switch from a competitor to your product, you need to understand barriers to entry, and you need to understand them a lot better than you think, or people won’t switch and you’ll be waiting tables.

In an earlier letter, I wrote about the difference between two kinds of companies: the Ben and Jerry’s kind of company which is trying to take over from established competition, versus the kind of company which is trying a “land grab” in a new field where there is no established competition. When I worked on Microsoft Excel in the early 90’s, it was a card-carrying member of the Ben and Jerry’s camp. Lotus 123, the established competitor, had an almost complete monopoly in the market for spreadsheets. Sure, there were new users buying computers who started out with Excel, but for the most part, if Microsoft wanted to sell spreadsheets, they were going to have to get people to switch.

The most important thing to do when you’re in this position is to admit it. Some companies can’t even do this. The management at my last employer, Juno, was unwilling to admit that AOL had already achieved a dominant position. They spoke of the “millions of people not yet online.” They said that “in every market, there is room for two players: Time and Newsweek, Coke and Pepsi, etc.” The only thing they wouldn’t say is “we have to get people to switch away from AOL.” I’m not sure what they were afraid of. Perhaps they thought they were afraid to “wake up the sleeping bear”. When one of Juno’s star programmers (no, not me) had the chutzpah, the unmitigated gall to ask a simple question at a company meeting: “Why aren’t we doing more to get AOL users to switch?” they hauled him off, screamed at him for an hour, and denied him a promotion he had been promised. (Guess who took his talent elsewhere?)

There’s nothing wrong with being in a market that has established competition. In fact, even if your product is radically new, like eBay, you probably have competition: garage sales! Don’t stress too much. If your product is better in some way, you actually have a pretty good chance of getting people to switch. But you have to think strategically about it, and thinking strategically means thinking one step beyond the obvious.

The only strategy in getting people to switch to your product is to eliminate barriers. Imagine that it’s 1991. The dominant spreadsheet, with 100% market share, is Lotus 123. You’re the product manager for Microsoft Excel. Ask yourself: what are the barriers to switching? What keeps users from becoming Excel customers tomorrow?

1. They have to know about Excel and know that it’s better  
2. They have to buy Excel  
3. They have to buy Windows to run Excel  
4. They have to convert their existing spreadsheets from 123 to Excel  
5. They have to rewrite their keyboard macros which won’t run in Excel  
6. They have to learn a new user interface  
7. They need a faster computer with more memory  

And so on, and so on. Think of these barriers as an obstacle course that people have to run before you can count them as your customers. If you start out with a field of 1000 runners, about half of them will trip on the tires; half of the survivors won’t be strong enough to jump the wall; half of those survivors will fall off the rope ladder into the mud, and so on, until only 1 or 2 people actually overcome all the hurdles. With 8 or 9 barriers, everybody will have one non-negotiable deal killer.

This calculus means that eliminating barriers to switching is the most important thing you have to do if you want to take over an existing market, because eliminating just one barrier will likely double your sales. Eliminate two barriers, and you’ll double your sales again. Microsoft looked at the list of barriers and worked on all of them:

Barrier Solution
1. They have to know about Excel and know that it’s better Advertise Excel, send out demo disks, and tour the country showing it off
2. They have to buy Excel Offer a special discount for former 123 users to switch to Excel
3. They have to buy Windows to run Excel Make a runtime version of Windows which ships free with Excel
4. They have to convert their existing spreadsheets from 123 to Excel Give Excel the capability to read 123 spreadsheets
5. They have to rewrite their keyboard macros which won’t run in Excel Give Excel the capability to run 123 macros
6. They have to learn a new user interface Give Excel the ability to understand Lotus keystrokes, in case you were used to the old way of doing things
7. They need a faster computer with more memory Wait for Moore’s law to solve the problem of computer power

And it worked pretty well. By incessant pounding on eliminating barriers, they slowly pried some market share away from Lotus.

One thing you see a lot when there is a transition from an old monopoly to a new monopoly is that there is a magic “tipping point”: one morning, you wake up and your product has 80% market share instead of 20% market share. This flip tends to happen very quickly (VisiCalc to 123 to Excel, WordStar to WordPerfect to Word, Mosaic to Netscape to Internet Explorer, dBase to Access, and so on). It usually happens because the very last barrier to entry has fallen and suddenly it’s logical for everyone to switch.

Obviously, it’s important to work on fixing the obvious barriers to entry, but once you think you’ve addressed those, you need to figure out what the non-so-obvious ones are. And this is where strategy becomes tricky, because there are some non-obvious things that keep people from switching.

Here’s an example. This summer I’m spending most of my time in a house near the beach, but my bills still go to the apartment in New York City. And I travel a lot. There’s a nice web service,, which is supposed to simplify your life: you have all your bills sent to them, and they scan them and put them on the web for you to see wherever you may be.

Now, PayMyBills costs about $9 a month, which sounds reasonable, and I would consider using it, but in the past, I’ve had pretty bad luck with financial services on the Internet, like Datek, which made so many arithmetic mistakes in my statements I couldn’t believe they were licensed. So I’m willing to try PayMyBills, but if I don’t like it, I want to be able to go back to the old way.

The trouble is, after I use PayMyBills, if I don’t like it, I need to call every damn credit card company and change my address again. That’s a lot of work. And so the fear of how hard it will be to switch back is keeping me from using their service. Earlier I called this “stealth lock-in,” and sort of praised it, but if potential customers figure it out, oh boy are you in trouble.

That’s the barrier to entry. Not how hard it is to switch in: it’s how hard it might be to switch out.

And this reminded me of Excel’s tipping point, which happened around the time of Excel 4.0. And the biggest reason was that Excel 4.0 was the first version of Excel that could write Lotus spreadsheets transparently.

Yep, you heard me. Write. Not read. It turns out that what was stopping people from switching to Excel was that everybody else they worked with was still using Lotus 123. They didn’t want a product that would create spreadsheets that nobody else could read: a classic Chicken and Egg problem. When you’re the lone Excel fan in a company where everyone else is using 123, even if you love Excel, you can’t switch until you can participate in the 123 ecology.

To take over a market, you have to address every barrier to entry. If you forget just one barrier which trips up 50% of your potential customers, then by definition, you can’t have more than 50% market share, and you will never displace the dominant player, and you’ll be stuck on the sad (omelet) side of chicken and egg problems.

The trouble is that most managers only think about strategy one step at a time, like chess players who refuse to think one move ahead. Most of them will say, “it’s important to let people convert into your product, but why should I waste my limited engineering budget letting people convert out?

That’s a childish approach to strategy. It reminds me of independent booksellers, who said “why should I make it comfortable for people to read books in my store? I want them to buy the books!” And then one day Barnes and Nobles puts couches and cafes in the stores and practically begged people to read books in their store without buying them. Now you’ve got all these customers sitting in their stores for hours at a time, mittengrabben all the books with their filthy hands, and the probability that they find something they want to buy is linearly proportional to the amount of time they spend in the store, and even the dinkiest Barnes and Nobles superstore in Iowa City rakes in hundreds of dollars a minute while the independent booksellers are going out of business. Honey, Shakespeare and Company on Manhattan’s Upper West Side did not close because Barnes and Nobles had cheaper prices, it closed because Barnes and Nobles had more human beings in the building.

The mature approach to strategy is not to try to force things on potential customers. If somebody isn’t even your customer yet, trying to lock them in just isn’t a good idea. When you have 100% market share, come talk to me about lock-in. Until then, if you try to lock them in now, it’s too early, and if any customer catches you in the act, you’ll just wind up locking them out. Nobody wants to switch to a product that is going to eliminate their freedom in the future.

Let’s take a more current example: ISPs, a highly competitive market. Something that virtually no ISP offers is the ability to get your email forwarded to another email address after you quit their service. This is small-minded thinking of the worst sort, and I’m pretty surprised nobody has figured it out. If you’re a small ISP trying to get people to switch, they are going to be worrying about the biggest barrier: telling all their friends their new email address. So they won’t even want to try your service. If they do try it, they won’t tell their friends the new address for a while, just in case it doesn’t work out. Which means they won’t be getting much email at the new address, which means they won’t really be trying out the service and seeing how much better they like it. Lose-lose.

Now suppose one brave ISP would make the following promise: “Try us. If you don’t like us, we’ll keep your email address functioning, and we’ll forward your email for free to any other ISP. For life. Hop around from ISP to ISP as many times as you want, just let us know, and we’ll be your permanent forwarding service.”

Of course, the business managers would have fits. Why should we make it easy for customers to leave the service? That’s because they are short sighted. These are not your customers now. Try to lock them in before they become your customers, and you’ll just lock them out. But if you make an honest promise that it will be easy to back out of the service if they’re not happy, and suddenly you eliminate one more barrier to entry. And, as we learned, eliminating even a single barrier to entry can have a dramatic effect on conversions, and over time, when you knock down that last barrier to entry, people will start flooding in, and life will be good for a while. Until somebody does the same thing to you.

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.


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. (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, 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 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, 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.

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 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 — 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, 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 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

Top Five (Wrong) Reasons You Don’t Have Testers

In 1992, James Gleick was having a lot of problems with buggy software. A new version of Microsoft Word for Windows had come out, which Gleick, a science writer, considered to be awful. He wrote a lengthy article in the Sunday New York Times Magazine which could only be described as a flame, skewering the Word team for being unresponsive to the requests of customers, and delivering an enormously buggy product.

Later, as a customer of a local Internet provider Panix (which also happens to be my Internet provider), he wanted a way to automatically sort and filter his mail. The UNIX tool for doing this is called procmail, which is really arcane and has the kind of interface that even the most hardcore UNIX groupies will admit is obscure.

Anyway, Mr. Gleick inadvertently made some kind of innocent typo in procmail which deleted all his email. In a rage, he decided that he was going to create his own Internet access company. Hiring Uday Ivatury, a programmer, he created Pipeline, which was really quite a bit ahead of its time: it was the first commercial provider of Internet access with any kind of graphical interface. 

Now, Pipeline had its problems, of course. The very first version didn’t use any kind of error correction protocol, so it had a tendency to garble things up or crash. Like all software, it had bugs. I applied for a job at Pipeline in 1993. During the interview, I asked Mr. Gleick about the article he wrote. “Now that you’re on the other side of the fence,” I asked, “do you have a bit more of an appreciation for the difficultly of creating good software?”

Gleick was unrepentant. He denied that Pipeline had any bugs. He denied that it was anything as bad as Word. He told me: “one day, Joel, you too will come to hate Microsoft.” I was a little bit shocked that his year of experience as a software creator, not merely a software user, hadn’t given him a smidgen of appreciation for how hard it is to really get bug-free, easy to use software. So I fled, turning down the job offer.  (Pipeline was bought out, by PSI, the strangest Internet provider on earth, and then unceremoniously taken out and shot.)

Software has bugs. CPUs are outrageously finicky. They absolutely refuse to deal with things that they weren’t taught to deal with explicitly, and they tend to refuse in the most childish of ways. When my laptop is away from home, it tends to crash a lot because it can’t find the network printer it’s used to finding. What a baby. It probably comes down to a single line of code somewhere with a teensy tiny almost insignificant bug in it.

Which is why you positively, absolutely, need to have a QA department. You are going to need 1 tester for every 2 programmers (more if your software needs to work under a lot of complicated configurations or operating systems). Each programmer should work closely with a single tester, throwing them private builds as often as necessary.  

The QA department should be independent and powerful, it must not report to the development team, in fact, the head of QA should have veto power over releasing any software that doesn’t meet muster.

My first real software job was at Microsoft; a company that is not exactly famous for its high quality code, but which does nonetheless hire a large number of software testers. So I had sort of assumed that every software operation had testers.

Many do. But a surprising number do not have testers. In fact, a lot of software teams don’t even believe in testing.

You would think that after all the Quality mania of the 80s, with all kinds of meaningless international “quality” certifications like ISO-9000 and buzzwords like “six-sigma”, managers today would understand that having high quality products makes good business sense. In fact, they do. Most have managed to get this through their heads. But they still come up with lots of reasons not to have software testers, all of which are wrong.

I hope I can explain to you why these ideas are wrong. If you’re in a hurry, skip the rest of this article, and go out and hire one full-time tester for every two full-time programmers on your team. 

Here are the most common boo-hoo excuses I’ve heard for not hiring testers:

1. Bugs come from lazy programmers.

“If we hire testers”, this fantasy goes, “the programmers will get sloppy and write buggy code. By avoiding testers, we can force the programmers to write correct code in the first place.”

Sheesh. If you think that, you either have never written code, or you are remarkably dishonest about what writing code is like. Bugs, by definition, leak out because programmers did not see the bug in their own code. A lot of times it just takes a second set of eyes to see a bug.

When I was writing code at Juno, I tended to exercise my code the same way every time … I used my own habits, relying on the mouse a lot. Our marvelous, vastly overqualified tester had slightly different habits: she did more things with the keyboard (and actually rigorously tested the interface using every possible combination of inputs). This quickly uncovered a whole slew of bugs. In fact at times she actually told me that the interface flatly didn’t work, 100% did not work, even though it always worked for me. When I watched her repro the bug I had one of those whack-your-forehead moments. Alt! You’re holding down the Alt Key! Why didn’t I test that?

2. My software is on the web. I can fix bugs in a second.

Bwa ha ha ha ha! OK, it’s true, web distribution lets you distribute bug fixes much faster than the old days of packaged software. But don’t underestimate the cost of fixing a bug, even on a web site, after the project has already frozen. For one thing, you may introduce even more bugs when you fix the first one. But a worse problem is that if you look around at the process you have in place for rolling out new versions, you’ll realize that it may be quite an expensive proposition to roll out fixes on the web. Besides the bad impression you will make, which leads to:

3. My customers will test the software for me.

Ah, the dreaded “Netscape Defense”. This poor company did an almost supernatural amount of damage to its reputation through their “testing” methodology:

  1. when the programmers are about halfway done, release the software on the web without any testing.
  2. when the programmers say they are done, release the software on the web without any testing.
  3. repeat six or seven times.
  4. call one of those versions the “final version”
  5. release .01, .02, .03 versions every time an embarrassing bug is mentioned on c|net.

This company pioneered the idea of “wide betas”. Literally millions of people would download these unfinished, buggy releases. In the first few years, almost everybody using Netscape was using some kind of pre-release or beta version. As a result, most people think that Netscape software is really buggy. Even if the final release was usually reasonably unbuggy, Netscape had so doggone many people using buggy versions that the average impression that most people have of the software was pretty poor.

Besides, the whole point of letting “your customers” do the testing is that they find the bugs, and you fix them. Unfortunately, neither Netscape, nor any other company on earth, has the manpower to sift through bug reports from 2,000,000 customers and decide what’s really important. When I reported bugs in Netscape 2.0, the bug reporting website repeatedly crashed and simply did not let me report a bug (which, of course, would have gone into a black hole anyway). But Netscape doesn’t learn. Testers of the current “preview” version, 6.0, have complained in newsgroups that the bug reporting website still just doesn’t allow submissions. Years later! Same problem!

Of those zillions of bug reports, I would bet that almost all of them were about the same set of 5 or 10 really obvious bugs, anyway. Buried in that haystack will be one or two interesting, difficult-to-find bugs that somebody has gone to the trouble of submitting, but nobody is looking at all these reports anyway, so it is lost.

The worst thing about this form of testing is the remarkably bad impression you will make of your company. When Userland released the first Windows version of their flagship Frontier product, I downloaded it and started working through the tutorial. Unfortunately, Frontier crashed several times. I was literally following the instructions exactly as they were printed in the tutorial, and I just could not get more than 2 minutes into the program. I felt like nobody at Userland had even done the minimum amount of testing, making sure that the tutorial works. The low perceived quality of the product turned me off of Frontier for an awfully long time. 

4. Anybody qualified to be a good tester doesn’t want to work as a tester.

This one is painful. It’s very hard to hire good testers. 

With testers, like programmers, the best ones are an order of magnitude better than the average ones. At Juno, we had one tester, Jill McFarlane, who found three times as many bugs as all four other testers, combined. I’m not exaggerating, I actually measured this. She was more than twelve times more productive than the average tester. When she quit, I sent an email to the CEO saying “I’d rather have Jill on Mondays and Tuesdays than the rest of the QA team put together”.

Unfortunately, most people who are that smart will tend to get bored with day-to-day testing, so the best testers tend to last for about 3 or 4 months and then move on.

The only thing to do about this problem is to recognize that it exists, and deal with it. Here are some suggestions:

  • Use testing as a career move up from technical support. Tedious as testing may be, it sure beats dealing with irate users on the phone, and this may be a way to eliminate some of the churn from the technical support side.
  • Allow testers to develop their careers by taking programming classes, and encourage the smarter ones to develop automated test suites using programming tools and scripting languages. This is a heck of a lot more interesting than testing the same dialog again and again and again.
  • Recognize that you will have a lot of turnover among your top testers. Hire aggressively to keep a steady inflow of people. Don’t stop hiring just because you temporarily have a full manifest, ’cause da golden age ain’t gonna last.
  • Look for “nontraditional” workers: smart teenagers, college kids, and retirees, working part time. You could create a stunningly good testing department with two or three top notch full timers and an army of kids from Bronx Science (a top-ranked high school in New York) working summers in exchange for college money.
  • Hire temps. If you hire about 10 temps to come in and bang on your software for a few days, you’ll find a tremendous number of bugs. Two or three of those temps are likely to have good testing skills, in which case it’s worth buying out their contracts to get them full time. Recognize in advance that some of the temps are likely to be worthless as testers; send them home and move on. That’s what temp agencies are for.

Here’s one way not to deal with it:

  • Don’t even think of trying to tell college CS graduates that they can come work for you, but “everyone has to do a stint in QA for a while before moving on to code”. I’ve seen a lot of this. Programmers do not make good testers, and you’ll lose a good programmer, who is a lot harder to replace.

And finally. The number one stupid reason people don’t hire testers:

5. I can’t afford testers!

This is the stupidest, and it’s the easiest to debunk.

No matter how hard it is to find testers, they are still cheaper than programmers. A lot cheaper.  And if you don’t hire testers, you’re going to have programmers doing testing. And if you think it’s bad when you have testers churning out, just wait till you see how expensive it is to replace that star programmer, at $100,000 a year, who got sick of being told to “spend a few weeks on testing before we release” and moved on to a more professional company. You could hire three testers for a year just to cover the recruiter’s fee on the replacement programmer.

Skimping on testers is such an outrageous false economy that I’m simply blown away that more people don’t recognize it.

Where do These People Get Their (Unoriginal) Ideas?

Maybe I should call this article “why I should stop reading Upside Magazine”. I really have been trying to stop, but they send it to me for free, and I really needed bathroom reading material, so I grabbed it and found one of the most wrong-headed articles I’ve seen in a long time. Well, actually, there are wrong-headed articles all over Upside magazine, but this one was particularly irksome.

It’s an article by Stephen James called “Lessons in Survival”. (March 2000 Upside). Every month, I’m told, Mr James will share with us “some of the simple lessons [he’s] learned from [his] own startups”.

It includes lots of extremely useful advise that you would never figure out on your own, like, don’t spend a lot of money on office space and try to find a neighborhood where you don’t have to stand in line at the local restaurants. If you are starting a dot com, Mr James reminds us, “Get out of the house… Working at home sucks.” And he points out that you should never pay more than $1.50 per square foot. Thanks, Mr James! It’s extremely strange to me that you could expect the same price in every market. Maybe he just assumes that everyone in the world starts all companies in Silicon Valley.

“Forget the free coffee and drinks. Sure they’re free at Microsoft… who wants to be like Microsoft?”

Hello? Is this a joke? Did Upside schedule their April issue for May?

I guess Mr James lives in a funny la-la world where there are millions of programmers just dying to work at your startup. When you are the founder of a company, you want to skimp on frills; they seem like a waste of money to you. That’s fine. But don’t think that candidates interviewing at your company will have the same emotional attachment; they won’t. They are looking for a nice place to work. Skimping on free soft drinks, a completely standard benefit at most high tech companies, is a great way to send your employees and potential employees the message that you just don’t care about being an attractive workplace.

Everybody in Silicon Valley seems to be talking about Charlie, the gourmet cook at Google who used to work for Jerry Garcia. I can tell you, the food is spectacular even by Michelin standards, not just corporate cafeteria standards. Because the food in the company cafeteria is so good, people don’t leave work to eat. They eat with their colleagues, which increases learning and communication. They get back to work within half an hour, making them more productive. They feel like Google cares about them, making them more loyal.

Meanwhile, “Build-outs are a bad idea,” Stephen James tells us. “Don’t build out your space with walls or partitions — leave it open… If employees need an office with a door, let them go to law school or Apple.”

Guess what? They will go to Apple! And replacing just one of them will cost on the order of $50,000 in recruiting and training. A friend of mine provides gorgeous private office space for his programmers in the most expensive real estate district in the USA, Manhattan, and it’s probably costing about $6,000 per person per year. Not much in the scheme of things.

What’s worse, Mr James seems to be completely ignorant of the documented productivity gains provided by giving knowledge workers space, quiet, and privacy. The classic software management book Peopleware documents these productivity benefits extensively. (To be fair, Mr James is not alone in his cluelessness. He’s just reflecting the folk wisdom prevalent in the Valley).

Here’s the trouble. We all know that knowledge workers work best by getting into “flow”, also known as being “in the zone”, where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.

The trouble is, getting into “the zone” is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity. Sometimes, if you’re tired or have already done a lot of creative work that day, you just can’t get into the zone and you spend the rest of your work day fiddling around, reading the web, playing Tetris.

The other trouble is that it’s so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers — ESPECIALLY interruptions by coworkers — all knock you out of the zone. If you take a 1 minute interruption by a coworker asking you a question, and this knocks out your concentration enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble. If you’re in a noisy bullpen environment like the type that caffinated dotcoms love to create, with marketing guys screaming on the phone next to programmers, your productivity will plunge as knowledge workers get interrupted time after time and never get into the zone.

With programmers, it’s especially hard. Productivity depends on being able to juggle a lot of little details in short term memory all at once. Any kind of interruption can cause these details to come crashing down. When you resume work, you can’t remember any of the details (like local variable names you were using, or where you were up to in implementing that search algorithm) and you have to keep looking these things up, which slows you down a lot until you get back up to speed.

Here’s the simple algebra. Let’s say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we’re really blowing away 15 minutes of productivity. For this example, lets put two programmers, Jeff and Mutt, in open cubicles next to each other in a standard Dilbert veal-fattening farm. Mutt can’t remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he’s sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).

Now let’s move them into separate offices with walls and doors. Now when Mutt can’t remember the name of that function, he could look it up, which still takes 30 seconds, or he could ask Jeff, which now takes 45 seconds and involves standing up (not an easy task given the average physical fitness of programmers!). So he looks it up. So now Mutt loses 30 seconds of productivity, but we save 15 minutes for Jeff.

Anyway, I fully expect that most of you, reading this, will write to say, “what the heck are you doing reading Upside anyway? You get what you deserve”. How true. Serves me right.