Here are my current thoughts on the gradual migration to .NET development tools at Fog Creek.

The status quo: Most of CityDesk is written in Visual Basic 6.0, with parts written in Visual C++ 6.0. Most of FogBUGZ is written in VBScript for ASP, with parts written in C++. Almost all of our internal tools and our web presense (Fog Shop, Discussions, etc) are written in VBScript for ASP.

Why bother moving to .NET at all? Simply put, it’s because .NET appears so far to be one of the most brilliant and productive development environments ever created. ASP.NET really makes it incredibly easy to create useful web applications; over the last couple of days I’ve been creating some applications we use internally at incredible speed. All the grungy stuff that takes 75% of the time creating web applications with ASP (such as form validation and error reporting) becomes trivial. ASP.NET is as big a jump in productivity over ASP as Java is to C. Wow.

C# has most of the good stuff from Java, with a few small improvements like automatic boxing. Although we have always done what we can to create reasonably object oriented code in ASP and VB6 in the past, switching to C# will be nice.

Finally, the class libraries that ship with .NET are great. The fact that everything, from data access to web development to GUI development, was redesigned means that there is incredible consistency from top to bottom. When you look at the old Win32 API’s, it is simply amazing how many different ways there are to get a string back from a function call, for example. Every two years they changed their mind about what a good way is to do this. .NET has cleaned that all up. I love the fact that you can use an ASP.NET calendar widget, which generates HTML that selects a date on a monthly calendar, and be confident that the “date” class you get back from that thing (System.DateTime, I believe) will be the exact same date class that the SQL Server classes expect. In the past you would not believe how much time we wasted doing things like reformatting dates for SQL statements, or converting COleDateTimes to someOtherKindOfDateTime. And finally — a string data type that works everywhere! Just last week I was writing ATL code and messing around with BSTRs and OLECHARs and char*s and LPSTRs and what a mess that was. Good riddance.

OK, I admit it — .NET violated the Never Rewrite From Scratch rule. Microsoft got away with it because they had two things. First, they had the world’s best language designer, the man who was responsible for 90% of the productivity gains in software development in the last 20 years: Anders Hejlsberg, who gave us Turbo Pascal (thank you!), Delphi (thank you!), WFC (nice try!) and now .NET (smacked the ball outta the park). Second, they put about a zillion engineers on it for about three years, during a period where much of their competition was more-or-less stalled. Remember, just because Microsoft can do something, doesn’t mean you can. Microsoft makes their own gravity. Normal rules don’t apply to them.

A few dozen people will now proceed to compose angry emails praising some other development environment, or asking why we don’t just use Java and get Write Once Run Anywhere (giggle), or Delphi (the talent has left the building. .NET is Delphi 7.0, and 8.0, and 9.0), or Lisp, or whatever. I am getting locked in the Microsoft Trunk! they will say. Regrettably, I don’t have time to get into religious discussions right now and I usually find them quite boring. I don’t care if Japanese is a better language than English. It just doesn’t matter. Let me finish describing our strategy.

First problem: we don’t know enough about .NET to write good code. As usual in any development environment there are many ways to do any given thing, and we haven’t quite learned the first way, let alone the second way. So the quality of .NET code that we can write is not good enough to ship. Until Bill Vaughn’s first ADO book came out, we didn’t even know the optimal ways to do basic SQL queries. So our first priority is education, which we will accomplish by doing all future in-house and web-based development in .NET — basically, all the software that nobody is paying money for. We can migrate parts of the Fog Shop to .NET and certainly use .NET for all kinds of internal stuff. (Today I wrote a FogShop Coupon Generator in ASP.NET. It’s kind of messy but it works!)

Second problem: the obese 20 MB CLR (runtime). It’s bad enough that about 6 MB of the 8 MB CityDesk download comes from runtimes and data access libraries; we just can’t expect every home CityDesk Starter Edition user to download another 20 MB. The hope is that in a year or two or three lots of people will have the CLR from somewhere else (too bad it didn’t make it into Windows XP). We’ll keep an eye on that; it used to change your user agent; I hope it still does, so we can get statistics.

The bottom line is that neither CityDesk nor FogBUGZ can be ported to .NET today. We will port some future version of CityDesk when the CLR has about 75% penetration. The plan is to:

1. port existing code and forms using Microsoft’s conversion tools
2. fix problems by brute force until it’s working again
3. create new forms and classes using C#
4. gradually port old forms and classes to C# whenever they need major work, anyway
5. many old forms and classes will remain in VB.NET forever (using the ugly backwards compatibility string functions, etc.) as long as they work properly.

FogBUGZ also needs to wait for greater CLR penetration on server computers; we need to survey our customers and find out how bad it would be if FogBUGZ required the CLR.

We have another product in the works which we haven’t talked about publically; this one will share a large portion of its code base with FogBUGZ (a subset we are going to name “Dispatcho”) so it will remain VBScript/ASP at heart until we port FogBUGZ.

For FogBUGZ/Dispatcho/SecretNewProduct, the plan is:

1. wait until it’s OK to require CLR,
2. port existing “business logic” classes to C#,
3. keep current web forms in ASP,
4. and create new web forms in ASP.NET.

Discuss

CityDesk is a Windows program that makes it easy to manage a web site which changes often.

