Category: Business

Next Big Language = JavaScript

There’s a lot of buzz about Steve Yegge’s “port” of Rails to JavaScript, and Steve has now provided (in his funny, self-deprecating style) the background of how it came to be. He doesn’t quite say it explicitly in this post, but I think it reveals that the “Next Big Language” he has been hinting at is JavaScript.

I (mostly) agree:

JavaScript is in nearly every browser, including tiny ones (like the one in my BlackBerry Pearl). It may be the single most widely available language today.

Because of the above, an enormous population of JavaScript programmers (though sometimes of dubious skill) has emerged.

Starting with Java 6 it’s “in the box” there also. To me, this makes it the likely winner, by a wide margin, for a dynamic language to be used at Java shops or inside Java projects. Being “in the box” is a powerful advantage, one which the many other contenders will have a hard time overcoming.

Adobe’s new JavaScript virtual machine implementation, which they handed over to Mozilla as “Tamarin”, sounds like it will boost JavaScript performance great, making it good enough for a very wide variety of projects.

JavasScript uses curly braces, like the last few Big Languages.

Like Java, C, C++, etc., JavaScript has specs and multiple competing, complete, current, high quality implementations. This, to me, is a big advantage over Ruby, Python, and other currently popular dynamic languages. Of course there is plenty of room in the industry for these language to thrive also, I am not saying any of them will go away; we use Python with great results and expect to keep doing so.
Mark Volkmann initially thought I was nuts to predict JavaScript as a winner but came around a few month later (and said so in a user group talk).

In a project at work, we’d adopted JavaScript as our plugin extension language for user-customizable rules (billing rules, etc.). I’d have chosen Lua (as I did for another project), but there are at least 1000x as many JavaScript programs out there. So far it has worked very well. If we had it to do over we might implement far more of the project in JavaScript.

However, there are a few reasons why I only “mostly” agree:

First, with JavaScript there isn’t a good way to avoid shipping source code. Sure, you an obfuscate JavaScript with various tools, but the results remains far for amenable to readable-source recovery than in a more traditionally compiled language. For open source projects this is no big deal, but there are also many worthwhile businesses and projects which depend on proprietary, not open software (including most of our projects), and it’s not year clear that obfuscation is sufficient protection. (Update in reply to a comment below: This matters even for server-side software, because some of us create and sell software products for other people to run on their servers.)

Second, at the moment JavaScript appears to lack a module system, without which it’s painful to build large systems. I expect an upcoming language version will address this.

BaseJumpr: BaseCamp -> ActiveCollab

BaseJumpr has a fascinating service offering: they export your data from your Basecamp account, producing a set of files ready to import in to ActiveCollab, the open source Basecamp-sorta-clone-like-program. They then, if you wish to buy their hosting service, create an instance of ActiveCollab for you and import your data there. (They host your file storage on Amazon S3, so they can easily offer ample storage.)

I find this very appealing, yet also a bit impolite; 37Signals has built a good business on Basecamp, the ActiveCollab team has created (well, is creating) an open source clone, while BaseJumpr did neither of these things yet stands to gain (at 37s’s expense). However, I doubt BaseJumpr is a significant threat or bother to 37Signals because most users interested in the open source ActiveCollab would likely not be using the Basecamp service in the first place.

Speaking of Basecamp, I am fascinated by 37Signals’ business success with such a simple (but well executed) application. I tried out Basecamp myself, and found it far too feature-anemic for my taste; but I could readily see its appeal and simplicity, and it has me thinking about the merit of building a business in a focussed niche, intentionally and happily excluding the potential customers outside it.

Update in 2009: BaseJumpr doesn’t appear to exist any more. I am curious how it worked out.

Selling your Software as a Service: Notes and Audio

At the St. Louis Code Camp on May 5, 2007, I gave a talk on Selling Your Software as a Service, in which I discussed our experiences selling a complex (Java) “enterprise” application in that manner. The room was much more crowded than I expected, it was exciting to have an eager group. As with all my recent talks, I used a handout instead of slides. You can download a PDF of the handout (one page, one side), or read the contents below.

The 1 hour audio recording (Olympus WS-100 digital voice recorder, Audacity cleanup) is available here: SAASTalk.mp3

A transcript of the talk is available. In the talk I mentioned Paul Graham’s The Other Road Ahead, which is shorter and easier to read the my talk transcript.

A couple of people at Code Camp asked if I could come give a similar talk in-house at their firms. Yes – please contact me with the contact form to arrange a date.

The handout contents follow.

Continue reading “Selling your Software as a Service: Notes and Audio”

St. Louis Code Camp, May 5 2007

It’s time for the second (annual) St. Lous Code Camp on May 5, 2007. There’s no actual camping (unlike some other ___ camps out there), just one day of sessions. Think of it as a mini-conference. See Brian’s announcement for more details. If you’ve been thinking of giving user group talks and never gotten around to it, Code Camp is a great place to start.

I’m in for two sessions this year, assuming enough slots are available for both: Continue reading “St. Louis Code Camp, May 5 2007”

Dear PayPal, My Thoughts Do Not Fit In 40 Characters

I recently closed a PayPal account. During the closing process, and again thereafter, I was surveyed as to why I closed the account. Predictably, these surveys offered a few choices for why I didn’t want the account, with only a tiny field if I wanted to explain in more detail why I closed it. I picked the choices that were closest to my actual reasons; but they really were not close at all.

(Kyle’s Business Tip of The Day: You really aren’t helping yourself, or your customers, if you set up feedback mechanisms that only allow you to hear messages you want to hear.)

So here is my reason to be wary of PayPal: I can start with a credit card, but I won’t get far that way; to do anything useful with PayPal, I need to grant them full access to my bank account. At every bank I’ve ever used, there is no mechanism for partial access. Once a vendor is in, there is nothing I can do to stop them from withdrawing all my money. For example, there is no way to say “this vendor can pull out up to $N in a month, and no more”; at most I can get, in some cases, notification of transactions. This is unsafe: fraudulent access to my PayPal account, or a bug at PayPal, could empty my bank account.

There is no “push” way to get money in to PayPal. An example of Push would be that I mail them a check, they deposit it, they wait N days for it to clear, then they put the money in my PayPal account. Push is safe; it avoid granting them “Pull” access to my accounts.

These issues are not solely PayPal’s, rather they are caused by the broken bank payment system here in the U.S.; but it is clearly PayPal’s choice to not provide a workaround in the form of a “push” deposit mechanism.

(European readers will probably find all this silly; apparently in that part of the world there are “push” mechanisms to transfer money electronically, and for all I know PayPal may work like that European customers.)

How Not To Shoot Yourself in the Foot with Change Control

As anyone with experience in a large firm knows, change control procedures (and “change control boards”) are a common fixture. Change control mechanisms (such as requiring extensive documentation, signatures, meetings, checklists, approvals, etc.) have obvious benefits, but they also add inertia, increasing the cost of change. This refers to both dollar costs (meetings aren’t free), and to inaction by employees who find it not worth the effort to a desirable change approved. The net result can be that bad procedures, features, documents, etc. stay in place, to the detriment of the organization.

Thus, I will frame Kyle’s Guideline on Change Control:

The “weight” of your change control system should be, at most, proportional to how good your product / processes are. If things are really bad, fix them *first*, while it’s easy, and then *after* that add in the obstacles to change.

Unfortunately, this ubiquitous alternative procedure:

  1. Notice things are bad.
  2. Add change control mechanisms that make it hard to fix them.
  3. Avoid changing the things that are bad.

is actively stupid. (Of course, maybe your problem is that things change too much… in that case, the first thing to change, is to make it harder to change.)