“Modernize”

In a vintage computing group, someone posted a picture of a terminal in use at a modern bookstore that’s still using the same infrastructure as they have for decades, and someone replied saying that while from a retrocomputing perspective it was cool, as a business they need to “modernize!” This was my reply…

It’s my understanding that a major US tire and oil change chain used HP 3000—Hewlett-Packard’s minicomputer and mainframe platform—for decades, right up until HP cancelled it out from under them, and only switched away from it due to the promised end of support. That is to say, they’d be using it now if HPe still supported it today.

My understanding is that their systems were built using native technologies on MPE, the HP mini/mainframe OS, like the IMAGE database, COBOL for business logic, and MPE’s native forms package. They went through a number of transitions from HP’s 16-bit mainframe architecture to 32-bit and then 64-bit PA-RISC, from using terminal concentrators in stores connected to a district mini over packet data to using a small mini at each store with store-and-forward via a modem to the regional mini (and on up) and finally to live connections over VPN via local ISPs, and from not having any direct customer access except by calling someone at a specific store to having customer access via the corporate web site.

So tell me, why should they have switched away if their hand wasn’t forced by HP? Keep in mind that they maintained and enhanced the same applications for decades to accommodate changes in technology, regulations, and expectations, and by all accounts everything was straightforward to use, fast, and worked well. What would be in it for the company and the people working in the shops to rewrite everything regularly for the platform du jour? I’ll grant that their development staff wasn’t padding their résumés with the latest webshit, but why would that actually matter?

“Astroturfing” Is Fraud, Prosecute It

I read something tonight about how some telecom lobbies were sending automated “public comments” to regulators as if they were actual individuals represented by the government the regulatory agencies belonged to, and are starting to switch to LLM-generated text to try to evade detection.

How is that not fraud? (Wire fraud if electronic, mail fraud if mailed?) It’s known misrepresentation for illicit gain. It should be an open-and-shut fraud prosecution at minimum, an open-and-shut RICO prosecution for any organization that engages in this practice repeatedly, and an open-and-shut conspiracy (and possibly antitrust) prosecution for any group of organizations coordinating this activity.

Want to know why shit keeps getting worse in our society? Not pursuing things like this is why.

DDJ vs. Backyard Poultry

Eric Sink has a post talking about the sad state of developer publishing, specifically discussing the declining readership of the venerable developer magazine Dr. Dobb’s Journal, as compared to that mainstay of American newsstands Backyard Poultry.

After reading the article and the replies, I just had to throw in my two cents about magazine publishing and why “1% of the US population are software developers, so there should be a huge market for development magazines.”

It’s a significant mistake to think that the reader is the target and that the magazine is the product.

It is actually the aggregate readership that is the product, and the advertisers who are the target. That is, unless the magazine takes no advertising and is entirely supported by its subscribers.

This was driven home to me recently when I bought the recent “eInk Flashing Cover” issue of Esquire. I had never read Esquire before, so in addition to checking out the cool hardware on the cover, I started trying to read it. It was way more full of ads than Wired ever was — even in the days when Suck famously disassembled Wired 3.09 to remove the ads.

Furthermore, its advertisers were all very high-end. Thus I wasn’t that surprised when I saw that the price on the subscription card for a year of Esquire was well under $1/issue.

So if Dr. Dobb’s Journal is circling the drain, it’s not the current readership that’s to be blamed, or the Internet. It’s the lack of advertisers interested in reaching that readership, or the magazine’s ability to reach a readership that is interesting to a better-paying tier of advertisers.

Copyright canonical form

One thing that’s nagged at me lately has been the series of applications I’ve seen lately with copyright statements that appear to be from the Bizarro universe. I don’t mean that they have weird license restrictions; rather, they have a copyright statement in their standard About panel that’s formatted strangely. It’s a minor pet peeve to be sure, but it’s a simple thing to get right and getting it wrong looks silly.

Note that the following is not legal advice on asserting or protecting your copyright — you’ll have to go to a lawyer for that — it’s just a suggestion on how to concisely format your statement that your work is covered under copyright.

In a Cocoa application, the standard About panel will show the copyright statement specified under the NSHumanReadableCopyright of its Info.plist file. This should generally be of the form