With CityDesk, people who don’t know anything about HTML or web servers can easily add, edit, and remove articles from a web site, using a program that is as easy as a word processor. CityDesk will automatically apply standard formatting, according to templates you provide, to those articles. Then it copies them to your web server automatically. Each article can include pictures, sounds, and other media elements.

Here are just a few examples of the kinds of things you can build and maintain with CityDesk:

• A daily newspaper, a monthly newsletter, or a web-based magazine
• A personal journal or weblog
• A company’s list of job openings
• A real-estate agent’s list of currently available properties
• A company worldwide knowledge base

The real power in CityDesk comes from the fact that you only design the formatting of your site once. After that, it’s easy to create new articles which use the same design. Because CityDesk keeps the text of the articles separate from their design, you can change the design in one place, and every article on your site changes accordingly.

Once you set up your site, updating it is just as easy as using a simple Windows-based word processor. The built-in word processor is WYSIWYG (“What You See Is What You Get”) and includes a spell checker, word counter, find and replace, and formatting commands.

CityDesk is built around a powerful, robust database engine. This means that different people can update the site simultaneously without any risk of conflict or corruption. You can even have a whole newsroom banging away at the same time; even a virtual newsroom, with contributors all over the Internet!

When you need to manage a site with several different versions, CityDesk is invaluable. Suppose you want to publish a newsletter every week in two languages. CityDesk provides a nice interface for translators where they can see a list of untranslated articles and translate them on the spot in a split-screen environment. If you try to publish the site before everything has been translated, you’ll see a warning.

Or suppose you produce a newsletter that has different regional editions. Most of the articles are the same, but you don’t want to run your poem “Every Civilized Person Loves the New York Yankees” in the Boston edition. CityDesk keeps track of that and publishes both editions completely automatically.

CityDesk can also keep track of articles that need to be held until a certain date. Just write the article and set the date range, and CityDesk will never publish it before or after those dates. This is a good way to keep fresh content on your web site when you’re on vacation.

Many web sites appear in multiple formats. For example, you might have:

• the normal web version
• a “printer-friendly” web version without ads or navigation elements
• a version for Palm Pilots without pictures
• a large-font version for the web site for people who like larger fonts
• a printed version that you hand out on street corners to passers-by (who use it to line bird-cages, those scurvy knaves)
• and so on and so forth.

Setting up template families for each of these versions is a one-time operation. After that, you only have to type in the article once, and it will automatically be published in each and every format without any additional work. Ta da!

We think you’ll find that CityDesk is an extremely powerful tool, but one that’s quite easy to understand. There’s a tutorial which will take you on a whirlwind tour in about ten minutes. After that, you’ll only need to consult the documentation occasionally.

CityDesk will be in beta from Oct 15 – Nov 30, 2001, after which it will be shipping. Click here if you would like to apply to be a beta tester.

… in which I respond to some interesting email I’ve gotten lately. All the incoming email has been edited for brevity.

Charles Lin writes:

I teach a C++ computer science course here at University of Maryland at College Park….

Presume you are the czar of University of Maryland Computer Science (you’ve just dreamed about this, haven’t you?), and say “things need to be changed — we need to teach computer science the right way”, what would you do? What do you think are the important things students need to learn if they are to become good C++ programmers.

Off of the top of my head, some of these topics are:

1. the relational model and modern DBMSs
2. user interface design and usability
3. techniques for coding on large teams
4. software design and writing functional specifications
5. debugging
6. Windows and COM programming
7. sockets programming and common Internet protocols
8. database-backed web site development
9. writing! Because great programmers are great communicators.

Dan Green writes:

I read sometime back that you were going shared sourced (for want of a better term) with FogBUGZ. I’m going to be wanting to do similar on a product of mine but I’m not sure how best to word the license. Would you mind sharing the FogBugz license, so that I can learn from it?

Sure. It’s here. I suggest you get a lawyer, though, to review your license. (If you have Errors and Omissions insurance, whatever the heck that is, you are probably required to do so).

Paul Wolpe writes:

I graduated from Carnegie Mellon in May and was happily planning on working for Loudcloud in New York City this fall. It seemed like the best of both worlds; I could work for a tech company and I wouldn’t need to live in the suburbs. Well, due to “unfavorable market conditions” I am now without a job and faced with what appears to be two options: go work for Microsoft in Redmond or work for some financial company in New York City. I have to choose between a great job in a not so great location or a great location with a not so great job. I am not asking for a job (but I would gladly accept if you are offering!). I want to find out if there are any interesting tech companies in New York (and even better if they are hiring). So far, I have found a total of maybe 3 companies, and that includes Fog Creek.

Oooo. Uh-oh. I have two pieces of bad news for ya. No, wait, three pieces. Number one: there aren’t that many technology companies where you can do R&D in New York City. Every local programmer I know complains all the time about how hard it is to get interesting software jobs that aren’t at a bank. That’s one of the reasons I created Fog Creek. Which brings us to bad news number two: Fog Creek is not hiring, because we can’t afford to right now, which is caused by the dot-com crash, which is bad news number three: there’s a bit of a recession going on right now, especially in the tech sector… which means that almost nobody is hiring.

But there is good news, which is that every programmer I know has some job. Maybe it’s not their dream job, but it pays the rent.

