The Young Man's Business Model

I've had and idea bouncing around in my head for awhile that randomly came together recently. And given I have a blog, I thought I'd write it down. This idea came from 3 experiences I've had - and here they are:

Mini-story #1:

In my early 20's I pretty much did 2 things. Ride motorcycles and code. Oh, and given my motorcycles were always sort of junky and I beat the snot out of them, I spent plenty of time fixing motorcycles too - I guess that's 3 things then. (If you think I forgot dating or went to bars or some such - nope. We're good. 3 things).

Every now and then we needed an "old man" (like in his 40's or something) to help us fix something when it was beyond our self-taught abilities. Now when I say "old man" here and throughout this article, I don't necessarily mean "old" (and I don't necessarily mean "man") - I mean "experienced". Experienced at whatever I'm interested in at the time - or more specifically, experienced at what I wasn't experienced in at the time.

And as far as fixing motorcycles, what struck me was the way he'd go about it.

A rather common case would be something like there being one final screw holding on some engine part that we needed to replace, but it was buried deep inside the engine - i.e. you could barely see it. My first reaction was to wedge a screwdriver in there as far as I could - and see if, with luck, brute force, and karma, I could turn it enough to get it out.

The old guy on the other hand never went this route. He merely looked at it a moment, then immediately started taking off the neighboring easy-to-remove piece of the engine. Once that was off, he then effortlessly put his screwdriver in to remove the now exposed screw. Now mind you, the old-guy's way was my back-up plan - but I was betting that my brash exuberance would payoff in a slightly quicker result. Sometimes it did - sometimes it didn't - and sometimes I broke screwdrivers.

This trade-off of investment up-front versus brute-force hope became so obvious that my friends and I used it as vernacular. "Do you want to try this the 'young man' way or the 'old man' way?". It was surprising how without any further explanation we would know all the precise steps involved in both for whatever situation.

Ok. That was mini-story #1, here's mini-story #2. This is a business story but its actually surprisingly similar to the previous one whether you know it or not.

In 1997, I was writing a Java optimizer (this made a lot of sense when Java was interpreted) called DashO. Somewhere along the line I was introduced to a guy at Adobe, who (I was told) wanted exactly what I was building.

When I finally spoke to him, it turned out that the Adobe guy didn't really want Java optimization at all. What he wanted, was Java application size reduction. It had literally become a show-stopper for what he was developing. He was clear that money wasn't a problem - if I could solve his issue, he was a customer.

Wanting to please my newfound (big-time) customer I said "Sure! I can add that in!". Then I shrewdly secured the Adobe guy as a beta tester. This changed the direction that my product took and added about 2-3 months of development, but given the payoff, it seemed worth it.

About mid-way through those 2-3 months my partners and I had lunch with a veteran ("old man") business guy that for some reason seemed to like us and liked to keep tabs on our progress. As I excitedly told him the story of Adobe waiting anxiously for our product, his reaction wasn't as I expected. I thought he'd be excited for us, but instead he had a look of disappointment on his face.

Me: What? What's wrong - this is awesome - Adobe is our first customer!
Old-guy: So you spoke to Adobe. Directly to an internal guy that's a customer
Me: yeah!
Old-guy: And he has plenty of money to solve his problem.
Me: yeah, tons!
Old-guy: And how much of that money are you going to get in the best case?
Me: erm. um. We'll sell a copy.
Old-guy: Right. A copy. Maybe a few if you're lucky.

Old-guy went on to discuss how that deal should have gone. Adobe had effectively contracted me to build them a product that didn't exist (this was true). It was possible that no other customers would ever want that functionality (possible). Simply put, they had a specific business need, lots of money to solve it, and had hand-picked me to be the solver.

I should have structured the deal as a contracting agreement. Charging on a per-hour basis to develop their product using what we already had as a base. Then, give them a discount rate on the hourly rate in exchange for full-rights to further develop and sell the product as our own. This would have been a 6-figure deal which would have meant a lot at that time. What's worse is you might be thinking that I missed an opportunity to fleece a customer - but I argue you're wrong. In fact, that arrangement would have actually brought more value to the Adobe.

In the old-guy's arrangement, Adobe would have then had a hand in guiding the project and making sure all the features they wanted were in the soup. Not to mention, if I didn't build this for them, they simply would have had to hire someone else to do it - probably spending lots more.

Once in awhile, you have a fucking-duh moment - and for me, this was one. If you're thinking "well obviously" then clearly you've done this before, at that time - I hadn't.

Story 3 - a recent breakfast.

I recently had breakfast with a guy I met at an entrepreneur event. He was CTO of a pretty popular website. When he first described his site, I liked the business model a lot. His site feeded him data that allowed him to refine his real product: pre-built server boxes which he sold to companies that allowed them to use his software internally.

Visions of sugar-plums and multi-million dollar deals immediately started dancing in my head. As he talked, the rolodex in my mind quickly flipped from person to person. I thought of potential customers, potential partners and even maybe people appropriate to join his team. His product was good, and not that he asked me to, but I couldn't help forming a deal network in my head.

I asked about his sales infrastructure. His answer left me wanting but I figured he was probably still fleshing it out (a very hard task). I almost rhetorically asked about the sales cycle. There wasn't one. Now I was getting confused.

As we talked more it became clear that he and his company were following what I'd call the young-man's business model.

He was basically building a (good) product, then laying it out on the web for all to see and hoping to get a million eyeballs. The viewpoint of the business is to get eyeballs, often from things like Digg or Techcrunch, and then figure out how to keep them. And then amazingly often, this really is the step where entrepreneurs have no clue what happens except they are sure the next step is "and then Profit!".

This is an extremely innocent look at business - and in some sense, its the most logical one if you simply have no other avenues.

This model isn't wrong but now to me (who has of course only recently come to rather shocking self-realization that I am... an "old-man" at how I view business) it seems like a business model without considering connections. Deciding to make connections for your business of course isn't conscious. When something happens, the first thing that pops in your head is "Boy, Fred needs to hear about this". And depending on how many Freds you know dictates how often that idea pops in your head. (and of course, the more Freds you know, the more Freds you will know).

My old-man/young-man nomenclature may not be perfect but it might be statistically correct. Its probably safe to say that on average a 30 year old has a generally more business connections than a 20 year old. From there people simply follow business plans as they occur to them.

To me, my friend at breakfast had a sure winner if he had put together a solid sales and marketing infrastructure. His product should have been selling inside 6 figure deals with several month sales cycles. Now clearly, this model doesn't apply to everything. And plenty of new Web 2.5 startups don't fit this mold - but I also think many people underestimate the idea. So far it seems the evolution of all businesses, even something so webby as Facebook eventually becomes about making deals with big partners at least as much as its about eyeballs.

It wasn't so long ago that saying your new startup was monetized by ads wasn't scary. Some companies go right from eyeballs to ads and to sell-out. Thats great work if you can get it. But the number of eyeballs is limited. Its scary to think that, but on the web, we tend to give value away and "make it up on volume". The only problem is you need a hell of a lot of volume to make up for free. And 6 billion people isn't all that many when it comes down to it.

Personally I think web businesses are growing up. The eyeball business model is getting to be like Market street in San Francisco. Everyone is pierced, shaved, screaming, or on fire. They're crying for attention and they have to keep shouting louder than everyone else to get it.

I have plenty of opinions about business models, but to me, the best business model is one that makes your customer money. I didn't say "saves" them money - big difference. Also, its better yet if that customer is a business. You need less businesses as customers to be successful than if you had individuals as customers. A common sweet-spot is BtoBtoC. Supply to businesses that supply to consumers (and of course, make them money).

(I am very sadly not affiliated with Paul Martino's company Aggregate Knowledge if you want an example of a business model that's simply beautiful.)

If you don't have a ton of business experience, try this - think about your next great web app, then imagine the slickest (or sleaziest, your call) old-man salesperson you ever met sitting in front of you. Picture the idea that this guy is really good at persuasion and networking. He can't code, you may not like him, and he wears shoes you wouldn't wear on halloween, but he's good at what he does. Then imagine handing the old-man 5% of the company (I know its hard, try - remember, its just pretend). You need him truly on your side.

If you had access to the old-man and his imaginary immense rolodex of connections. How else could you sell this? What value could you bring to some customers that currently you can't reach?

Your real business model might be hiding like that last screw holding on part of the engine. Despite you stubbornly breaking screwdrivers, you might not get to what you need. It might just be worth asking yourself, "WWTOMD" - What would the old man do?

A few ideas about Negotiation

A good friend of mine asked me for some negotiating tips. This is what I told her. Use, agree, or disagree with them at your own risk.

1) Never put numbers in email. Email lives forever. Numbers are only discussed on phone or in person. Only written down when you're signing the contract.

2) There's an old saying "Whoever puts the number on the table first - loses". In general, this is good fallback advice.

I modify this according to several factors:
a) The less you can predict the outcome, the more likely I let the adversary say the first number. (i.e. revenue-less company valuations are often voodoo - its quite possible your buyer will give a higher number than you ever imagined).
b) The more I need a deal, the quicker I am to say this first number. This sets a tone.
c) Conversely, the less I need a deal - I'm willing to let them show me just how bad they want it. The danger is if they give an extreme lowball, I need to be able to walk.

