Borrow My Brain

A while back I wrote a game called Wolf5K, which was a re-creation of the original first-person shooter Wolfenstein 3D in only 5K of Javascript. There’s an online tutorial about how this was accomplished. It used an archaic 1-bit image type called XBM, originally designed for the X Window System, to dynamically generate bitmap images via Javascript.

I’ve just discovered that XBM images no longer work in Windows XP. There apparently was a recent security update that removed support for this image type, and it won’t be included in IE7. This means that the game will no longer work, unless there’s a way around this restriction. I’d like to keep the game up, so if you have any ideas, please contact me.

Last night there was a NextNY discussion on the role of business development for Web 2.0 focusing on the opportunities for bringing in traffic and revenues through crawling, APIs, widgets, mashups, and the like. The conclusion was that, while you still need to schmooze and make deals, these new tools are a powerful way to get others to use your service.

Among the topics discussed were mashup sites, sites that combine these features in new and creative ways, and whether they could ever be standalone businesses. Right now, they’re mainly “FNAC — Feature Not a Company”. Things like the New York City Subway Smell Map. Cool, but not businesses.

But there’s something to be said for building a new product out of other people’s code. It’s done all the time: the applications you run on your Windows desktop are basically just ‘mashups’ of the Windows APIs. Why can’t we do the same thing on the Web? What would it take to allow you to put together parts of other companies’ businesses, to create something more than the sum of its parts? And what do you need to pay attention to now if you’re a startup using APIs as part of your business development strategy?

• Reliability. When you call the sprintf function, you can be pretty sure it’s going to be there, ready and able to sprintf for you. It won’t be down for maintenance, hacked, or gone out of business. All of which can happen if you’re making an API call to another website.
• Trust. Developers must have faith they won’t be kicked off or blocked from the API, as MySpace has done.
• A not-free option. If you’re going to rely on a web service to run your business, you’ll want some kind of contract or subscription. Free services are fine for experimenting, but not when you’re using a service in a serious way. You’ll need some kind of service level guarantee and a real person you can call up when something goes wrong.
• Predictable charges. Right now, you can buy an ActiveX control or PHP script and pretty much know how much it’ll cost. It’s usually a flat upfront chanrge. But charging for web services can be unpredictable. What happens once your site takes off, and the service provider figures out you’re making a lot of money? Up goes the subscription fee!
• Predictable upgrades. If you’re mashing up another site’s API and they decide to upgrade, it could break your site. This isn’t as much of a problem with desktop operating systems, because upgrades are fewer and announced far ahead of time, and vendors usually take great pains not to break old applications. Not so with Web APIs. It’s best if the old versions of the API remain available for a while for sites that can’t adjust immediately.
• Speed. HTTP is not fast. It takes a long time to make multiple HTTP API calls in the background.

If you’re creating a site with an API, you have control over some of these issues. Will you offer your users a Pro version of the API, predictable upgrades, a real person to talk to, and a guarantee that you won’t kick them off, or will you offer only a free API, make it impossible to talk to a real person, and kick off developers whenever you feel like it? , Companies like Microsoft need to treat developers well to get them to write for their platform. The same goes for companies create ecosystems around their Web APIs.

If you want to use APIs, mashups and widgets as part of your business development strategy, treat your developers well.

Thanks to this new Web 2.0 bubble, nearly ever week or so I get contacted by a startup or small company looking for someone like me to join up. I’m always happy to give them advice. Inevitably, one of their biggest worries is what programming language to use. “Should I use PHP, Python or Ruby?” they ask, as if their choice of programming platform is the sole factor that determines the ultimate outcome of their business.

Well, I’m going to give the definitive answer to the question, “Does the programming language matter?” Yes and No.

• Yes, because some languages are much more productive than others. What could take days to program in a strongly-typed, compiled language like Java or C# could be done in an afternoon in Ruby or PHP. Don’t get me going about J2EE, which you shouldn’t be using unless you know exactly why you need it.
• Yes, because different languages promote different work styles and cultures, and will make it easier or more difficult for you to work together and find additional programmers. As an example, PHP is designed with minimal restrictions, promotes a free-for-all programming style, and everyone in every country around the world seems to know it. Ruby, especially with Rails, has more structure and elegance, making it easier to write maintainable code, but it’s harder to find people.
• Yes, because some languages make it easy to make quick updates in response to your customers, and some languages require a lot more work, planning, and ceremony to do anything new.
• Yes, because some programming environments are still evolving while others are more mature, and you may want to use a less cutting-edge language just so you can worry less about the technology and spend more time on the business side. For example, Lisp can be extremely cool and productive, but getting it connected to a webserver and getting set up with wide array of libraries isn’t an easy, out-of-the-box process the way it is with C# or PHP, so you may end up spending a lot of time on low-level tech issues, rather than working on areas that matter more.
• Yes, if it’s an enterprise product you plan to sell to businesses to install on their servers. In this case, code it in the language your target market’s iT departments require (usually Java or C#).
• No, because there’s so much more to making your business a success than whipping up some code. You’ve got to have a good business model. You’ve got to find good people. You’ve got to do marketing, customer service, and create a well-designed product. The initial build of the site is going to be just a small percentage of all the things you need to do right.
• No, because bad programmers can produce bad code in any language. There’s no silver bullet that prevents untalented or indifferent people from generating garbage.
• No, because the system architecture matters more. If you design an overly complex architecture, or one that’s unwieldy, or slow, you’ll produce an unmaintainable, unwieldy, slow site. Look at Friendster as an example. The initial build of Friendster was done in Java, and was incredibly slow. Could Java have handled a site like Friendster? Sure. I don’t have first hand access to what was under the hood at Friendster, but I can’t imagine it was clean, elegant, or well-thought-out. The language that a system design is expressed in doesn’t make a difference if the overall design is poor.

Ultimately, none of your customers care what’s under the hood, as long as it works and does a good job for them. So choose what works best for your particular situation, and entrust it to the most talented and motivated people you can.

One of my sites, a version of Wolfenstein 3D written in 5K of Javascript, was picked up by Digg the other day. I wrote this game about 3 years ago, so I’m not sure how people found it, but the traffic has sure picked up, from about 1000 pageviews a day to 75,000.