> Copyright © «YEARS» «HOLDERS». All rights reserved.

where «YEARS» represents the individual year, set of years, or range of years during which the application was authored and «HOLDERS» represent the authors of the application.

Thus if I were to start writing an application in 2007 and finish it in 2008, I would put

> Copyright © 2007–2008 Chris Hanson. All rights reserved.

in the NSHumanReadableCopyright key of its Info.plist file. (Yes, that’s an en-dash between the years, option-hyphen gets you one.) It wouldn’t have the year at the end, or random commas after things, or random abbreviations. Just one simple statement.

Someday I’ll figure out how to add

> Copyright © 2002–2008 Chris Hanson. All rights reserved.

to the bottom of my weblog, too. Hopefully in such a way that I can actually update it easily when the year rolls over…

“Enterprise” thought leadership?

David Heinemeier Hansson, creator of Rails at 37signals, takes James McGovern — some Java/J2EE author — to task for his über-lame rant against Ruby in the Enterprise in a great post titled Boy, is James McGovern enterprise or what!

> So by Enterprise, Architect, and Enterprise Architect standards, this gent must be the top of the pop. Thus, allow me to make this perfectly clear: I would be as happy as a clam never to write a single line of software that guys like James McGovern found worthy of The Enterprise.

> If Ruby, Rails, and the rest of the dynamic gang we’re lumped together to represent, is not now, nor ever, McGovern Enterprise Readyâ„¢, I say hallelujah! Heck, I’ll repeat that in slow motion just to underscore my excitement: HAL-LE-LU-JAH!

> With that out of the way, we’re faced with a more serious problem. How do we fork the word enterprise? The capitalized version has obviously been hijacked by McGovern and his like-minded to mean something that is synonymous with hurt and pain and torment.

Indeed, McGovern’s rant reads more like a parody of a rant than the real thing:

> 13\. Lets say there is a sixteen week project and the productivity stuff was true and Ruby could save me an entire three weeks which would be significant. Since Ruby is a new vendor and not represented by existing vendors I already do business with, do you think that I will spend more than three weeks in just negotiating the contract?

Yes, because there is some vendor out there named “Ruby that you need to sign a contract with before you can begin a project.

Despite his claims to be agile, McGovern obviously doesn’t know the first thing about agile development. People come first, sure, but agile development doesn’t say that tools aren’t important. Not using good tools makes it harder for good people to do good work.

That’s why I love developing software for Mac OS X and why I love helping people develop software on Mac OS X: We have great tools like Cocoa, Core Data, Interface Builder, OCUnit, WebObjects, and Xcode, and these can be used by great developers to do great things.

Joel Spolsky’s Bionic Office

In the latest installment of Joel on Software, Joel talks about his new office.

I like a lot of what he’s done with it. It’s largely the kind of space I’d design. I might or might not have private offices, now that I’m starting to buy into XP more, but I definitely like a lot of what I see.

This amused me, though:

> The monthly rent for our offices, when fully occupied, will run
> about $700 per employee. The build-out was done on budget and paid
> for almost entirely by the landlord. I suspect that $700 per person
> is on the high side for software developers throughout the world,
> but if it means we can hire from the 99.9 percentile instead of the
> 99 percentile, it’ll be worth it.

I strongly expect it’s actually on the low side, at least in large corporations.

Joel says each employee is getting about 425 rentable square feet, at a cost of $700 per month. That’s about $20 per square foot per year. That’s low for Class A office space, at least in some markets. Like, say, Schaumburg.

(Though with 53,255 square feet available in Zurich II, and a couple of newly-built office towers standing vacant, and a bunch of other Class A space vacant, perhaps Schaumburg rents have come down since I last looked in 2001…)

I knew it wasn’t all puppies and rainbows!

[Joel on Software][1], “[Local Optimization, or, The Trouble with Dell][2]”

> Unfortunately, the dirty little secret about Dell is that all they have
> really done is push the pain of inventory up to their suppliers and down
> to their customers. Their suppliers end up building big warehouses right
> next to the Dell plants where they keep the inventory, which gets
> reflected in the cost of the goods that Dell consumes. And every time
> there’s a little hiccup in supplies, Dell customers just don’t get their
> products.

