Eddie Kessler describes programming at Napster.

Ray Ozzie has more on platforms. “Finding the ‘right’ price point for a software platform is critical.” To me this sounds like a fancy way of saying, “I groove all that stuff about how platforms need to be cheap and ubiquitous, but I can’t bring myself to do it.” The price, Ray says, “must be high enough both 1) to maintain a perception of value in the platform, and 2) to create significant margins well before ubiquity is assured so that the ecosystem is assured of the platform’s ultimate viability.” What he doesn’t mention: if you lower the price on the only product you’re selling, you have a revenue hit, which will not make your investors happy, and you may run out of money and have to close. But that must be what he’s thinking.

Dave Winer continues the Platform theme: “If you’re lucky enough to get a gazillion dollars invested behind your ideas, never say no to a developer.” General Magic had a platform they tried to position as an application. (Getting a gazillion dollars didn’t help them much, either.)

I’ve created a new discussion group for .NET programming questions. (Why?)

Let’s hope it doesn’t turn into this.

Orlando Sentinel: “After investing $273 million, NASA is canceling a cutting-edge launch-control computer system for the space shuttle that is over budget, behind schedule and too expensive to operate.”

(A few paragraphs later) “The CLCS program began in 1997 as an effort to upgrade KSC’s 1970s-vintage system.”

Here’s my question. In the 1970s, computers didn’t have much memory. An expensive mainframe from that era couldn’t have had more than a megabyte or so of core memory. It seems to me as if the most complex piece software that could possibly be run on such systems would pale in comparison to the complexity of the software in a modern CDMA cellular phone, also about a megabyte in Assembler code. (I know, somebody’s going to tell me about how mission critical this stuff is, and how lives depend on it, but heavens, $273 million dollars?)

The question is, why are NASA, the FAA, etc. still running these ancient systems, and why have so many quarter billion dollar projects failed to replace them? Jeez, they didn’t even have relational databases in those days, to say nothing about structured program, GUI development tools, and books by Kent Beck. Recreating those old systems with modern tools would probably be a weekend Visual Basic/Access project. OK, I’m exaggerating a little. But if the problem is that you can’t even get parts (vacuum tubes, no doubt) for the old system, you don’t need a zillion dollar Big Science project: you need a four week project writing a CPU emulator for that old mainframe that runs on PCs.

OK, maybe now we won’t be subject to all those annoying lectures about how great SEI Level 5 is because the shuttle uses it. Flipping back and forth between today’s news and that old FastCompany hagiography will keep you entertained for hours!

Ged Byrne points out that it was actually a different system that used SEI Level 5.

Copy Editors Needed!

I have a few articles which have already been translated, but are waiting for someone to edit them and do a final check before I post them.

If you would like to volunteer to edit some articles in any of these languages, please let me know: Farsi, Hungarian, Italian,  Portuguese (Portugal), Ukrainian.

Jakob Nielsen on Offshore Usability: “To save costs, some companies are outsourcing Web projects to countries with cheap labor. Unfortunately, these countries lack strong usability traditions and their developers have limited access — if any — to good usability data from the target users.”

Offshore usability is a specific case of the general “offshore design” problem. Put simply, software teams are not successful when design or management are done in a different physical location than programming. Once I actually had a job where I was in New York, my direct manager was in Singapore, his manager was in Hyderabad, and if I needed any management input I had literally no choice but to go to the CEO because at least he was awake during the same hours as I was. You can’t get things done like this. A good project team relies on hundreds of small interactions a day. Here in the Fog Creek offices, we have 10 small conversations about FogBUGZ 3.0 development every day.

What I don’t understand is people who think it’s OK to move the developers ten time zones away from their managers and expect good results. Those same people would scream bloody murder if you told them that you were going to send the whole management team to Bangalore or Beijing.

John Robb has an interesting perspective on trust-based, targetted advertising based on his experiences at Gomez during the heady days of the Internet gold rush.

Nobody believes advertisements any more. There’s a lot of evidence that advertising just doesn’t work, no matter how targetted, so if you have a product to sell you have no choice but to get into the editorial side, where consumers’ defenses are lowered. Product placements are one example of this.

There is an unfortunate tragedy of the commons, here. When advertising first rose to prominence, advertisements did work. We hadn’t built up our immunities yet. As more and more advertisers used the opportunity of the medium to lie, we learned not to trust advertisements. But we still trust editorial. And once editorial gets polluted by desperate marketers using PR instead of advertising to promote their message, nobody will believe it either.

We’re trying to decide if FogBUGZ 3.0 should support custom fields. Historically, I am opposed to custom fields in principle, because they get abused. People add so many fields to their bug databases to capture everything they think might be important that entering a bug is like applying to Harvard. End result: people don’t enter bugs, which is much, much worse than not capturing all that information. You can always “page fault” to get the information if the original report forgot it. Rather than having a field in every bug where you enter the version numbers of every DLL on your machine (this is an actual customer request), information which is likely to be relevant only for a tiny percentage of bugs, why not just have the programmer-assignee look at the bug first, and if they think it might be dll-version-related, only then bounce the bug back to the originator asking for the DLL info? Similarly, it’s always tempting to add a field in which you ask for the OS version in which the bug occurred. This sounds logical, but trust me: adding fields like this is guaranteed to do one thing and one thing only: reduce the number of bug reports that get into the system in the first place. Only a small percentage of bugs are really OS dependant and you can always include that info in the text description of the bug if it happens to be relevant. (But then how do you search for, say, all bugs which only happen on Windows 98SE? Aha! You can’t. Ever. Even with the custom field. Because not every bug has been regressed on every version of every operating system, so this search doesn’t make sense in the first place. The info wasn’t captured. Do a full text search for 98SE and you’ll find some of them. Life is imperfect.)

