RealNames is going out of business. They deserve it. It was just a dumb scam to try and establish yet another Verisign-like monopoly on everybody else’s trademarks. And it was a “boil the ocean” business plan, one which required everybody on earth to go along with their stupid scheme. And Keith Teare’s public crybabying is really quite unprofessional, albeit fun to read.

Now if New.net would kindly just go away. Why anybody would pay actual money, the stuff that can be used to purchase valuable goods and services, for a domain name that is only visible to a fraction of the Internet is completely beyond my comprehension. Another scam hoping to prey on stupid businesses?


Bertrand Meyer provides a far better analysis than I did about multiple languages in .NET in this month’s Software Development Magazine. “Of course, the [.NET] languages involved have their own models, which may differ significantly from the .NET object model. That’s to be expected: Otherwise, they wouldn’t really be different languages, just a different syntax and minor variations on a single language theme. To a certain extent, this characterization could be applied to C# and Visual Basic .NET; one may claim that these two are, deep down, just one language, now that VB has become an OO language. But it’s definitely incorrect if we consider the entire set of .NET language players.”

He goes on to point out that “Managed C++ is very close to C#, in spite of what the default Microsoft descriptions would have you believe.” And I’m sure when Java.NET comes out it will be too.


Five Worlds: not all software development is the same.

PS. There is a large grey area between internal, consultingware, and shrinkwrap – the three worlds are often a continuum. Often products start out as internal products, then the business guys have the bright idea of selling it to other companies, but it is so brittle and makes so many assumptions about its environment that it takes weeks to install it at other customers’ sites, which is how consultingware is born. (cf. Vignette StoryServer which started as c|net’s inhouse content management system and now costs millions to get running.) Theoretically the software should then migrate towards shrinkwrap as the customer base grows, with increasing emphasis on ease of installation, but these companies get so addicted to their consulting revenue they don’t see any benefit in making it easier to use off-the-shelf. And many internal developers have no prior experience with making software run in the wild, so it doesn’t.

Five Worlds

Something important is almost never mentioned in all the literature about programming and software development, and as a result we sometimes misunderstand each other.

You’re a software developer. Me too. But we may not have the same goals and requirements. In fact there are several different worlds of software development, and different rules apply to different worlds.

You read a book about UML modeling, and nowhere does it say that it doesn’t make sense for programming device drivers. Or you read an article saying that “the 20MB runtime [required for .NET] is a NON issue” and it doesn’t mention the obvious: if you’re trying to write code for a 32KB ROM on a pager it very much is an issue!

I think there are five worlds here, sometimes intersecting, often not. The five are:

  1. Shrinkwrap
  2. Internal
  3. Embedded
  4. Games
  5. Throwaway

When you read the latest book about Extreme Programming, or one of Steve McConnell’s excellent books, or Joel on Software, or Software Development magazine, you see a lot of claims about how to do software development, but you hardly ever see any mention of what kind of development they’re talking about, which is unfortunate, because sometimes you need to do things differently in different worlds.

Let’s go over the categories briefly.

Shrinkwrap is software that needs to be used “in the wild” by a large number of people. It may be actually wrapped in cellophane and sold at CompUSA, or it may be downloaded over the Internet. It may be commercial or shareware or open source or GNU or whatever — the main point here is software that will be installed and used by thousands or millions of people.

Shrinkwrap has special problems which derive from two special properties:

  • Since it has so many users who often have alternatives, the user interface needs to be easier than average in order to achieve success.
  • Since it runs on so many computers, the code must be unusually resilient to variations between computers. Last week someone emailed me about a bug in CityDesk which only appears in Polish Windows, because of the way that operating system uses Right-Alt to enter special characters. We tested Windows 95, 95OSR2, 98, 98SE, Me, NT 4.0, Win 2000, and Win XP. We tested with IE 5.01, 5.5, or 6.0 installed. We tested US, Spanish, French, Hebrew, and Chinese Windows. But we hadn’t quite gotten around to Polish yet.

There are three major variations of shrinkwrap. Open Source software is often developed without anyone getting paid to develop it, which changes the dynamics a lot. For example, things that are not considered “fun” often don’t get done in an all-volunteer team, and, as Matthew Thomas points out eloquently, this can hurt usability. Development is much more likely to be geographically dispersed, which results in a radically different quality of team communication. It’s rare in the open source world to have a face to face conversation around a whiteboard drawing boxes and arrows, so the kind of design decisions which benefit from drawing boxes and arrows are usually decided poorly on such projects. As a result geographically dispersed teams have done far better at cloning existing software where little or no design is required.