3) No matter what they offer, ask for more. How forcefully depends on how good the deal already is. If they offer you 10% when you were expecting 3, meekly ask for 12% and back down fast if needed. If they offer 1%, strongly go for 4% and settle for 2.5.

4) Don't answer the phone if they call to discuss the negotiation. You are probably thinking about the chicken mcnuggets you just ate and they have been thinking the last 20mins how the phone negotiation will go. In short - they are prepared, you aren't. Let them goto voicemail. Wait an hour.. spend 10 minutes focusing on the possibilities of the negotiation and call them back. Their mind will be elsewhere now. You'll be ready.

5) Seriously - don't ignore #4. Fifteen seconds is just not enough time to swap your mind into the right context. Besides, information they leave in the voicemail could be advantageous.

6) (Unless you're reading this and you end up negotiating with me - then we might as well set a time in the future to chat otherwise we'll never answer each other's calls.)

7) *Everytime* you sign a contract, you are giving up something. Take a step back and make sure you fully understand all that you are giving up - and all that you are receiving in return. Never sign a contract (or sleep with someone for that matter) because you feel bullied into it.

8) A common negotiating tactic is to put your adversary in an uncomfortable situation. The hope is that the adversary will compromise some just to relieve the discomfort (the more experienced the negotiator, the less likely this is). If you can, reverse the discomfort instead. (This is a class used-car-salesman tactic - think "But you told me yesterday you were going to buy this car!")