The good thing about working for Microsoft is that Microsoft is one company that really knows how to make software, and you’ll learn a lot that will help you wherever you go. And the good thing about living in New York City is, well, OK, I don’t have to explain that. I think in your place I would come to the city and spend some time hopping around, waiting for something interesting to show up. (Pay your dues at the banks and media companies like the rest of us!) Oh, and email me your resume anyway, you never know what might come up.

Gabriel Krupa writes:

I have been a fan of yours for a while and would very much like to start my own company, modeled after Fog Creek (on the other side of the country). Given the business climate lately, I’m hesitant to leave “subsistence programming” (and give it a go with my own savings) until I plan, scheme and “strategize” myself into a false sense of security. I understand the importance of leveraging work to generate money, lest I spend the rest of my life running a consulting firm. Unfortunately, it’s not easy to pay someone else’s salary from my margins unless they’re generating part of that revenue for the company– at least with my hourly rate. Thus, I’m still a company of one with less time than I’d like to devote to building the company.

This is where I get to the point. I’ve read your admissions of how much it takes to run Fog Creek on a monthly basis and that you’re making most of that through consulting. I’d like to find out about Fog Creek’s shrink-wrap strategy and results to date. If you’d rather not share this information, I understand.

For instance, I’d like to know:

• how much revenue you generate from FogBugz and expect from CityDesk

  FogBUGZ is not yet at the point where it’s paying anybody’s salary, but it does cover virtually all of our non-salary expenses (rent, T1, etc) and then some. Which is nice. Yesterday we sold $5700 worth in one day. Whoo hoo! Your mileage may vary.

  We expect CityDesk to have a much wider potential audience than FogBUGZ, so we’re hoping that once CityDesk hits its stride we won’t need any consulting revenue to support ourselves.

• what sort of growth you’ve seen and expect(ed) in sales

  It’s probably too early to see a pattern, but there has been slow but steady growth as the word spreads. We are not doing any active marketing on FogBUGZ at this point, mainly because we want to conserve any marketing dollars we have for CityDesk.

  Even without funding, we hope to be able to get to the point where we can demonstrate that (a) we’re profitable and secure and (b) x dollars spent on marketing results in x times y dollars in revenue. At this point, if y > 1, we can make a strong argument to raise money for marketing without giving up very much equity… or we can go slowly and simply reinvest internally.

• how you choose your product lines (e.g., why you chose to make FogBugz and CityDesk instead of other products (user demand and market conditions being roughly equal))

  FogBUGZ was something we had, so it was a no-brainer to ship it: both to get some cash and to get some practice selling software. (And to get the people off our backs who kept asking us if they could buy it.) It has more than paid for its own R&D costs, so now it feels like one of those mystical things you hear about on late-night TV that you set up and get a nice check every month in exchange for doing nothing. (We do still plan several more major releases of FogBUGZ so it’s not exactly nothing but you get the idea).

  CityDesk will fill a very major vacuum in the desktop software marketplace, it’s a great product, and everybody who’s seen it has said “I gotta get me one of those.” So we’re working day and night trying to get the beta out the door.

• if you feel your reputation and product quality are enough to gain market share in non-virgin markets (i.e., defect tracking) or what Fog Creek’s strategy is

  There are about 1000 bug tracking packages on the market (from companies who are probably selling it for the same reason as we are — because they have it.) So we didn’t know if we would sell any copies of FogBUGZ. As it turns out, the FogBUGZ philosophy of painless bug tracking has hit a nerve and the product has exceeded our expectations and then some. People are also happy because we’re a small company that provides fanatical customer service… when you find a bug and call our toll-free number, you’ll speak to a programmer and probably get a bug fix shipped to you that day.

• whether or not you’re presently concentrating on non-consulting revenue

  We’re trying to avoid taking new clients for a while, since we don’t actually need the money and would rather have CityDesk done right now. But this is something we reevaluate constantly.

Ted Graham Writes:

Since you are an ex-microsoftie, I have a question for you: does Microsoft use VSS for their projects? I can’t see how they would, it doesn’t seem to have the features needed to support multiple versions. I’m a consultant on a fairly large VC++ project on Win2K and we are about to make our first shipment to the end users. I’ve been looking for a way to do branching like I’m used to in PVCS, but not finding anything. It seems like it has labels available, but we can’t branch an individual file off and label the branch. Any ideas?

I can’t really speak for what Microsoft uses; I haven’t been there in years and SourceSafe didn’t exist when I was there. But I have heard only bad things about it. What I’ve heard from other programmers is that it’s not so strong in the data reliability department. Oops.

Do yourself a favor – use CVS like everyone else; it’s simple, reliable, ubiquitous, and rock-solid.

As research for the next book I’m supposed to be writing, I’ve been reading Michael E. Porter‘s book Competitive Strategy. It’s a brilliant book and it is considered the standard text on the subject, read by freshly hatched management consultants worldwide. But it’s drier than school cafeteria chicken, and every time I read two pages, I have to take a nap.

It’s worth it, so I’ve been taking a lot of naps lately. I’m only on page 57. 

One thing the book emphasizes is that you should analyze your competition and try to guess how they will react to your move. Here’s one question to ask yourself:

