<![CDATA[ For years, people have talked about the idea of a device (or mobile application) that could be useful for meeting available members of the appropriate sex. You could program in your likes and dislikes, and if you happen to be walking near a „match,“ it would alert both of you. It appears that some are looking to take that concept and use it in a very different way: to help worried parents know if convicted sex offenders are nearby – and the idea is so intriguing that an Ohio state senator is considering regulating that certain sex offenders need to use the device. Basically, some convicted sex offenders would be required to wear a special bracelet. Then, anyone who was concerned could carry around a special device that would vibrate if one of those bracelets came within a certain distance. Of course, there wouldn't be any indication of who the person was or even where he was – just that he was nearby. For obvious reasons, this has some folks questioning whether this violates various civil liberties. It also is hard to see how it does much good, especially since you still would have no idea who was wearing the bracelet. If anything, it would just make already worried parents more paranoid.

Permalink | Comments | Email This Story ]]>

<![CDATA[ What do you do when the court orders you to do the impossible? The French High Court has apparently told Google that if someone alerts it to an unauthorized video being uploaded to Google video, not only does it need to take the video down, but it must prevent that same video from ever being uploaded again ever. It seems that some people still believe that this really is possible, but despite some companies claiming they offer filters that will block certain uploads, none have been shown to be all that effective. There's always some way to mask or change the content enough that these filters won't work. The question that comes up again, though, is why is this Google's respon­sibility? If there's liability, it should be on the person uploading the unauthorized content. If someone is clever enough to get around any filter, then why should Google have to pay for that?

Permalink | Comments | Email This Story ]]>

<![CDATA[ James Grimmelman has an in depth look a ACAP, the new „standard“ for website access control that we discussed last Friday. I put „standard“ in scare quotes because, as Grimmelman points out, the specs clearly weren't written by people with any experience in writing technical standards. While a well-written standard will very precisely specify which behaviors are required, which are prohibited, and under what circumstances, the ACAP spec is full of vague directives and confusing terminology. Some parts of the standard are apparently designed to „only be interpreted by prior arrangement.“ Also, despite the „1.0“ branding, the latest version of the specification has several sections that are labeled „not yet fully ready for implementation.“ It is, in short, a big mess.

Of course, this shouldn't surprise us, because it's not really a technical standard at all. Robots.txt works just fine for almost everyone, and search engines aren't clamoring to replace it. Rather, some publishers are using the trappings of a technical standard to try to micromanage the uses to which search engines put their content, and they're laying the groundwork for lawsuits if search engines fail to heed the demands embedded in ACAP files. Not only are the rules vague and confused, but the „standard“ also helpfully notes that the rules „may change or be withdrawn without notice.“ In other words, a search engine that committed to complying with ACAP directives would be setting itself up to have their search engine's functi­onality micro-managed by the publishers who control the ACAP specifications.

Luckily, as Mike pointed out on Friday, search engines have the upper hand here. So here's my suggestion for search engines: instead of trying to comply with every nitpicky detail of the ACAP standard, just announce that every line of an ACAP file will be interpreted as the equivalent of a „Disallow“ line in a robots.txt file. Websites would discover pretty quickly that posting ACAP directives on their sites just caused their content to disappear from search engines. As much as they might bluster about other search engines „stealing“ their content, the reality is that they can't afford to give up the traffic that search engines send their way. If search engines simply refused to include ACAP-restricted pages in their index, publishers would quickly realize that those old robots.txt files aren't so bad after all.

Tim Lee is an expert at the Techdirt Insight Community. To get insight and analysis from Tim Lee and other experts on challenges your company faces, click here.

Permalink | Comments | Email This Story ]]>

<![CDATA[ When Verizon Wireless announced last month its plans to „open“ its network some people noticed very quickly that what Verizon Wireless was announcing didn't sound any different from what GSM operators, like AT&T and T-Mobile already had. It was just that the GSM operators hadn't come up with the PR gimmick to call it „open.“ Since they already had it though, it didn't take a genius to figure out that it wouldn't be long before they declared their networks open as well. And, that appears to be exactly what AT&T is doing – but somehow, it appears that AT&T's marketers have convinced a USA Today reporter that it's somehow changed its policies and is „flinging“ its network „wide open.“ The article starts off breathlessly announcing that „starting immediately“ people can use any device on AT&T's network. Of course, the reason it's „starting immediately“ is because, um, you've been able to do that ever since they launched their GSM network years ago. Basically, absolutely nothing happened here except that AT&T's marketing crew declared that AT&T's network is now open, and convinced USA Today to report it as if it were a big deal. If there was any change at all within AT&T, it's that retail store employees are now supposed to admit that you can use other devices on the network, rather than pretending you can't. Not quite as exciting as „flinging the network open,“ though.

Permalink | Comments | Email This Story ]]>