Surely negotiation is an art and there's plenty more to it. These ideas are at best a few tricks and tips. Negotiation is a dance - you can't exactly know what you'll have to do until you are forced to react to what your partner does. Thus just like dancing, practice does wonders for your skill.

Writing Java Multithreaded Servers - whats old is new (PDF Slides)

I'm giving another talk tomorrow at the SD West conference:

Here are the slides

Thousands of Threads and Blocking I/O: The Old Way to Write Java Servers Is New Again (and Way Better)


I've encountered some very strong misperceptions in the world that:

1) Java asynchronous NIO has higher throughput than Java IO (false)
It doesn't. It loses by 20-30%. Even with single thread against single thread. If multiple threads enter the equation (and multiple cores) which of course blocking I/O is intent on using - its skews even farther.

2) Thread context switching is expensive (false)
New threading libraries across the board make this negligble. I knew Linux NPTL was fast, but I was quite surprised how well Windows XP did (graphs inside notes).

3) Synchronization is expensive (false, usually)
It is possible for synchronization to be fully optimized away. In cases where it couldn't it did have a cost - however given we have multicore systems now its uncommon to write a fully singly-threaded server (synch or asynch), in other words every server design will pay this cost - but, non-blocking-data-structures ameliorate this cost significantly (again graphs inside show this).