Are there any regulatory, antitrust, or other governmental or social constraints on the behavior of the firm that will affect such things as its reaction to moves of a smaller competitor or the probability that it will try to gain a larger market share? Has the competitor had any antitrust problems in the past? … Has it entered into any consent decrees? Such restraints or even just a history may sensitize a firm so that it foregoes reacting to strategic events unless some essential element [of] its business is threatened. The firm attempting to capture a small share of a market from an industry leader can enjoy some protection as a result of such constraints, for example. [page 53]

Of course, antitrust reminds me of Microsoft. Microsoft has always acted, against all credibility, as if it didn’t do anything remotely wrong — pundits ask “how can Microsoft executives be the only ones in the world who are so delusional about the legality their anticompetitive behavior?” Microsoft’s strategy has been to proclaim their innocence repeatedly; to continue to compete aggressively in all areas, and to merrily do new things, such as requiring Passport accounts for everything, which are bound to get them into anti-trust trouble yet again. Why?

If you’ve been working in the software industry, you’ve probably seen zillions of good new product ideas quashed by some executive who asks, “what if Microsoft enters this space and makes all the profits go away?” Lemming VCs generally have a policy of automatically saying “no” to any investment that could be seen as competing with Microsoft or which might prod Microsoft to create a new product in response. This herd fear of Microsoft in the software industry is enormously beneficial to Bill … lots of potential competition never gets off the ground because of fear that Microsoft will squash it.

This benefit would be lost if Microsoft acted even slightly concerned about the Justice Department. Put 2 and 2 together: if Microsoft were to act contrite and concede even the slightest point in the Justice Department’s anti-trust case, hundreds of independent software companies and VCs would see this as their opportunity to enter Microsoft’s markets and try to get a small piece of market share, knowing that Microsoft would be sensitized against appearing to be monopolistic and therefore might allow smaller competitors to survive. Bill Gates remembers working with IBM on OS/2 in the late 1980s, when it was completely impossible to get anything accomplished at IBM. Microsoft has an institutional memory of how ineffectual that company was against competitors: everything IBM did had to be reviewed by internal consent decree committees to make sure it wasn’t monopolistic, and it was no problem for young companies (like, um, Microsoft) to take big bites out of IBM’s ankles without provoking a reaction.

Seen in that context, Microsoft’s squashing of Netscape could well have been intended as a stern warning across the bow of Kleiner Perkins to stay the hell out of their garden; as much as Marc Andreessen’s childish threats to replace Windows was threatening, it was even more threatening that John Doerr seemed to have lost the fear of Microsoft that is vital to Microsoft’s dominance of the software industry.

It only makes sense to read Porter after you’ve spent a few years reading the business press; every sentence will remind you of dozens of examples you’ve seen across other industries and the whole thing will make sense. That’s the other reason this book takes me so long to read (besides the obligatory naps caused by it’s soporific nature): every sentence makes me look up at the ceiling, say “Ah-ha!” and rethink some aspect of how the software industry works in a new light.

George Moromisato at Groove Networks writes:

I read “Joel on Software” more or less religiously and I’m always intrigued by your insights. Your column on Architecture Astronauts was no different, except for your dismissal of Groove as software that “miss[ed] the point” of Napster’s example. I hope to take a few moments of your time to convince you to give Groove another chance.

Like Napster, we also consider peer-to-peer to be a means to an end, not the end in itself. For Groove, the end goal is not to search for music on the Internet (as cool as that is); Groove’s end goal is to allow people to interact and share information on the Internet without regards to time, distance, or corporate infrastructure.

The last point is worth diving on: Today, if I want to share information with someone outside my corporate infrastructure I have three plausible choices: 1) use email, which is not very interactive, has very little persistence, and is often insecure; 2) use an internal web server, which requires me to ask my IT administrator to either open up a hole in the firewall or to deploy some section on our extranet; or 3) use a public web server, which now is privy to my corporate data and may take it with them when they go under. The cool thing about Groove, and one of the problems that we were trying to solve, is that I can use it like email to communicate with someone outside my infrastructure (they can download the client for free) and I don’t have to worry about a server (we are peer-to-peer when appropriate) or a firewall (we go through firewalls) or security (since Groove communications are by invitation only and heavily encrypted). The best part, IMHO, is that, while we provide some basic tools to interact inside a Groove space (sharing files, doodling, voice chat, forums, etc.), we have also built a platform that allows third parties to extend Groove in whatever direction they want, all without having to ask us to change our servers or upgrade the core product!

[pause while I stop hyperventilating]

The bottom line is that I think it was unfair of you to consider us Architecture Astronauts. It is true that we do not solve the problem that Napster was trying to solve, but I think we have been successful at solving the problem that we set out to solve. Also, to be fair, we have managed to ship a product (and even sell it to people) unlike some of the Architecture Astronauts that you are thinking of.

Anyway, I hope I haven’t completely wasted your time. Thanks for your columns and good luck with everything.

George Moromisato
Chief Product Designer
Groove Networks

My reply:

I like Groove, I think it’s a nice architecture. I think in many ways it’s Notes done right, eliminating one of the biggest problems with Notes — the server bottleneck which crippled large Notes installations.

On the other hand, Notes was the most misunderstood product in history 🙂 It was being sold as a groupware platform, but in reality, it was being bought (and used) as an email program. A few people used the discussion groups and document databases, and an even smaller number actually created applications on top of Notes, but the reason companies with 50,000 people bought Notes was really for email.