<![CDATA[

When I was a kid working in the bread factory, my nemesis was dough. It was sticky and hard to remove and it got everywhere. I got home with specks of dough in my hair. Every shift included a couple of hours of scraping dough off of machinery. I carried dough-scrapers in my back pocket. Sometimes a huge lump of dough would go flying someplace where it shouldn't and gum up everything. I had dough nightmares.

I worked in the production side of the factory. The other side did packing and shipping. Their nemesis was crumbs. Crumbs got everywhere. The shipping crew went home with crumbs in their hair. Every shift included a couple of hours of brushing crumbs out of machinery. They carried little brushes in their back pockets. I'm sure they had crumb nightmares, too.

Pretty much any job that you can get paid for includes dealing with one gnarly problem. If you don't have dough or crumbs to deal with, maybe you work in a razor blade factory and go home with little cuts all over your fingers. Maybe you work for VMWare and have nightmares about emulating bugs in sophisticated video cards that games rely on. Maybe you work on Windows, and your nightmare is that the simplest change can cause millions of old programs and hardware devices to stop working. That's the gnarly part of your job.

One of our gnarly problems is getting FogBugz to run on our customers' own servers. Jason Fried over at 37signals has a good summary of why this is no fun: „You have to deal with endless operating environment variations that are out of your control. When something goes wrong it’s a lot harder to figure out why if you aren’t in control of the OS or the third party software or hardware that may be interfering with the install, upgrade, or general performance of your product. This is even more complicated with remote server installs when there may be different versions of Ruby, Rails, MYSQL, etc. at play.“ Jason concludes that if they had to sell installable software, they „definitely wouldn't be as happy.“ Yep. Work that makes you unhappy is what I mean by „a gnarly problem.“

The trouble is, the market pays for solutions to gnarly problems, not solutions to easy problems. As the Yorkshire lads say, „Where there's muck, there's brass.“

We offer both kinds of FogBugz–hosted and installable–and our customers opt 4 to 1 to install it at their own site. For us, the installable option gives us five times the sales. It costs us an extra salary or two (in tech support costs). It also means we have to use Wasabi, which has some serious disadvantages compared to off-the-shelf programming languages, but which we found to be the most cost-effective and efficient way, given our code base, to ship software that is installable on Windows, Linux, and Mac. Boy, I would love nothing more than to scrap installable FogBugz and run everything on our servers… we've got racks and racks of nice, well-managed Dell servers with plenty of capacity and our tech support costs for the hosted version are zero. Life would be much easier. But we'd be making so much less money we'd be out of business.

The one thing that so many of today's cute startups have in common is that all they have is a simple little Ruby-on-Rails Ajax site that has no barriers to entry and doesn't solve any gnarly problems. So many of these companies feel insubstantial and fluffy, because, out of necessity (the whole company is three kids and an iguana), they haven't solved anything difficult yet. Until they do, they won't be solving problems for people. People pay for solutions to their problems.

Making an elegantly-designed and easy-to-use application is just as gnarly, even though, like good ballet, it seems easy when done well. Jason and 37signals put effort into good design and get paid for that. Good design seems like the easiest thing to copy, but, watching Microsoft trying to copy the iPod, turns out to be not-so-easy. Great design is a gnarly problem, and can actually provide surprisingly sustainable competitive advantage.

Indeed Jason probably made a good choice by picking the gnarly problem where he has a lot of talent (design) to solve, because it doesn't seem like a chore to him. I've been a Windows programmer for ages, so making a Windows Setup program for FogBugz, from scratch in C++ doing all kinds of gnarly COM stuff, doesn't seem like a chore to me.

The only way to keep growing–as a person and as a company–is to keep expanding the boundaries of what you're good at. At some point, the 37signals team might decide that hiring one person to write the Setup script and do installation support would pay for itself, and generate substantially more profit than it costs. So unless they deliberately want to keep the company small, which is a perfectly legitimate desire, they might eventually lose their reluctance to do things that seem gnarly.

Or maybe they won't. There's nothing wrong with choosing the fun part of your business to work on. I've certainly been guilty of that. And there's nothing wrong with deciding that you only want to solve a specific set of problems for a small, select group of people. Salesforce has managed to become big enough by sticking to hosted software. And there are plenty of smaller software shops providing a fantastic lifestyle for their crew with no desire to get any bigger.

But the great thing is that as you solve each additional gnarly problem, your business and market grows substantially. Good marketing, good design, good sales, good support, and solving lots of problems for customers all amplify each other. You start out with good design, then you add some good features and triple your customer base by solving lots of problems, and then you do some marketing and triple your customer base again because now lots of people learn about your solution to their pain, and then you hire sales people and triple your customer base yet again because now the people who know about your solution are reminded to actually buy it, and then you add more features to solve more problems for even more people, and eventually you actually have a chance to reach enough people with your software to make the world a better place.

P.S. I'm not claiming here that 37signals would sell 5 times as many copies if they offered Installable Basecamp. First of all, one of the reasons we may sell so many more installable versions of FogBugz is that it appears, to some customers, to be cheaper. (It's not cheaper in the long run because you have to pay for the server and administer it yourself, but that's subjective.) Also, our support costs for the installable version are only as low as they are because 80% of our customers opt to run on Windows Server. Because Windows systems are so similar, it's much easier for us to support the lowest common denominator. The vast majority of our tech support costs are caused by the diversity in Unix platforms out there–I'd guess that the 20% of our Unix sales result in 80% of our support incidents. If an installable version of Basecamp required Unix, the support cost would be disproportionately expensive compared to a hypothetical installable Windows version. Finally, another reason our experience might not translate to 37signals is that we've been selling installable software for seven years now; the hosted version has only been out for about six months. So we have a big installed base used to running FogBugz on their own servers. If you only look at new FogBugz customers, the ratio of installable to hosted goes down to 3 to 1.

Not loving your job? Visit the Joel on Software Job Board: Great software jobs, great people.

]]>