4) Thread per connection servers cannot scale (false)
Thats incorrect at least up to an artificial limit set by JDK 1.6. 15k (or 30k depending on the JVM) threads is really no problem (note linux 2.6 with NPTL using C++ is fully happy with a few hundred-thousand threads running, Java sadly imposes an arbitrary limit). If you need more connections than this (and aren't maxing your CPU or bandwidth) - you can still use blocking IO but must depart from thread-per-connection. Or fall back to NIO.

I'll try to spruce up the benchmarks I used and try to post them. I'd like to point out that writing Java benchmarks is very hard. I spent a great deal of time making sure I warmed up the VM and insured there were no positional biases or other overzealous or skewing optimizations.

I was then *extremely* lucky to get help from Cliff Click of Azul systems (if you want to write a benchmark, a VM engineer is the right kind of person to get help from). He spent half a saturday tweaking my benchmark in ways I never thought of. Then ran them for me on his 768core Azul box (graph inside)!! thanks Cliff !

Notes for my SD-West talk tomorrow on Interviewing in Silicon Valley

I'm giving a half-day tutorial tomorrow at SD-West 2008 in Santa Clara on How to Pass a Silicon Valley Software Engineering Interview.

Its the first of 3 talks I'm giving this week (subsequent notes to come subsequently).

You can download the slides Here.

If you're not attending the talk, please note that as with all slide decks, they are in a sense only half the story - as I'll be filling in many pieces during the lecture itself.

This is the third year I've given this talk and I'm amused to mention that I got a thank you a few weeks back from a veteran SD speaker that attended last year's class and now is just starting his new job at Google. He said the class was very helpful (he also offered to buy me dinner, but given that dinner at Google is free, I countered and offered to buy him dinner instead :)

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.

Your business model called; its leaving (and its not coming back)

Let's say you found yourself a cash cow. Something that made you tons of money; day after day. And let's say that you get better and better at making your cash cow efficient. Pretty soon, you're rolling in dough. At some point you can nearly rest on your laurels while your money machine keeps churning. Eventually, you probably don't need anymore money, but that doesn't stop most people it seems. You just keep on wanting more (and why not, if the cash cow keeps delivering).

Its probably pretty safe to say that at this point in time, the advent of some technology enabled your cash cow. Maybe it was recorded media or a new video format or some computers in need of an operating system. Whatever it was, its likely that some recent technology gave you the building blocks to create your new cash cow business.

And, as you realized that technology enabled your cash cow, you also know that it's just a matter of time before it's going to disable it too. Usually by the advent of yet newer technology obsoleting yours. What do you do then? The best option is to see if you can morph your cash cow to be in synergy with the new technology. Kodak is a good example, they moved from pure film to a strong embrace of digital photography. AT&T is another - land phones are dying - they made sure they were in the mobile business.

Other models however aren't so easy to move with. Music CDs are sort of silly now and the new technology doesn't leave a lot of room for a new business model. What do you do then? You might think that you're the kind of person that if you spent a few years making millions (or billions) producing music CDs that you might eventually have enough of it all. If you truly can't save it then - you can take your millions, smile back upon the fun ride of building something great, and move on to something new.

You might be. But it doesn't seem like this is the way it works. Instead (statistically speaking) if you had an un-save-able dying cash cow, you'd defend it anyway. You'd start to use the millions your cash cow makes to try to change laws, start lawsuits, or stifle technology to artificially keep your cash cow alive. Quite literally, you'd use its own resources to hinder future technology that will hurt it (regardless if thats good, bad, or indifferent for humanity).

Technology enables business, art, and science. And it kills them too, usually by advancing to a point that makes the existing ideas obsolete. A few people miss LP records these days, and surely some still play and collect them. But that number will continue to diminish. I'm sure plenty of folks stuck with a horse-and-buggy because they thought automobiles were a stupid idea. Those people are mostly dead now, just like LP records will be some day.

Now, it might seem like I'm picking on the record industry. I'm not really, they're just a poignant example. Whatever you think, the people in that industry are not idiots. They *know* their business model is dead. Dead, dead, deaddity, dead, dead, dead. Music is really a service, the idea of putting in on a CD was always an artificial means of trying to turn a service into a product.

Instead of teenagers idolizing manufactured rock stars, the internet gives every indie band in the world an open forum. It wasn't that long ago that rock bands begged and prayed to get signed with a big label. Now they can start their own label and reach thousands of listeners, all for the cost of a website. Add a marketing and sales manager and you have a music-making company.

You don't need to be a futurist to predict some corporate business models that will be dead (remnants always remain for awhile) in the near future. Shrink-wrapped software, music CDs, desktop computers, and purely-gasoline automobiles to name a few.

What about if we go just a little longer term - say 30 to 50 years. Now I'd venture to say things keyboards, mice, paper books, bullets, telephones, and batteries.

You might disagree, but I think you're not thinking far enough ahead. I don't think people disagree because they think this idea is wrong. I think just like (or depend) on some of those things and don't want them to go away. If you sell batteries, you'll probably vigilantly tell me that we'll ALWAYS need batteries. In fact, although "30 to 50 years" might not be accurate, my predictions above are pretty guaranteed in some time frame.

A friend of mine disagreed with me when I said libraries were destined to disappear. He argued they won't because people will always like to read from books. "Will always" is a very long time. Most people like books because they're used to them, kids today are pretty used to reading off screens a fair bit of the time. Tomorrow's kids will be even moreso. And would you really be willing to bet we won't invent something better (in all ways) than a paper book in a 100 years? 200? Heck, I'd bet reading itself will be gone by then.

Coming back to the nearer future, the title of this article talks about dying business models. Finding ones in the global corporate marketplace is easy. What I'm more thinking about is *your* business model.

Whether you're a assembly-line worker in a Ford plant in Michigan, a C++ programmer (sorry, I mean "software engineer") in silicon valley, or a McDonald's fry cook. Its pretty damn likely that technology is going to kill your job or career (i.e., your "business model") in your lifetime.

I've read around the net that its a "bad time to be a photographer". Simply put, thousand dollar digital SLR cameras and photoshop have destroyed the historical profession of a photographer. Surely, a skilled photographer can take better photos on average than an amateur. But the rules are now changed. With multi-gigabyte memory cards, I can snap photos all damn day long. And the camera has gotten far better at helping me take great photos. And Photoshop can come in the backside and fix any minor problems I might have. Maybe its a bad time to *be* a photographer - but its a great time to *become* a photographer - anyone can be one in just a few hours! (Of course, thats exactly why existing photographers might think its a bad time to already be one).

Seriously, if I snap a quick thousand photos, its getting more and more likely that I'll snap a really good shot. Then I can sell it on the internet in many instant-gratifying ways for a fraction of historical stock photography. The profession as we knew it is likely soon gone.

I've seen this even in computer programming. Coding used to be much harder than it is today. It takes much less devotion and study to make programs these days and its getting easier all the time. You might argue that good programmers write the best code, but you rarely need the best code to get a website up and running. And programming is perpetually going to get easier. (It used to take HTML expertise to make a website, now it just takes a MySpace account).

Scary enough I can boot up Adobe Illustrator (or more precisely, Gimp in my case since I use linux) and I can do things that a professional graphic designer of 20 years ago could only dream of. This is really a frightening thought - I have a really exceptional lack of artistic ability, but Gimp gives me a baseline. I might not be able to reproduce Van Gogh, but I can make all the graphics I need for websites or Christmas cards or whatever.

In a grand view, this is probably a great thing for our world. More people can do more things faster. It all sounds great unless you're personally be obsoleted in the process. Complaining photographers have somewhat of a point. They spent years perfecting their craft. They learned tricks of lighting and developing and who knows what else just to have it taken away by some fancy new camera. Technology obsoleted their craft overnite (like the song says, "Video killed the radio star").

If you're not a photographer and you're sort of not feeling sorry for them, thats ok as long as you're careful to shine that mirror on yourself too. Like I said, if you spent years learning the intricacies of C++, tax law, medicine, or anything else - you surely have job security likely for awhile. But definitely not forever.

Whatever your business model - it is indeed, at some given rate, dying. And its always possible that a technology will come to be tomorrow that will destroy it instantly. And every year we shall see more fights ensue with people looking to save their business model.

Create a cure for cancer? Watch the chemotherapy companies go into action. Build an electric car thats cleaner, faster, and more economical than any gasoline one? Watch the oil and car companies head to Washington. Invent teleportation? Airline industry sponsored laws will quickly be up for debate.

If you're complaining that your business model is dying, you might as well complain that the sun is going to come up tomorrow. Its going to happen and you have two options - keep moving or retire. Be ready to throw out what you learned if you see it becoming obsolete.

If you're lucky you'll be on the forefront of that technology and you can start a company giving you your own technology-induced cash cow. Once that happens, you can sit back counting money. Until the next wave comes and your once new cash cow starts to crumble. Then, of course, you can adapt again or you can become the technology stifler yourself. Somehow I have a feeling that thats one job that will never go out of style.

Don't Chase your Dream Too Fast

I thought of a funny quote today (which is oh-so-true):

Don't chase your dream too fast - chase someone else's first, and after you screw that up and learn a little; then go after yours.

(this applies to dream jobs, dream dates, pretty much "dream anything")

This blog made the Top 50 Google Blog list

SEO-Space has ranked my blog #47 on the Top 50 Google Blogs list. That's pretty cool given how many blogs by googlers are out there.

They mentioned my earlier article on Why I work at Google.

Thanks SEO-Space!

(Of course, I work for, but do not speak for Google. All words are my own.)

Using Tricky Assertions

I'm not sure why, but I never got much in the habit of using the java assert keyword. Its a nice idea, but I somehow just checked what I wanted the old fashioned way.

And, although I'm a big fan of IDEs and I love debuggers, I still find having some print statements here and there sometimes is really helpful.

Of course, print statements suck when you're done and you no longer want them. That is, you need to go delete (or comment them out) all over the place.

I've sort of combined these ideas into a pretty obvious trick (which I seem to get asked about a fair bit, hence this post). Its basically a comment-out-less, performance-free debugging (or stats, or logging, or whatever) facility.

Simply:

assert(Debug.out("test code val="+val));
or
assert(Stat.increaseHitCount());

The only trick is that the method (like "Debug.out") must always return true. Now run the app with assertions turned on "java -ea Main" and you get the messages. For production, simply don't run with -ea and the VM will ignore those statements (I hope) altogether.

This basically gives you an application-wide, command-line way to turn on or off (with no performance hit if the VM is smart) some code. If you think about, there's many possible uses for such a thing.

Edit: Code for Debug.out would look something like:

class Debug {
 public static boolean out(String x) {
  System.out.println(x);
  return true;
 }
}

Been Reading Crappy (Half)Books

I don't read a lot of books. At least under the definition of, you open it, flip pages over several days or weeks, get to the last one, read the last sentence, say "huh", and put it down. I mean, I don't finish a lot of books, at least nowhere near the number I start.

I *do* read a lot of half books - that is I only get half-way through. I have a feeling I'm rather hard on books - I expect a lot.

The problem I see is that there is simply an absolute deluge of books that should be articles. Simply said, books are about ideas. However (fixing the english of that last sentence), every book should be about multiple ideas.

So so so so many (half)books I read are only about one idea. They have a wispy chapter 1 introduction, chapter 2 introduces the idea (which sometimes is so simple it takes a paragraph), and then the rest of the book cites contrived/researched/induced examples about how that idea is so great.

That's fine and all. Some of those ideas are pretty luminary (i.e. Freakonomics comes to mind) but one single idea has to be pretty damn big to make a book. (Meta-note: the idea that books should be about multiple ideas and not just one idea is probably not a big enough idea to be a book, just an article, or maybe even a stinky little blog post).

I read a lot of technical books (not halves usually) and technical books are pretty hard to be stuck on one idea. Brian Goetz' Java Concurrency in Practice is a great example. If you're a Java techie, this is an incredible page turner. (Another amazingly great techie book is Warren's Hacker's Delight .)

I also read a lot of (half)books about business. I just read a (half)book called Selling Blue Elephants. The basic idea was to do market research using actual customer testing. Cool. Good idea. They even gave a spiffy acronym to try to add it to the world's business vocabulary (much like "tipping point" and "long tail" have done in the past few years).

But that was about it. The rest was case studies on how customer testing helped a bunch of products. Yip.

I also have been listening to Good to Great lately, a pretty heavily lauded book. I don't usually do books on CD but it was a gift. There was a lot of solid empirical research in it which was helpful but it seemed (much like Built to Last) to be fraught by survivorship bias. And I don't discount the strong research, but the results were somewhat expected (that's no ones fault, its just that everyone loves a plot twist).

The entire section devoted to how people in "great" companies tend to be stay friends is what really ended up ejecting the CD however. It almost seemd to imply was almost that if you were only in a "good" company, you'll never make any friends.

My expectations are probably too high. Business vs. technology is largely analogous to art vs. science - and its damn hard to write about art (as compared to science). Its just too subjective.

Becoming a great businessperson is analogous to becoming a great techie. It simply takes some level of innate talent that can't be replaced by hard work (and after you have that, then you still need a lot of hard work). After that however, the tech stuff is arguably easier to document.

Now I definitely might be too hard on books but how I figure it, I only get so many days on this planet (and this planet is the only one I know with books). I really can't afford to waste time on any book I find anything less than insanely great (Influence by Cialdini).
Ah well, onto the next - maybe I'll read some Call of Cthulhu. Or even better, "How to run a business like Cthulu would" - I bet there'd be more than one idea in there.

Doing Wheelies

In a vain effort to remedy the situation where my friends are starting to call me names like boring, settled, and overall rather linear; I attended a wheelie class this weekend. If that sounds odd, well it is. I don't think there are that many such schools in existence.

It was a one day, 8-hour class and let me tell you, by the end of the day I could have not been more tired.



The instructors definitely knew what they were doing. The bikes were outfitted with a dual-stage limiter. It had settings 1-5 each at a progressively higher angle. Once the limiter was hit, the center cylinder (of the 3 cylinder speed triple) was turned off. So you rose up, hit the limiter, and then the engine lost 1/3rd power usually sending you back down.

After that at level "6" another limiter engaged that hit the back brake. The bar you see on the back (btw, that pic is of Simon my classmate as it was sort of hard getting a pic of myself whilst wheelie-ing and all) is not a hard stop bar, its merely there to engage both limiters.

I flipped a dirtbike a few years back screwing around which always instilled a good deal of respect in me for wheelies. Now the limiter was there to not let me do it again. By the end of the day I was at level 5 with pretty consistent wheelies. I really did go from nothing to finding the balance point in one very tiring day (I can't believe how sore I am today).

If you think this all sounds dangerous, well it can be. While I was standing by the side of the run, one of the students came out of a wheelie and in the process of trying to stop, locked the front brake and washed the front tire. He and the bike hit the ground doing about 50mph. The bike went skidding on its side right off the cement into a field like a hockey puck. The rider tumbled awhile and came to rest with (luckily) just a broken wrist (we were all wearing head-to-toe leather armor plus helmet).

That was an unfortunate cap to the day. Although I do get to add wheelies to my ever-increasing list of possibly interesting but mostly useless skills. :)

Sprint Customer Support

I've had my share of bad customer support experiences, but this one is special. :)

A few months back I logged onto sprint.com to turn off receiving text messages on my phone. I was simply getting too many spam texts. Not being able to receive friendly texts however eventually turned into a problem. At times, friends would text me and rely on the fact that I received it. Sprint doesn't notify the sender the message isn't delivered. This caused a few annoying instances.

Anyway, I decided I needed to turn texting back on and simply accept the spam (seems like spam would be relatively easy to stop on an SMS network, but then again phone companies also make money on that spam, so maybe they're not all that motivated to do so. Who knows - regardless, I was getting a fair bit).

I went to the website again (now a few months later) and tried to login so I could turn texting back on. Well, as I'm wont to do with websites I dont login to for months at a time, I forgot my password. I cheerfully clicked the "forgot your password?" link which asked for my phone number.

Ok.. I entered my phone number which then gave me a message - "We have sent you your password via text message!".

Um. Hey smarty-head - your database has a bit that says my text messages are turned off. Maybe you could, ya know, CHECK THAT BIT before you go off and send me my password via text message so that I could login with the sole purpose of turning my text messaging back on. (Hey btw... I have a new advertising campaign for you: "Don't have any access to a phone whatsoever but want one? Call us!")

So.... off we goto customer support. I dial their customer support number and funny enough the first thing the automated system does is to ask me is to enter my phone number.

Um. Dear Sprint - this is YOUR phone service. Maybe you should spring for caller ID for yourself and then check the incoming number against your database (you have this database thingie turned on right? Its the big pretty box that says "Oracle" on it) and then ask that given I'm on a Sprint number, maybe thats the number I'm calling about. You never know - it just might work.

From here I deftly navigate their convoluted automated phone tree (which consisted of just pressing 0 a LOT) and sat on hold for about 20 minutes.

Finally, I get a customer support person. She greets me... and then.. with what I perceived as a tint of "this is gonna be good" in her voice, she asks:

"What's your phone number?"

WTF. So.. you're Sprint. Its your line. You'd think you'd have caller ID. If not, You just made me enter my phone number 20 minutes ago (prior to hold) and the first thing the real live person does is ask me again?

If this system was designed to frustrate customers away from using it, its pure user interface art.