Which, unfortunately, didn’t work quite well enough in Notes. At Bankers Trust in the mid-90’s, management ruled that no new Notes accounts could be created, because of an incident where Notes replication between servers managed to tie up the company’s crucial transatlantic link thus cutting London off from New York for an entire trading day. As a result Bankers Trust was in the awkward position of ruling “no new Notes accounts!”

At Viacom a couple of years later, Notes was shelfware because the email component was too hard for most people to figure out. Everybody in the company had AOL accounts which they expensed because they could figure that out.

Note that none of this is necessarily a bad thing from a company perspective: Notes sold scrillions of copies and was considered a raging success. In theory, Groove is even cooler, because it’s Notes without the server headaches.

Anyway, now we’re talking about architecture. Let’s talk about features. The applets you ship with are all spiffy but not ultra-compelling, because you can often get the same functionality elsewhere. And it’s the applets that are going to sell Groove, not the architecture. If you don’t believe me look at NeXT and Be … you can build the best dang computer in the world with a killer architecture, but if it doesn’t run Microsoft Excel, nobody wants one. When you say “it’s a platform, third parties will build things,” you have to explain what KIND of things and why THEY will be killer apps that sell the architecture. If you keep hearing the same examples, you’re in deep trouble — like the idiot WAP people who talk endlessly about how “you’ll walk by a starbucks and the GPS in your phone will coordinate to beam you a coupon for that starbucks.” I’ve heard this same example a zillion times from “location based wireless” architecture astronauts and it amuses me, because it solves the one problem that coffee shops DON’T have, namely, advertising to people who are standing right in front of the store! 🙂

So… yes, you shipped a product, and sold it to people, it’s great, I believe you. But if you want it to be The Next Great Thing it has to be more than architecture, it has to enable things that people really need.

Since my company is moving to a new office, I’ve been calling around trying to find an Internet provider. In Manhattan these days, you have a zillion choices. It seems like every Internet provider in the known universe offers service in Manhattan.

We’re probably going to get a T1 line from Savvis. Getting a T1 installed takes a couple of months, and we were worrying about what to do while we wait. ISDN and DSL are nightmares to install and take just as long to get installed. In desperation I was considering a dedicated dial up service, which is usually expensive as hell (something like $100 – $150 per month) and slow (modem speed). Or maybe a bonded modem service, where you use two modems and some expensive equipment to get double modem speed (realistically, that would be about 80kbps).

Then I found Juno Express, a service provided by my alma matter (I worked at Juno until about a year ago). It’s a wireless modem that runs at 128kbps. The service and modem are actually provided by Ricochet, which is really another name for Metricom. The one thing about the new economy is that nobody wants to get their hands dirty. Juno doesn’t want to get their hands dirty with messy hardware and infrastructure, and Metricom doesn’t want to get their hands dirty with customer service and billing (“ew”), and in fact, Juno even outsources their customer service to a company in Canada which answers the phone.

Anyway, I called Juno and ordered Juno Express Wireless. They will sell you a modem for $99, and the monthly service is $80 for unlimited usage. This is a fantastic deal if you’ve ever priced wireless Internet access in the past. (I remember when it was $25 per megabyte, not so long ago, for download speeds around 9.6kbps.)

The first Ricochet modems ran at 28.8 kbps. They are now transitioning over to a new technology that provides 128kbps, which is what I’m using. Wow! That’s dual channel ISDN speed! The trick is that the high speeds are only available in a few places. Luckily, Manhattan is one. Metrocom has been installing small shoebox-sized transmitters on light poles throughout Manhattan, since the technology they are using doesn’t have very long range (the cells aren’t nearly as large or as strong as typical cell-phone cells).

The modem itself is the size of a small paperback book, with a little antenna that folds out. It connects to your laptop computer via a USB port. (It can use a serial port, but the speed is slower if you do that). It has its own battery that runs for 6 hours so it doesn’t have to suck up your laptop’s battery. Yes, it’s really 6 hours… I ran it down today.

Installation was almost easy. Once I got everything set up, Juno was still giving me weird error messages. Luckily I remembered, from my time as a programmer at Juno, that the Juno system requires you to check your mail at least once when any features of your account change so that the Juno servers can update the client with your new service information. I think that if I didn’t have this “inside information” I would have been pretty frustrated, and I would have had to call Juno tech support. Anyway, by checking my Juno email once using my home DSL connection, everything was fixed up and I was able to start using Ricochet successfully.

My apartment is in the back of a big, brick brownstone in a dense part of Manhattan’s Upper West Side. So the signal wasn’t very strong. The maps on Ricochet’s site implied that they have more transmitters in midtown anyway. At home, the service was very bursty. When it worked, it was fast, but a lot of the time, it was super-slow (like 14.4 modem speed). This doesn’t surprise me or bother me very much… I can barely get cellular reception from behind all the masonry on my block.