<![CDATA[

This is part three of the text of a talk delivered to the Yale Computer Science department on November 28. Part one and part two already appeared.

I despaired of finding a company to work for where programmers were treated like talent and not like typists, and decided I would have to start my own. In those days, I was seeing lots of really dumb people with really dumb business plans making internet companies, and I thought, hey, if I can be, say, 10% less dumb than them, that should be easy, maybe I can make a company too, and in my company, we’d do things right for a change. We’d treat programmers with respect, we’d make high quality products, we wouldn’t take any shit from VCs or 24-year-olds playing President, we’d care about our customers and solve their problems when they called, instead of blaming everything on Microsoft, and we’d let our customers decide whether or not to pay us. At Fog Creek we’ll give anyone their money back with no questions asked under any circumstances whatsoever. Keeps us honest.

So, it was the summer of 2000, and I had taken some time off from work while I hatched the plans for Fog Creek Software and went to the beach a lot. During that period I started writing up some of the things I had learned over the course of my career on a website called Joel on Software. In those early days before blogs were invented, a programmer named Dave Winer had set up a system called EditThisPage.com where anyone could post things to the web in a sort-of blog like format. Joel on Software grew quickly and gave me a pulpit where I could write about software development and actually get some people to pay attention to what I was saying. The site consists of fairly unoriginal thoughts, combined with jokes. It was successful because I used a slightly larger font than the average website, making it easy to read. It’s always hard to figure out how many people read the site, especially when you don’t bother counting them, but typical articles on that site get read by somewhere between 100,000 and a million people, depending on how popular the topic is.

What I do on Joel on Software—writing articles about somewhat technical topics—is something I learned here in the CS department, too. Here’s the story behind that. In 1989 Yale was pretty good at AI, and one of the big name professors, Roger Schank, came and gave a little talk at Hillel about some of his AI theories about scripts and schemas and slots and all that kind of stuff. Now essentially, I suspect from reading his work that it was the same speech he’d been giving for twenty years, and he had spent twenty years of his career writing little programs using these theories, presumably to test them, and they didn’t work, but somehow the theories never got discarded. He did seem like a brilliant man, and I wanted to take a course with him, but he was well known for hating undergraduates, so the only option was to take this course called Algorithmic Thinking—CS115—basically, a watered-down gut group IV class designed for poets. It was technically in the CS department, but the faculty was so completely unimpressed that you were not allowed to count it towards a CS major. Although it was the largest class by enrollment in the CS department, I cringed every time I heard my history-major friends referring to the class as “computer science.” A typical assignment was to write an essay on whether machines can think or not. You can see why we weren’t allowed to count it towards a CS degree. In fact, I would not be entirely surprised if you revoke my degree today, retroactively, upon learning that I took this class.

The best thing about Algorithmic Thinking was that you had to write a lot. There were 13 papers—one every week. You didn’t get grades. Well, you did. Well, ok, there’s a story there. One of the reasons Schank hated undergrads so much was that they were obsessed with grades. He wanted to talk about whether computers could think and all undergrads wanted to talk about was why their paper got a B instead of an A. At the beginning of the term, he made a big speech about how grades are evil, and decided that the only grade you could get on a paper was a little check mark to signify that some grad student read it. Over time, he wanted to recognize the really good papers, so he added check-PLUS, and then there were some really lame papers, so he started giving out check-minuses, and I think I got a check-plus-plus once. But grades: never.

And despite the fact that CS115 didn’t count towards the major, all this experience writing about slightly technical topics turned out to be the most useful thing I got out of the CS department. Being able to write clearly on technical topics is the difference between being a grunt individual contributor programmer and being a leader. My first job at Microsoft was as a program manager on the Excel team, writing the technical specification for this huge programming system called Visual Basic for Applications. This document was something like 500 pages long, and every morning literally hundreds of people came into work and read my spec to figure out what to do next. That included programmers, testers, marketing people, documentation writers, and localizers around the world. I noticed that the really good program managers at Microsoft were the ones who could write really well. Microsoft flipped its corporate strategy 180 degrees based on a single compelling email that Steve Sinofsky wrote called Cornell is Wired. The people who get to decide the terms of the debate are the ones who can write. The C programming language took over because The C Programming Language was such a great book.

So anyway, those were the highlights of CS. CS 115, in which I learned to write, one lecture in Dynamic Logic, in which I learned not to go to graduate school, and CS 322, in which I learned the rites and rituals of the Unix church and had a good time writing a lot of code. The main thing you don’t learn with a CS degree is how to develop software, although you will probably build up certain muscles in your brain that may help you later if you decide that developing software is what you want to do. The other thing you can do, if you want to learn how to develop software, is send your resume to jobs@fogcreek.com, and apply for a summer internship, and we’ll teach you a thing or two about the subject.

Thank you very much for your time.

Not loving your job? Visit the Joel on Software Job Board: Great software jobs, great people.

]]>