This isn’t the only problem with Dell. Their other big problem is that they’re constantly starting price wars, which keep driving down their margins further and further, which makes not only their products but all of their competitors’ products crappier and crappier. It also fuels the delusion that price is the only factor that customers use when selecting a supplier. It’s a race to the bottom that nobody wins.

[1]: http://www.joelonsoftware.com/
[2]: http://www.joelonsoftware.com/news/20030115.html

Platform Futures

On Windows, many developers seem to want to run as fast as possible away from Microsoft Visual C++ and embrace Microsoft’s C# and .NET platform for new development. Most Windows developers that I’ve seen seem downright enthusiastic about these technologies. It’s disconcerting; I’m not used to seeing Windows developers (or users) be enthusiastic about their platform.

On the Mac, many developers are trying to hold onto C++ and Carbon for as long as they can, even for new development. A new Mac developer on the Carbon list actually said he wished Apple had a C++ framework that used MFC-like “message maps” for Mac OS X-only Carbon development “to make it easier to build software fast!” (Paraphrased.) And Metrowerks is spending money & time building a next-generation C++ PowerPlant framework for Mac OS X-only Carbon development! And some developers keep on Apple’s case to try and maintain feature parity between Carbon and Cocoa.

Fortunately, Apple isn’t giving in to them as much as they might think. For instance, WebKit has a Carbon wrapper, but it’s just a wrapper; WebView is really a Cocoa framework and if you want to extend it you’re going to have to use Cocoa. The Cocoa Controller layer is only really possible to do with a rich dynamic runtime; it’ll never make it to Carbon. You can only build screen savers using Cocoa and Objective-C. You can only build preference panes using Cocoa and Objective-C. Virtually all new applications coming out of Apple are built using Cocoa and Objective-C.

(Keynote, SoundTrack, LiveType, iCal, iPhoto, iSync, iChat AV, Safari… Final Cut and Logic don’t count, since they ware originally developed for the traditional Mac OS and thus aren’t new. Neither does Shake, since it was originally developed for Irix and X11 — though it wouldn’t surprise me at all to see it rearchitected as a Cocoa application in the next couple of years.)

The future of development on Windows is C# and .NET. This has been clear since Microsoft first released .NET, and it’s especially clear in light of the latest PDC and Longhorn.

The future of development on the Mac is Objective-C and Cocoa. This has been clear ever since Apple bought NeXT, and it’s especially clear in light of the latest WWDC and Panther.

Deal with it.

Joel still doesn’t get it

A couple days ago in [Joel on Software][1], Joel claimed that in order for it to make economic sense to develop a Macintosh product, you had to be able to sell *25 times as many* copies as you would a Windows product.

**Bullshit.**

First of all, you can’t just assume that the relative market sizes between the Macintosh and Windows are accurately represented by their market shares. This is partly because market share is a measurement of new computer sales rather than installed base, and partly because there are broad swaths of each market that *aren’t* in the market for your application.

Secondly, it presumes that it costs the same to develop and bring to market a Macintosh product as it does to develop a Windows product. It doesn’t. It costs substantially less. The development tools on Mac OS X are the best on any platform, and speed development significantly; very small teams can create high-end applications in very short timeframes. There is a far smaller test matrix when you’re dealing with Macintosh software, and within that matrix there are far fewer bizarre interactions. There is significantly less competition in the Macintosh market, so you don’t have to spend as much on marketing and promotion of your product. Consumers also don’t have to wade through nearly as much complete garbage to discover the good applications.

Finally, you have to consider post-sales support. The support load presented by Macintosh software is also far lower than for the typical Windows product. This means lower post-sales costs, which means you get to keep more of the revenue generated by the product.

All this adds up to an excellent ROI story for Mac OS X development. You may still have the potential for a higher return on a Windows product, but you’ll also have substantially higher costs, a longer development timeline, and correspondingly greater project risk. All sides need to be weighed before deciding whether it’s worth pursuing one platform or another – you can’t just do a couple bogus back-of-the envelope calculations and decide you need to sell 25 times as many units to make Macintosh development worthwhile.

[1]: http://www.joelonsoftware.com/news/20020910.html