So I took the modem out to a local cafe on Broadway and 70th, near a major avenue, and tried it from there. Tada! This is how it was meant to work. This thing is fast. You do get 128 kbps, sometimes more. I tried a whole bunch of the various line-speed-tests around the Internet, like C|net‘s. These tests are shockingly unscientific, since there are so many other things that can slow down a connection between your machine and the server where they are running, but I did get results between 70 kbps and 180 kbps. Nice! The overall feel of the thing is great. While I’ve been writing this article, I’ve been uploading pictures, sending email, browsing the web, and some people have emailed me some really huge attachments which I’ve forwarded on… the overall speed is great, much much faster than a “56kbps” modem which usually gets you more like 40 kbps. And it’s wireless! And it’s easy to install! And it only took two days from placing an order to being online! (They must have shipped the modem the day I called).

I also tried the service from a friend’s house around the corner; it works at around 128kbps there, too. Slick.

Now, $80 a month may sound like a lot for a home user. But for our small office of five people, for a temporary solution while we wait for the T1, it’s going to be great. And for working as consultants, where we’re all over the city working at clients’ sites, working from cafes and libraries, etc., it will also be great; I’m thinking of equipping my entire team with these so we don’t have to rely on clients’ Internet connections.

There are two things I would change. First, I wish there was a capability to attach a big antenna when you want to have a fixed installation with better reception. Maybe that’s an FCC restriction?

I also wish it gave you some idea of the signal strength as you moved the antenna around so you could adjust it for optimal reception. There is no way to tell which way to wiggle the antenna.

Note: Someone on the Yahoo message boards has since informed me that you can check the signal strength by pressing in the power slide switch, which gives you from 1 – 4 beeps indicating signal strength. Totally non-obvious and not in the documentation, but it seems to work!

Another big problem is the coverage. This thing works in the downtown areas of 10 cities. But in the past couple of years, the places where I want wireless access are not downtowns. Maybe I’m staying with a friend and don’t want to tie up their modem. Or I’m at the beach. Last year I was in the middle of the Navajo reservation and I needed Internet access. I suspect Ricochet ain’t never gonna have base stations in the middle of the Navajo reservation.

August 2, 2001: Ricochet Closes Down. They spent $500,000,000 and went out of business owing almost a billion dollars, with 51,000 subscribers. They would have had to make about $30,000 per subscriber for the business idea to have worked.

Until yesterday, the FogBUGZ license said that you couldn’t reverse engineer the program, attempt to look at the source code, or modify it in any way. Various honest people have asked how much we charge for a source license, so that they could customize a few things.

Hmmm. Why does the license say you can’t change the source code? I couldn’t think of a single reason. In fact I thought of a lot of counter-reasons, and immediately changed the license agreement. So now you’re going to have to sit through one of those old-fuddy-duddy stories from my past.

Way back in 1995, I was working at Viacom, where a small group of us hardy pioneers were building web sites for various Viacom properties.

In those days, there were no application servers. Sybase was so clueless that if you wanted to use their database on the Internet they told you that you needed to buy a $150 client license for every user that connects to your web site. Netscape’s web server was up to version 1.0.

A brave company called Illustra started telling people that their database management system was perfect for the web. You see, Illustra was designed to make it easy to add new data types by writing some C code and linking it in with their DBMS. (Any programmer who’s used a DBMS will tell you that this is already sounding a bit too dangerous. C code? linked in? Oy.) This was originally intended for exciting data types like Latitude/Longitude, time series, and so on. But then the web happened. Illustra wrote something they called a “Web Blade” and linked it in. The Web Blade was a sort of half-baked system that allegedly made it possible to extract data from the database and create dynamic web pages on the fly, which was the biggest problem everybody had in 1995.

A colleague of mine at Viacom was put in charge of building an ecommerce site so that Blockbuster could sell, I kid you not, CDs on the web. (Because that’s what people think of when they think of Blockbuster, right?) Anyway, he thought that Illustra would be perfect for the job. Now, Illustra cost something like $125,000, and shaking that much money loose from the Viacom Tree is like herding cats, so it took a while. My colleague taped a paper cup to his cube labeled “Illustra Fund” and collected a few dollars that way. The CTO negotiated hard and long hours with Illustra and eventually a deal was struck. We installed Illustra and got to work.

Unfortunately, disaster struck. Illustra’s Web Blade was barely half baked and completely not up to the task. It crashed every few minutes. When it did run, it proved to have the only programming language I’ve ever seen that wasn’t Turing-equivalent, if you can imagine that. The license manager kept deciding to shut you off and your site would die. Building a site with it was terrible, my colleague’s annus horribilis. So when they came to me and said, “Joel, you’re making a site for MTV,” I said, “uh oh.”

“Please can I not use Illustra?” I begged.

“Well, OK, but what are you going to use instead?” There really weren’t any other app servers in those days. There was no PHP, no AOLServer with TCL stuff, perl had to fork, we didn’t have penicillin, life was terrible.

And my reputation was on the line. And I decided that the scariest thing about Illustra was that when it crashed, you couldn’t do anything about it. At least, if you had the source code, I thought, if Illustra crashes, well, it falls into your lap in the debugger and you can try to fix the bug. You may have to stay up all night for a week debugging someone else’s code, but at least you have a chance. Whereas, without the source code, you are up the proverbial tata without a tutu.

And that’s where I learned a key lesson in software architecture: for your most important, mission critical stuff, you have to use a tool that is one level lower in abstraction than ideal. For example, if you’re writing a cool 3D shoot-em-up game (like Quake, around the same time period) and your key number 1 differentiator is to have the coolest 3D graphics, you do not use whatever 3D library you can find. You write your own, because it’s fundamental to what you do. The people who use 3D libraries like DirectX are using them because they are trying to differentiate their games on something other than 3D performance. (Maybe the story line.)