<![CDATA[

This is part two of the text of a talk delivered to the Yale Computer Science department on November 28. Part one appeared yesterday.

After a few years in Redmond, Washington, during which I completely failed to adapt to my environment, I beat a hasty retreat to New York City. I stayed on with Microsoft in New York for a few months, where I was a complete and utter failure as a consultant at Microsoft Consulting, and then I spent a few years in the mid-90s, when the Internet was first starting to happen, at Viacom. That’s this big corporate conglomerate which owned MTV, VH1, Nickelodeon, Blockbuster, Paramount Studios, Comedy Central, CBS, and a bunch of other entertainment companies. New York was the first place I got to see what most computer programmers do for a living. It’s this scary thing called “in house software.” It’s terrifying. You never want to do in house software. You’re a programmer for a big corporation that makes, oh, I don’t know, aluminum cans, and there’s nothing quite available off the shelf which does the exact kind of aluminum can processing that they need, so they have these in-house programmers, or they hire companies like Accenture and IBM to send them overpriced programmers, to write this software. And there are two reasons this is so frightening: one, because it’s not a very fulfilling career if you’re a programmer, for a list of reasons which I’ll enumerate in a moment, but two, it’s frightening because this is what probably 80% of programming jobs are like, and if you’re not very, very careful when you graduate, you might find yourself working on in-house software, by accident, and let me tell you, it can drain the life out of you.

OK, so, why does it suck to be an in house programmer.

Number one. You never get to do things the right way. You always have to do things the expedient way. It costs so much money to hire these programmers—typically a company like Accenture or IBM would charge $300 an hour for the services of some recent Yale PoliSci grad who took a 6 week course in dot net programming, and who is earning $47,000 a year and hoping that it’ll provide enough experience to get into business school—anyway, it costs so much to hire these programmers that you’re not going to allowed to build things with Ruby on Rails no matter how cool Ruby is and no matter how spiffy the Ajax is going to be. You’re going into Visual Studio, you’re going to click on the wizard, you’re going to drag the little Grid control onto the page, you’re going to hook it up to the database, and presto, you’re done. It’s good enough. Get out of there and onto the next thing. That’s the second reason these jobs suck: as soon as your program gets good enough, you have to stop working on it. Once the core functionality is there, the main problem is solved, there is absolutely no return-on-investment, no business reason to make the software any better. So all of these in house programs look like a dog’s breakfast: because it’s just not worth a penny to make them look nice. Forget any pride in workmanship or craftsmanship you learned in CS323. You’re going to churn out embarrassing junk, and then, you’re going to rush off to patch up last year’s embarrassing junk which is starting to break down because it wasn’t done right in the first place, twenty-seven years of that and you get a gold watch. Oh, and they don’t give gold watches any more. 27 years and you get carpal tunnel syndrome. Now, at a product company, for example, if you’re a software developer working on a software product or even an online product like Google or Facebook, the better you make the product, the better it sells. The key point about in-house development is that once it’s “good enough,” you stop. When you’re working on products, you can keep refining and polishing and refactoring and improving, and if you work for Facebook, you can spend a whole month optimizing the Ajax name-choosing gizmo so that it’s really fast and really cool, and all that effort is worthwhile because it makes your product better than the competition. So, the number two reason product work is better than in-house work is that you get to make beautiful things.

Number three: when you’re a programmer at a software company, the work you’re doing is directly related to the way the company makes money. That means, for one thing, that management cares about you. It means you get the best benefits and the nicest offices and the best chances for promotion. A programmer is never going to rise to become CEO of Viacom, but you might well rise to become CEO of a tech company.

Anyway. After Microsoft I took a job at Viacom, because I wanted to learn something about the internet and Microsoft was willfully ignoring it in those days. But at Viacom, I was just an in-house programmer, several layers removed from anybody who did anything that made Viacom money in any way.

And I could tell that no matter how critical it was for Viacom to get this internet thing right, when it came time to assign people to desks, the in-house programmers were stuck with 3 people per cubicle in a dark part of the office with no line-of-sight to a window, and the “producers,” I don’t know what they did exactly but they were sort of the equivalent of Turtle on Entourage, the producers had their own big windowed offices overlooking the Hudson River. Once at a Viacom Christmas party I was introduced to the executive in charge of interactive strategy or something. A very lofty position. He said something vague and inept about how interactivity was very important. It was the future. It convinced me that he had no flipping idea whatsoever what it was that was happening and what the internet meant or what I did as a programmer, and he was a little bit scared of it all, but who cares, because he’s making 2 million dollars a year and I’m just a typist or “HTML operator” or whatever it is that I did, how hard can it be, his teenage daughter can do that.

So I moved across the street to Juno Online Services. This was an early internet provider that gave people free dial-up accounts that could only be use for email. It wasn’t like Hotmail or Gmail, which didn’t exist yet, because you didn’t need internet access to begin with, so it was really free.

Juno was, allegedly, supported by advertising. It turned out that advertising to the kinds of people who won’t pay $20 a month for AOL is not exactly the most lucrative business in the world, so in reality, Juno was supported by rich investors. But at least Juno was a product company where programmers were held in high regard, and I felt good about their mission to provide email to everyone. And indeed I worked there happily for about three years as a C++ programmer. Eventually, though, I started to discover that the management philosophy at Juno was old fashioned. The assumption there was that managers exist to tell people what to do. This is quite upside-down from the way management worked in typical west-coast high tech companies. What I was used to from the west coast was an attitude that

<![CDATA[

This is part one of the text of a talk delivered to the Yale Computer Science department on November 28. The rest of the talk will be published tomorrow and Wednesday.

I graduated with a B.S. in Computer Science in 1991. Sixteen years ago. What I’m going to try to do today is relate my undergraduate years in the CS department to my career, which consists of developing software, writing about software, and starting a software company. And of course that’s a little bit absurd; there’s a famous part at the beginning of MIT’s Introduction to Computer Science where Hal Abelson gets up and explains that Computer Science isn’t about computers and it isn’t a science, so it’s a little bit presumptuous of me to imply that CS is supposed to be training for a career in software development, any more than, say, Media Studies or Cultural Anthropology would be.

I’ll press ahead anyway. One of the most useful classes I took was a course that I dropped after the first lecture. Another one was a class given by Roger Schank that was so disdained by the CS faculty that it was not allowed to count towards a degree in computer science. But I’ll get to that in a minute.

The third was this little gut called CS 322, which you know of as CS 323. Back in my day, CS 322 took so much work that it was a 1½ credit class. And Yale’s rule is, that extra half credit could only be combined with other half credits from the same department. Apparently there were two other 1½ credit courses, but they could only be taken together. So through that clever trickery, the half credit was therefore completely useless, but it did justify those weekly problem sets that took 40 hours to complete. After years of students’ complaining, the course was adjusted to be a 1 credit class, it was renumbered CS 323, and still had weekly 40 hour problem sets. Other than that, it’s pretty much the same thing. I loved it, because I love programming. The best thing about CS323 is it teaches a lot of people that they just ain’t never gonna be programmers. This is a good thing. People that don’t have the benefit of Stan teaching them that they can’t be programmers have miserable careers cutting and pasting a lot of Java. By the way, if you took CS 323 and got an A, we have great summer internships at Fog Creek. See me afterwards.

As far as I can tell, the core curriculum hasn’t changed at all. 201, 223, 240, 323, 365, 421, 422, 424, 429 appear to be almost the same courses we took 16 years ago. The number of CS majors is actually up since I went to Yale, although a temporary peak during the dotcom days makes it look like it’s down. And there are a lot more interesting electives now than there were in my time. So: progress.

For a moment there, I actually thought I’d get a PhD. Both my parents are professors. So many of their friends were academics that I grew up assuming that all adults eventually got PhDs. In any case, I was thinking pretty seriously of going on to graduate school in Computer Science. Until I tried to take a class in Dynamic Logic right here in this very department. It was taught by Lenore Zuck, who is now at UIC.

I didn’t last very long, nor did I understand much of anything that was going on. From what I gather, Dynamic Logic is just like formal logic: Socrates is a man, all men are mortal, therefore Socrates is mortal. The difference is that in Dynamic Logic truth values can change over time. Socrates was a man, now he’s a cat, etc. In theory this should be an interesting way to prove things about computer programs, in which state, i.e., truth values, change over time.

In the first lecture Dr. Zuck presented a few axioms and some transformation rules and set about trying to prove a very simple thing. She had a computer program “f := not f,” f is a Boolean, that simply flipped a bit, and the goal was to prove that if you ran this program an even number of times, f would finish with the same value as it started out with.

The proof went on and on. It was in this very room, if I remember correctly, it looks like the carpet hasn’t been changed since then, and all of these blackboards were completely covered in the steps of the proof. Dr. Zuck used proof by induction, proof by reductio ad absurdum, proof by exhaustion—the class was late in the day and we were already running forty minutes over—and, in desperation, proof by graduate student, whereby, she says, “I can’t really remember how to prove this step,” and a graduate student in the front row says, “yes, yes, professor, that’s right.”

And when all was said and done, she got to the end of the proof, and somehow was getting exactly the opposite result of the one that made sense, until that same graduate student pointed out where, 63 steps earlier, some bit had been accidentally flipped due to a little bit of dirt on the board, and all was well.

For our homework, she told us to prove the converse: that if you run the program “f := not f” n times, and the bit is in the same state as it started, that n must be even.

I worked on that problem for hours and hours. I had her original proof in front of me, going in one direction, which, upon closer examination, turned out to have all kinds of missing steps that were “trivial,” but not to me. I read every word about Dynamic Logic that I could find in Becton, and I struggled with the problem late into the night. I was getting absolutely nowhere, and increasingly despairing of theoretical computer science. It occurred to me that when you have a proof that goes on for pages and pages, it’s far more likely to contain errors in the proof as our own intuition about the trivial statements that it’s trying to prove, and I decided that this Dynamic Logic stuff was really not a fruitful way of proving things about actual, interesting computer programs, because you’re more likely to make a mistake in the proof than you are to make a mistake in your own intuition about what the program “f := not f” is going to do. So I dropped the course, thank God for shopping period, but not only that, I decided on the spot that graduate school in Computer Science was just not for me, which made this the single most useful course I ever took.

Now this brings me to one of the important themes that I’ve learned in my career. Time and time again, you’ll see programmers redefining problems so that they can be solved algorithmically. By redefining the problem, it often happens that they’re left with something that can be solved, but which is

<![CDATA[

This is cool… my friend Mike Mathieu set up a web page where you can enter an address and find out how walkable it is.

Microsoft's cam­pus

<![CDATA[

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

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

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

(I didn’t really say that.)

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

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

WTF just happened.

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

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

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

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

Picking cities

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

Booking the room

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

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

Setting the stage

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

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

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

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

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

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

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

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

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

Blow them away

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

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

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

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

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

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

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

Follow up

Ever wonder what the difference is between sales and marketing?

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

Giving demos is marketing, not sales.

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

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

Not loving your job? Visit the Joel on Software Job Board: Great software jobs, great people.

]]>