Sunday, February 24, 2008

Customers are the most honest people you'll ever meet

My first startup was Preemptive Solutions, Inc., where apart from other activities, I turned the core of my Ph.D. dissertation into a Java bytecode optimizer called DashO. It was named after the javac (and gcc) command line option "-O". I thought it was a dashingly clever name at the time (The idea of "hypen-O" seemed nowhere near as cool).

In hindsight, it was a pretty dubious product idea. Developer tools are a tough business. For all the talk of application performance, people don't often pay for it except in the form of bigger hardware. However, as I came close to completion of the code, the idea morphed itself into something much more viable (as startup ideas are wont to do).

Turns out people weren't willing to pay for performance so much, but at the time, Java applets were taking off. And people were dying on applet download times - making applets smaller became a component of business success. A wonderful side effect of my code optimizer was that it also made code smaller. And with a few added features focusing on that, it made Java applications amazingly smaller than the original. Getting a 50% size reduction (mostly via bytecode manipulation, dead class/method removal, and identifier renaming) wasn't unusual. The product was a hit.

As time went on, applets gave way to Java ME - and source code protection was added later - but the idea of small code prevailed. If your Java ME application doesn't fit on the phone, then you really can't expect to get many users.

While writing that code, I had just finished writing the book Java Primer Plus. Honestly, I thought I was a pretty crackshot Java programmer. As time went on, of course I kept learning. There really is a teenager phase in your lifecycle of learning a language. It's a distinct point where you're convinced that you know it all. As Mark Twain said (summarizing), "When I was a boy of 14, my father was so ignorant I could hardly stand to have the old man around. But when I got to be 21, I was astonished at how much the old man had learned in seven years."

In your post-teenager phase, the biggest thing you often learn is how little you actually knew. Thereafter, coding in the language moves from your brain to your brain-stem and finally to your fingers. I can palpably tell the difference. When I code in a language I've done for more than a few years, I don't have to think about the language at all. My brain does things like data structures, concurrency, and algorithms whereas my fingers do the coding.

It was about the time that DashO made its first million in sales that I really sat down and realized how bad the underlying code was designed. My deficiency in Java when I had first coded the app was now obvious to me throughout the code base. The first thing that struck me was that I had made nearly every method in the damn application static. Talk about a C programmer moving to Java. I remember being convinced it would make things run faster (of course I probably never tested that given I was so sure of myself).

I remember thinking that it almost seemed wrong that such bad code could be so successful. But it was. To be fair it was quite bug free and actually did do what it advertised. Its success was that it consistently brought value to its users - and they were more than willing to pay for that. They really didn't care if every method was static or if I was bubble sorting my way until Tuesday - if it shrunk their J2ME application by 50% that was good enough for them.

Customers are honest. They vote with their credit cards and their attention. I've heard of more than a few startup launches be delayed because they "needed to rewrite some core pieces". Clearly, rewriting your code is essential at times, but at other times I've seen it be a feel-good technical decision and a downright bad business one. Quite often its like polishing your car's engine. It might make you feel better, but the car won't run any different and no one else is really going to notice when you drive down the street. Simple moral is that if you're going to delay your product launch because of a rewrite, just be sure its worth it. Delays have been known to be fatal.

These days, I don't get to visit Preemptive as often as I'd like but I'm happy to report it is a very successful 25+ person company, still growing, and is moving into some very exciting (to me anyway) new product directions. A new set of developers work on DashO and it continues to grow in both features and users (and happily, they've evolved the code-base into something far more reasonable to maintain). I'm still amazed at how well the application sells, but I guess I shouldn't be. As long as DashO keeps bringing more and more value to its customers, it will remain a successful product. And things like where-you-went-to-school or how static you decided to code your methods be damned. Value is value.

1 comment:

Indeed, the DashO codebase is not the first or the last I've seen like this. It may not have been pretty under the hood, but it did what the customer wanted, and that was key. It's certainly good to have solid maintainable code, but the bottom line is that it has to meet the customer's needs.