That’s when I decided not to trust anyone else’s poxy application server, and decided to just write my own, in C++, using Netscape Server’s low level API. Because I knew that at least, if anything went wrong, it was in my code and I could eventually fix it.

And this is one of the greatest virtues of open source / free software, even if you could afford Illustra’s $125,000 piece of tata: at least if anything goes wrong, you are going to be able to fix it, somehow, and you won’t get fired, and the nice-if-hyperactive people at MTV won’t be all pissed off at you.

When I sit down to architect a system, I have to decide which tools to use. And a good architect only uses tools that can either be trusted, or that can be fixed. “Trusted” doesn’t mean that they were made by some big company that you’re supposed to trust like IBM, it means that you know in your heart that it’s going to work right. I think today most Windows programmers trust Visual C++, for example. They may not trust MFC, but MFC comes with source, and so even though it can’t be trusted, it can be fixed when you discover how truly atrocious the async socket library is. So it’s OK to bet your career on MFC, too.

You can bet your career on the Oracle DBMS, because it just works and everybody knows it. And you can bet your career on Berkeley DB, because if it screws up, you go into the source code and fix it. But you probably don’t want to bet your career on a non-open-source, not-well-known tool. You can use that for experiments, but it’s not a bet-your-career kind of tool.

So I got to thinking about how to make FogBUGZ a safe bet for smart engineers. Almost by accident, it ships in source code form — because that’s how ASP pages work these days. Which doesn’t bother me. There are no magical, trade-secret algorithms in bug tracking software. This stuff is not rocket science. (In fact, there are very few magical, trade-secret algorithms in any software. The fact that it’s fairly easy to disassemble an executable and figure out how it works just doesn’t matter as much as intellectual property lawyers think it should.) It doesn’t matter to me that people look at the code or modify the code for their own use.

There’s another risk when you modify source code that you bought from a vendor: when the vendor upgrades the code, you are going to have a heck of a time migrating your changes to their new version. There’s something I can do to ameliorate that, too: if you find a bug in FogBUGZ and fix it, and send me the fix, I’ll incorporate it into the next version. This is intended to make people feel a little bit more comfortable that (a) FogBUGZ works, and (b) if it doesn’t work, in some mission-critical way, they can fix it rather than get fired, and (c) if they do have to fix it, and their fix makes sense, it will get back into the source tree so that the next version will incorporate their fixes and life will be less brutish.

By now I can hear the open-source and free software advocates practically screaming, “you silly goose! just make it open source and be done with it! open source doesn’t have any of these problems!” And that’s nice. But my wee company with three programmers costs $40,000 a month to operate. So we just charge for our software, and we don’t apologize, because it’s worth the money. We don’t claim to be open source but we can make sure that FogBUGZ is a safe decision to make, by adopting two or three nice features from the open source world.

 

… and I’m very thankful, because Netscape 6.0 has been a terrific illustration of so many of the points I’ve made in Joel on Software over the last 6 months. Unfortunately, it’s usually an illustration of what not to do.

Way back in April, I wrote that Netscape made the “single worst strategic mistake that any software company can make” by deciding to rewrite their code from scratch. Lou Montulli, one of the 5 programming superstars who did the original version of Navigator, emailed me to say, “I agree completely, it’s one of the major reasons I resigned from Netscape.” This one decision cost Netscape 3 years. That’s three years in which the company couldn’t add new features, couldn’t respond to the competitive threads from Internet Explorer, and had to sit on their hands while Microsoft completely ate their lunch.

When they did, finally, release their software, it doesn’t seem like they did very much testing. The Joel on Software discussion group was full of complaints of bugs and general instability. This is one thing you can’t blame AOL for; when a new release of AOL ships, you don’t usually hear such an upcry about bugs. In Top Five (Wrong) Reasons You Don’t Have Testers, I wrote that Netscape “did an almost supernatural amount of damage to its reputation through their ‘testing’ methodology.” “Testing” in quotes because their methodology seems to be to ship to millions of people and then ignore any bug reports that come in. The sheer volume of bugs, it seems, proves that rewriting code from scratch does not make for a better code base, it makes it worse. Old code doesn’t rust, it gets better, as bugs are fixed. Lou Montulli again: “I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.”