Consultingware is a variant of shrinkwrap which requires so much customization and installation that you need an army of consultants to install it, at outrageous cost. CRM and CMS packages often fall in this category. One gets the feeling that they don’t actually do anything, they are just an excuse to get an army of consultants in the door billing at $300/hour. Although consultingware is disguised as shrinkwrap, the high cost of an implementation means this is really more like internal software.

Commercial web based software such as Salesforce.com or even the more garden variety eBay still needs to be easy to use and run on many browsers. Although the developers have the luxury of (at least) some control over the “deployment” environment — the computers in the data center — they have to deal with a wide variety of web browsers and a large number of users so I consider this basically a variation of shrinkwrap.

Internal software only has to work in one situation on one company’s computers. This makes it a lot easier to develop. You can make lots of assumptions about the environment under which it will run. You can require a particular version of Internet Explorer, or Microsoft Office, or Windows. If you need a graph, let Excel build it for you; everybody in our department has Excel. (But try that with a shrinkwrap package and you eliminate half of your potential customers.)

Here usability is a lower priority, because a limited number of people need to use the software, and they don’t have any choice in the matter, and they will just have to deal with it. Speed of development is more important. Because the value of the development effort is spread over only one company, the amount of development resources that can be justified is significantly less. Microsoft can afford to spend $500,000,000 developing an operating system that’s only worth about $80 to the average person. But when Detroit Edison develops an energy trading platform, that investment must make sense for a single company. To get a reasonable ROI you can’t spend as much as you would on shrinkwrap. So sadly lots of internal software sucks pretty badly.

Embedded Software has the unique property that it goes in a piece of hardware and in almost every case can never be updated. This is a whole different world, here. The quality requirements are much higher, because there are no second chances. You may be dealing with a processor that runs dramatically more slowly than the typical desktop processor, so you may spend a lot of time optimizing. Fast code is more important than elegant code. The input and output devices available to you may be limited. Picture of Hertz Neverlost GPSThe GPS system in the car I rented last week had such pathetic I/O that the usability was dismal. Have you ever tried to input an address on one of these things? They displayed a “keyboard” on screen and you had to use the directional arrows to choose letters from five small matrices of 9 letters each. (Follow the link for more illustrations of this UI. The GPS in my own car has a touch screen which makes the UI dramatically better. But I digress).

Games are unique for two reasons. First, the economics of game development are hit-oriented. Some games are hits, many more games are failures, and if you want to make money on game software you recognize this and make sure that you have a portfolio of games so that the blockbuster hit makes up for the losses on the failures. This is more like movies than software.

The bigger issue with the development of games is that there’s only one version. Once your users have played through Duke Nukem 3D, they are not going to upgrade to Duke Nukem 3.1D just to get some bug fixes and new weapons. With some exceptions, once somebody has played the game to the end, it’s boring to play it again. So games have the same quality requirements as embedded software and an incredible financial imperative to get it right the first time. Shrinkwrap developers have the luxury of knowing that if 1.0 doesn’t meet people’s needs and doesn’t sell, maybe 2.0 will.

Finally Throwaway code is code that you create temporarily solely for the purpose of obtaining something else, which you never need to use again once you obtain that thing. For example, you might write a little shell script that massages an input file that you got into the format you need it for some other purpose, and this is a one time operation.

There are probably other kinds of software development that I’m forgetting.

Here’s an important thing to know. Whenever you read one of those books about programming methodologies written by a full time software development guru/consultant, you can rest assured that they are talking about internal, corporate software development. Not shrinkwrapped software, not embedded software, and certainly not games. Why? Because corporations are the people who hire these gurus. They’re paying the bill. (Trust me, id software is not about to hire Ed Yourdon to talk about structured analysis.)

Last week Kent Beck made a claim that you don’t really need bug tracking databases when you’re doing Extreme Programming, because the combination of pair programming (with persistent code review) and test driven development (guaranteeing 100% code coverage of the automated tests) means you hardly ever have bugs. That didn’t sound right to me. I looked in our own bug tracking database here at Fog Creek to see what kinds of bugs were keeping it busy.

Lo and behold, I discovered that very few of the bugs in there would have been discovered with pair programming or test driven development. Many of our “bugs” are really what XP calls stories — basically, just feature requests. We’re using the bug tracking system as a way of remembering, prioritizing, and managing all the little improvements and big features we want to implement.