Life would be more perfect if every bug report included megabytes of information — a complete dump of every byte on the hard drive and in RAM on the computer in question and while you’re at it, a photograph of the tester’s workspace. But the goal of a bug tracking database is to keep track of bugs, which, all else being equal, takes priority over making it easy to find them. I have heard countless stories of development teams where the bug tracking package was so high-ceremony that people were afraid to enter bugs in the system, because they didn’t know what all those fields were. The real bug-“tracking” happened in email, post-its, and hallway conversations. Great.

A pretty common question we get on the customer service line is, “does FogBUGZ support custom fields?” Rather than giving our usual answer (“no. on purpose.”) over the last few weeks I’ve been saying, “can you please tell me what fields you would need? We’re trying to decide whether to implement that feature in 3.0 and we want to know why people need it.” The interesting thing is, almost all of the fields people ask for are already in FogBUGZ, and the other ones, in my educated opinion, shouldn’t be fields. And in fact, our existing customers are certainly happy without custom fields. One of our biggest site licenses was sold to a semiconductor company, and I myself wanted to add a custom field for them to keep track of versions of the circuit design, but I didn’t, and they never needed it (even though they had been keeping track of it with the old bug tracking package which had custom fields), and they are happy and keep buying more site licenses.

But the dilemma for us is that many customers are evaluating bug tracking software and they consider the lack of custom fields to be a major weakness in our product. “Gosh, even Filemaker has custom fields.” Righto. It’s true. And who am I to tell my customers they are wrong? One person who I was talking to yesterday would have used a custom field for something that we already have a built-in field for. This would have made their database confusing and inconsistent and would have definitely caused more problems than it solved. But it’s still rude of me to tell customers that we don’t have that feature for their own good, even though it usually is, and we’re losing some sales because of it.

Sigh. I guess we could have a custom fields feature but hide it and make it so hard to use that people don’t use it. At least we won’t lose any sales 🙂

9/11 In Memoriam.

Daniel Berlinger has noticed that Mac software shops are starting to move to OS X-only development. This makes sense, for two reasons. First, most people who pay for software have new computers. So while OS X may only have a small fraction of the installed base, it has the majority of the population of people who are opening their wallets. Second, if OS X isn’t successful, the Mac is over. It’s not like System 9 is getting any more popular.

Then again, there are very few conditions under which it is actually the right business decision to develop software for the Macintosh. Developing for the Mac is not a whole lot different than creating a web site that only works on Netscape. (Given the market share of Macs (about 3.5%) and the market share of Netscape (about 3.4%), that is not a silly comparison.)

Robb Beal wrote: “Try this test. Go to a venture firm, angel, or big company with a Mac OS X product/concept/prototype. Do they consider the fact that it’s a Mac application a net plus? (No.)” Well duh. Your product would have to appeal to 25 times more Mac users [as a percentage] than Windows users just to break even. In other words, if your Windows product appeals to 1 in 100 Windows users, you have to appeal to 25 in 100 Mac users to make the same amount of money.

Now, you may want to make an emotional appeal to developing for the Mac. That’s fine. If you like Macs and you’re doing it for fun, more power to ya.

But as long as we’re talking investment, you have to tell me why you’re going to get 25 times as many users. Maybe there’s less competition in your category on the Mac; maybe you’re in a niche like graphics where it seems like Macs dominate (they don’t, it just seems that way because the elite graphics people in big American cities use Macs); maybe your product can’t sell to mixed environments unless it runs everywhere. But if you want to make an investment in Mac software be prepared to demonstrate how you’re going to overcome that magic 25 multiplier.

A bunch of people asked me what I meant when I referred to Rick Chapman’s upcoming book on stupidity in the software industry. The book has not been published yet; I just read his manuscript so that I can write the foreword (being something of a stupidity maven, myself). As soon as it comes out you can be sure I’ll let you know, since it’s a great book.

I keep forgetting to link to TopCoder.com. What a cool idea, online programming competitions!

Ray Ozzie replies.

Another nail in the frequently-nailed coffin of Napster.  Here’s something I don’t understand. Ignore the Napster legal history for a moment. Let’s talk about software development. About two years ago, Napster and Bertlesmann announced that they would deliver a version of Napster that would charge money and only provide music legally. Now, it seems like they ran out of money before they could even deliver that. What I don’t understand, exactly, is why they couldn’t build this thing that sells Bertlesmann music with two whole years of work and a whole team of developers? When Fanning had built the original thing in three months? (Then again, the story here sounds incredibly familiar. One guy builds version 1 in a few months and then a team of 15 can’t build version 2 for years and years. Tell me you haven’t seen that movie before.)