The biggest single complaint about Netscape 6.0 revolves around the way they reimplemented every UI widget from scratch. Indeed, they felt that this was the only way to get cross platform compatibility. (It’s not. Microsoft Word and Excel are completely compatible between Mac and Windows versions, and they use native widgets and UI on each platform. When Mac Word 6.0 shipped, in which Microsoft had tried to make the interface a little bit more consistent with the Windows version, there was such a hue and cry from Mac loyalists that Microsoft had to ship a new version.) Many people complained about Netscape 6.0, for example, that you can’t right-click in the edit boxes and get a context menu — a feature which is available “for free” when you use the Windows native controls. Netscape 6 is just not very usable because it violates many rules of consistency. It’s not going to win many friends who were using IE (something like 95% of the users hitting my company site are IE users) because some of the things that IE users do just don’t work. For example, rather than reach for the mouse, I tend to go to a URL by typing Alt+D (which jumps to the address bar), typing the middle part of the URL (e.g. “nytimes” to go to “http://www.nytimes.com”) and pressing Ctrl+Enter (in IE, this automatically adds “http://www” and “.com” for you). The Alt+D / Ctrl+Enter combination is burned into my fingers now, but when I try it with Netscape 6, of course, it doesn’t work. Similarly, I’ve gotten into the habit of Shift+Clicking to open a link in a new window; Netscape opens the link in the same window. And I can’t use the scrolling mouse button on my ThinkPad to scroll, something which works with every other window in every other application I’ve ever used. I can’t even Alt+Space to get the context menu. I’m used to using Alt+Space N to minimize a window, and Netscape won’t do it. This is the first time I’ve ever seen a Windows app where Alt+Space N doesn’t work.

This is a lesson Microsoft learned years ago with Excel – which interprets Lotus 123 keystrokes perfectly – and Word, which is happy to go so far as to emulate WordPerfect’s white-on-blue screen. (I talk about the importance of consistency in Chapter 5 of UI for Programmers).

Netscape’s groovy “skinz” UI doesn’t honor the system settings. Once you’ve set the preferred system color scheme and fonts in Windows, Netscape will completely ignore them. For me, that’s just a nuisance. For vision-impaired users who need to set fonts very large or use high-contrast color schemes, it’s a reason not to use Netscape.

I can’t prove it, but I have to imagine that Netscape didn’t have a schedule for 6.0, choosing instead to meander for years and years and suddenly “find the religion” about shipping on time when it’s way too late to cut trivial features, like themes, and instead finish the important features, like standards compliance. Without a prioritized schedule, programmers will do the fun features first, not the important ones, where “fun” is very loosely defined.

Let me step back for a moment and point out one thing that I think that Netscape did right. If you’ve ever used Microsoft Outlook, you’ve probably been confused about how the Outlook Bar works:

Netscape’s Sidebar has exactly the same behavior as the Outlook bar, but with a slightly different visual appearance that makes it a zillion times easier to understand:

This is so much easier to understand because it uses a real world metaphor. The visual screen conveys the program model, teaching the user how it works, thus bringing the user model in line with the program model which makes it very easy to figure out. Sadly, this nice metaphor only works in the default theme; other themes (such as Sky Pilot) seem to have been created by people who are not as sensitive to the value of metaphors.

Joel on Software has subscribers in 44 countries:

Argentina
Australia
Austria
Belgium
Botswana
Brasil
Canada
Chile
Denmark
Estonia
Finland
France
Germany
Greece
Hong Kong
Iceland
India
Ireland
Israel
Italy
Latvia
Lebanon
Lithuania
Malaysia
Mexico
Netherlands
New Zealand
Norway
Philippines
Poland
Portugal
Romania
Russia
Singapore
Slovak Republic
Slovenia
South Africa
Spain
Sweden
UK
United Arab Emirates
USA
Western Samoa
Yugoslavia

I used to have Atomz.com as my search provider. That means that when you typed a search request in that little search box in the margin, it actually sent the request to Atomz.com. They were responsible for indexing my site once a week and displaying the results.

Atomz.com is “free”, with a catch: as soon as you have more than 500 pages on your site, they send you a nice little email:

I just wanted to take this opportunity to remind you that your website has exceeded the 500 page document limit for the free account that you currently have. Did you realize that 100% of your site is not currently being indexed? Only the FIRST 500 PAGES are being indexed. Is this an important concern to you and the services that you provide to others? If yes, upgrading to an atomz.com prime service will solve these issues.

Nowhere in the email does it tell you how much it’s going to cost for the upgrade. A bit of searching on their web site gave me the answer: $100 per quarter. Wow. That’s expensive.

Search on my site is not super popular; I get about 60 searches a week (out of about 35,000 page views). But I think it’s an important function. And I hate being tricked into upgrading from a ‘free’ service to a ‘premium’ service.

Atomz.com is hoping to achieve what I call ‘stealth lock-in‘. They don’t even want to you realize that you’re becoming dependent on a service. In the future, when you’re hooked, they can start charging you a bundle, and you’ll pay them just to avoid the cost of switching. There are a lot of Internet companies that are trying this approach. Juno constantly bombards its unpaying members to upgrade to the services that cost money. All the various xdrive/idrive/freedrive/mydrive clones have this business model. My buddy Elan’s company earthnoise, which gives you 50M of online video storage free, tries to upgrade you to the premium service at $4.99 a month when you realize that 50M is not that much online video.

The question here is: how much lock-in do these companies really have? That’s what is going to determine whether their plans work or fail. Juno has a lot, because it’s an email service, and if you switch your email provider, you have to tell all your friends about the new email address. If you printed a Juno email address on your business card and handed it out to prospective clients, you’re going to be scared to switch away. And indeed, Juno has been reasonably successful at getting people to upgrade.

All the free-hard-drive-on-the-net companies have zero lock in. They are going to have a problem. Besides the fact that there is almost no barrier to entry, incredible competition, and the service is stupid to begin with, these companies are simply not going to succeed, period.

Now, back to Atomz.com, my old search service. Lock-in? Well, I’m afraid not. It took me 20 minutes to switch over to Google. Kiss them goodbye.