A lot of the other bugs were only discovered after much use in the field. The Polish keyboard thing. There’s no way pair programming was going to find that. And logical mistakes that never occurred to us in the way that different features work together. The larger and more complex a program, the more interactions between the features that you don’t think about. A particular unlikely sequence of characters ({${?, if you must know) that confuses the lexer. Some ftp servers produce an error when you delete a file that doesn’t exist (our ftp server does not complain so this never occurred to us.)

I carefully studied every bug. Out of 106 bugs we fixed for the service pack release of CityDesk, exactly 5 of them could have been prevented through pair programming or test driven design. We actually had more bugs that we knew about and thought weren’t important (only to be corrected by our customers!) than bugs that could have been caught by XP methods.

But Kent is right, for other types of development. For most corporate development applications, none of these things would be considered a bug. Program crashes on invalid input? Run it again, and this time watch your {${?’s! And we only have One Kind of FTP server and nobody in the whole company uses Polish Windows.

Most things in software development are the same no matter what kind of project you’re working on, but not everything. When somebody tells you about methodology, think about how it applies to the work you’re doing. Think about where the person is coming from. Steve McConnell, Steve Maguire, and I all come from a very narrow corner: the world of mass market shrinkwrap spreadsheet applications written in Redmond, Washington. As such we have higher bars for ease of use and lower bars for bugs. Most of the other methodology gurus make their living doing consulting for in house corporate development, and that’s what they’re talking about. In any case, we should all be able to learn something from each other.


Why Religious Wars are Stupid

Yesterday I made what I thought was a lightweight claim about how the “choice” of languages in .NET is not as much of a choice as you might think.

Some people assume that this means I am against .NET, or I’m “clueless,” because I don’t understand the productivity benefit of managed code.

OK, they didn’t read what I wrote less than a month ago praising the productivity of .NET.

Of course, when I wrote that, some people assumed it meant I was for .NET, and dug up an old article from two years ago in which I complained that an early white paper on .NET didn’t say anything. (It was true, the white paper didn’t, and .NET didn’t ship for 2 years). So I’m a hypocrite because I used to be against .NET and now I’m for .NET.

Anything as complicated as .NET is bound to have many positive aspects and many negative aspects. Duh. The stupid thing about religious wars is when one person says, “you don’t get as much language choice as you think” and the other person says, “you are clueless, because you’re 4-6x more productive!” What a waste of time.

The World Is Complicated. Get Used To It.

Some people can’t. Look at how angry Michel gets because I point out that (a) features sell products and (b) choices reduce usability. So? The whole point of design is that you have different goals that you need to resolve. Want to design a trashcan for street corner? You have to make it light so it can be emptied easily. You have to make it heavy so it won’t blow away. You have to make it big so it will hold lots of trash and the trash won’t blow out. You have to make it small so it won’t take up too much space. You have to make it easy to throw trash in so people don’t miss and litter. You have to make it hard for trash to get out so when it’s windy the street doesn’t litter itself. Design is all about making hard choices and, hopefully, sometimes, hitting upon elegant solutions that solve conflicting goals. But when you can’t solve conflicting goals, you have to be smart enough to decide which goal to solve, and not just be a lazy punter and pretend that adding a checkbox to the options dialog will solve it.


Don’t use Verisign. They suck, and there’s no reason to use them. I’ve been using register.com for domain names (although namebargain.com is cheaper and run by register.com with the same excellent interface) and Commercelock, also run by register.com, for digital certificates. Commercelock is actually provided by Baltimore Technologies which charges a heck of a lot more for exactly the same thing.


Why do developers choose one programming language over another for a given task?

Sometimes I choose raw C when I need blazing speed.

When I want something that will run on Windows with as small a distribution as possible, I often choose C++ with MFC statically linked.

When we need a GUI that will run on Mac, Windows, and Linux, a common choice is Java (although the GUI will not be perfect, it will work.)

For rapid GUI development and really smooth UIs, I like Visual Basic, but I know that I’m going to have to pay the price in the size of the distributable and the fact that I’ll be locked into Windows.

For a command-line tool that must run on any UNIX machine and doesn’t need to be fast, perl is a good choice.

If you have to run inside a web browser, JavaScript is the really the only choice. In a SQL stored procedure, you usually get to choose between one vendor’s proprietary SQL derivative or go home.

What’s the Point?

But I hardly ever choose a language based on syntax. Yeah, I prefer the {}; languages (C/C++/C#/Java). And I have lots of opinions as to what makes a “good” syntax. But I wouldn’t accept a 20 MB runtime just to get semicolons.

Which makes me wonder a bit about .NET’s cross-language strategy. The idea is, choose any language you want, there are zillions, and they all work the same way.

VB.NET and C#.NET are virtually identical except for tiny syntactic differences. And other languages that want to be part of the .NET world need to support at least a core set of features and types or they won’t be able to Play Well With Others. But how do I develop a UNIX command line utility in .NET? How do I develop a tiny Windows EXE in less than 16K in .NET?

It seems like .NET gives us a “choice” of languages precisely where we couldn’t care less about it — in the syntax.