Neil Mix

One of Joel’s recent posts has been tumbling around in the back of my head. His observations are, as always, excellent. But unlike his usual posts, the conclusions drawn in this one mystify me. I see his point, but it feels…crazy.

One important truth he reveals is that software projects need not run optimally on today’s hardware; Moore’s law and the passage of time guarantee that when your product hits its prime market share, the hardware will be capable of supporting it.

Apply this maxim to development platforms, flip things around a bit, and we get this:

Any software development platform incapable of fully utilizing its hardware will surely fail.

This is true because there will always be some other platform that is capable of soaking up all that power, and that platform is going to have whiz-bang features that everyone’s gotta have right now that can’t be done in the old-fashioned turtle-speed platform.

Java is a great example. For those of us who used it back in the mid-90’s when it was brand new, it was slooooow. It was hard to believe that this was a “real” development platform. But it had some great features that outweighed the perf issues. And 10 years later, after 5 or so revs of Moore’s law and some nice optimization, Java is king. (Or at least queen.)

Case study #2: Ajax. Remember Ajax back in 2000? Yeah, I do too. If there’s a lesson to be learned from Java and Ajax, it’s this: your development platform should aim to run on tomorrow’s hardware. Worried that RoR is too CPU intensive? Relax, Moore’s Law will take care of it.

But…

Moore’s law isn’t quite the same as it used to be, now is it? As you might have heard (sarcasm), the multi-core world is coming, and a few people are a bit riled up about it.

Back to Joel and Ajax. Ajax depends on JavaScript, and JavaScript — as currently spec’d and implemented in browsers — is a single-core beast. The new version — supercharged kitchen-sink-of-features, still in its final spec’ing stages — will probably appear in the wild sometime late 2008. And what’s the new version doing to integrate well into the new multi-core world?

Well, nothing really. And it’s too late to change that.

So now we’re looking at version 3 of JavaScript before multi-core deficiencies will be addressed. Meanwhile it’s at least a few years before version 2 is established enough for Ajax apps and frameworks to depend on its features. Lather, rinse, repeat, it’s another couple years after that before theoretical multi-core Ajax apps are viable.

Repeat: the performance of Ajax apps will remain little-changed for the at least the next 3 to 5 years, unable to utilize multi-core processing power. (Same thing applies to Flash too, you’ll notice.) By that time, current processors will likely have 16+ cores. That’s a whopping amount of processing power lying dormant.

Do you think 5 years enough time for someone to build a platform that contains all the benefits of Ajax, plus some new great stuff, that lets developers soak up all the processing power in those extra cores, and deploy it to 90%+ of machines out there? Do you think maybe some of the big players have efforts in this space already underway? (hint: Gears is a start.) It’s just a question of who and how soon.

So what does this mean for Ajax? For one thing, it means that Ajax — as it currently exists is — will have to evolve for the long term. One of the major browser vendors is going to have break ranks and extend the browser platform to go multi-core (it won’t happen in lock-step — design-by-standards-committee is too slow and will inevitably lead to a back-stab). Either that or something new will emerge. (Or more likely, many new things will emerge.)

Get ready to brush up your skills…

It happens on every flight. The lights go off briefly as the pilots prepare for takeoff. Instinctively, passengers reach up for the button that turns on the reading light. It’s a red, rectangular button directly overhead…it’s hard to see (because the lights are off)…is this the one?…*bing*

The big red button is alluring, all-powerful in it’s ability to draw you toward it. Place it with care — the best placement is not intuitive. Most often, the big red button belongs somewhere you wouldn’t normally find a button. Consider: the airplane (wrong), versus the subway (correct). Easily accessible: yes, prominently visible: yes, intuitive: no. The idea is that in a panic, you’ll find it, but in your daily routine it’s out of your way.

Draw parallels to your communications. How many times have you inadvertently started an email panic by placing an unqualified big-red-button in plain site? Conversely, when was your big-red-button missed because it was buried deeply in amidst complex prose?

You may have noticed that some of my previously missing blog posts magically re-appeared this evening. And those close to me may have noticed that I caught up on email this evening. Plus I cleaned up the kitchen after dinner, did some other chores, and even managed to get some time on the piano. And now I’m writing this. Later, I may work on a new novel, finish the basement, and/or win the Nobel Peace Prize. We’ll see how my energy holds up.

Any parent of a newborn will recognize this — it’s the arrival of “The Schedule.” The Schedule is the magical point in a baby’s development when he stops going to sleep at a random time and waking at night (say, from his own gas) to discover that he’s hungry and needs to eat RIGHT NOW. Instead, he follows a daily pattern and holds in the gas (or sleeps through it — damn funny over the baby monitor, I tell you) and then wakes up early in the morning needing to eat RIGHT NOW.

For first-time parents, The Schedule is half mythology, half mysticism. You’ve heard of it, but don’t believe it exists. Or if it does exist, it’s not for your child. How can this child, whose sleeping pattern can only be described with the help of advanced chaotic science, suddenly become the Family Timepiece? We know those other parents who claim they got their child on The Schedule — why can’t we? Is it a cult? Will they let us in?

So after a couple of months of what I like to call “baby terrorism,” when The Schedule arrives it is a moment of great relief. Except for all the manic tasks and chores.

Manic, you say? Yeah, there’s the whole PTSD thing. Months of being on “high alert” (armed with wipes and onsies and headed for poopy combat) leaves one completely unprepared for the strange routine most people refer to as “daily life.” When The Schedule arrives, it is not to be trusted. Fool-me-once (and all that mumbling), I have 5 minutes to spare if I’m lucky, I better go change the oil.

I’ve always been a procrastinator, until now. You see, before The Schedule there is no such thing as “I can do that tomorrow.” That is the path of crusty bathtubs, overflowing litterboxes, and a stinky kitchen. So you evolve, and you do less with more, and you act with urgency. By the time The Schedule finally does arrive, you’ve forgotten that tomorrow is a tangible, reliable thing. Tomorrow? No no no, now that’s a myth.

Doing more-with-less is a Good Thing, thank you Henry. I don’t know why I used to think that researching reality show biographies was important. But no more! Now, where was that cancer drug formula I was working on…

Imagine you need to tell a story, to walk someone through a coherent thought beginning to end. Now imagine that you can’t use words, and you can’t use visuals. You can use sound, but you can’t use spoken language of any kind, and your audience will be blindfolded. Where would you start? How would you proceed? What messages would you be able to convey? And how limited would your message be?

At first glance, it may seem this format is too limiting for meaningful communication. But that’s not the case: the composers of classical music were great masters of the design and presentation of complex narratives, and they did so without words or visuals. For a master class in story telling, study classical music.

It’s no easy trick. You need to repeat your themes, but not too much. Themes must be presented in different ways, but not too different. And you need to evoke recognition of archetypal structures, but do so without belaboring the obvious.

A well-written classical music piece contains the plot of a great novel or movie: it has a well-defined flow and structure, it tells you where you are going without giving away the ending, and it’s so interesting that you’ll enjoy the ride even if you’ve experienced the story many times previously. When done well, the removal of any one section renders it incomplete. The narrative takes on a life of its own beyond the composer, as if it had always existed but no one ever pulled back the curtain to reveal it.

The sad truth about classical music in the modern world is that most people consider it “background” music. It’s fairly easy to hear simple beauty in classical music moment by moment, one theme at a time. But this is a shallow understanding of the music. In order to grasp its true depth (and unimaginable beauty), you have to “listen big”. You need to pay attention and remember each moment, and then you must reflect on how each moment impacts the next. In the end, the structure becomes clear. A beautiful architecture is revealed, and a deep emotional understanding is imparted. Rachmaninoff described this moment in a piece of music as “the point”. It’s presence is the hallmark of a masterful presentation.

Unfortunately, the attention requirements of classical music don’t mesh well with today’s sound-byte driven world. My college music history professor spent a year walking us on a musical journey through centuries, and his final lecture led to the conclusion that classical music (or more specifically, The Tradition of Western European Art Music) was terminally ill, if not already dead. It was a great moment, and remarkable in that he employed the master’s device on us — he built us up to a culminating “point” where a profound message became clear. Stunned by his prognosis, we were deeply saddened. And we applauded.

The next time you hear a bit of classical music in the background, consider scratching a little deeper. You might be surprised at what you learn.

As you may have noticed, my blog has been offline for a while. I’d like to say that I was too involved in a stealth-mode startup pursuing teleportation technology to notice that my blog was down, but the reality is far more boring. My blog provider sufferred a hard drive crash, I didn’t have a backup, and you know the rest.

We’ve all shared the misery of data loss at one time or another. It sucks. However, the past couple of weeks have given me a chance to reflect on the direction I was headed with my blog. I’d never gotten to the point where I felt my “true voice” was active, so I feel like this is an opportunity to give it another shot.

I’m a startup guy, so I’m all about starting from scratch. I far prefer the blank slate to the well-defined shell. I hated losing my blog, but I love the potential of a new start. So here we go.

(Of course, there are a few posts on my old blog that were traffic drivers or personal favorites. I managed to recover those from my blog reader; they’ll be appearing again as soon as I get a chance. In particular, the “Threading in JavaScript 1.7″ post, with its accompanying Thread.js library, is not lost. Expect it again soon or drop me an email if you’re impatient.)

This year marks the 10-year anniversary of my first startup. My high school friend Dan convinced me to start a web-based shopping-cart service with him. My logic went something like this: “Ok, 4 out of 5 companies fail within their first year. But hey, I’m young and employable, what have I got to lose?”

We ran the company out of a spare office in a local ISP’s facility in downtown St. Paul. I worked consulting gigs to fund the business, Dan solicited consulting gigs for me and worked on selling the business. And in whatever spare time we could scrape up, we built the shopping cart.

We made mistakes. Lots of them. Technical mistakes, architectural mistakes, business mistakes, all kinds of mistakes. If I were to do it today, I would do lots differently.

In spite of that, a year later we were bought and relocated to San Francisco. Half a year after that our buyers were bought by Microsoft.

Had we run the business with the benefit of my hindsight and maturity, I suspect we would have failed. Perhaps within a year.

There are a few shared qualities I’d use to describe every successful bootstrapper I’ve met: resourceful, scrappy, never-say-die, and blissfully ignorant of the “correct” solution. Does it work? Ship it. Is it a hack? Ship it. Just do it. Make it work, just do it.

Those were fun days. I miss them. I don’t think I can ever fully return to that life, which is more good than it is bad. But it’s important to never lose touch with the bootstrapping temperament. It needs curbing, restraint. But not too much.

I’d heard all the stories about how much work it is to take care of a newborn. I’d heeded the stories carefully. I knew it was unimaginable, but I had imagined it that way, and thus I was ready.

And yet, 48 hours after bringing my baby home, I couldn’t imagine how I’d imagined this unimaginable way of living. There’s so much they don’t tell you that they should have told me.

Thankfully, I’m going to save you from my mistakes. Listen carefully to the short lessons provided below. If you follow my instructions carefully, I’m certain that caring for your newborn will be a breeze.

With that, here’s a few things the so-called “textbooks” fail to mention:

• Your wife is likely to be tired and require rest in the days after birth. Expect her to move about half as fast as she normally does. A little simple math and you can see that you need to increase your efficiency by 1000% to compensate. Not so simple? Ok, here’s how it works. Baby is the work of one person split between the two of you, that’s 150%. Wife moves half as fast, so add 75%. Now scale appropriately to account for your laziness around the house in pre-kid life. Come on, let’s be honest. 1000%.
• Sleep deprivation and fatigue decrease memory and brain function. In the middle of the night, the effect is quadrupled. This applies to you, not just your wife. I’d ask you to remember this when you two are arguing at 4am over whether to nurse from the right side or the left side, but I’m pretty sure you’ll forget.
• Your wife will likely have restrictions on the weight she can carry, probably about 20 pounds. Of course, your doctor knows that she’s an over-achiever, and will halve that value just to be safe. You’ll take the doctor’s instructions for your wife, halve the maximum weight just to be safe, and therefore demand to your wife that she carry no more than 5 pounds. Your wife will point out that’s less than the weight of the baby, and surely the doctor didn’t say she couldn’t pick up the baby. You’ll discuss, and eventually compromise that wife can carry the baby, but not up and down the stairs. (See notes about reduction in brain function above.)
• Baby is the ultimate interruption. You already know that, but the interruptions compound on each other in unexpected ways. It works like this: you come home with the laundry half done and the dishes half washed. You start finishing the dishes, and baby cries. You help out with baby, and return to the dishes. But on your way you see that the cat dish is almost empty. This reminds you that you have to scoop the litterbox. On your way to the cat food, the phone rings. Mom-in-law is kindly checking in on you. You chat with her, baby cries and needs a diaper change before feeding. So you hand the phone to wife while you tend to baby. After wife is off the phone, you head toward the cat food, but wife reminds you that after baby’s feeding she needs to pump, so the pump gear needs to be washed, and while you’re at it can you carry the laundry basket to the washer (see weight restrictions above). You start washing the equipment and intend to finish the dishes while you’re at it, but before you’re done the doorbell rings — Fed-Ex is delivering a baby gift from your sibling. Baby’s just finished feeding, wife needs to pump, the equipment needs to be cleaned NOW, suddenly this is priority numero uno. You wash the equipment, wife starts pumping, and curiousity is killing you both about the package, so you open it and celebrate new gifts. Baby is sleepy, and as you carry baby to the crib, you can’t help but feel that you’ve forgotten something. The dishes, that’s right, they still need to be finished. And the laundry, that too. This is how you end up choosing to wash a piece of plastic while your cat starves and pees in the basement. Moral: Make lots of lists. If you can remember to.

Scared yet? Don’t be. This final rule will save you:

• Don’t believe the horror stories your guy friends tell you before your baby is born. Fathers like to scare expectant fathers. They enjoy seeing the fear in your eyes. I don’t know why, I suspect it’s some sort biological imperative.

Isn’t that nice to hear? Whew!

Ha! Fooled you! hahahahaha

Boy I wish I could see your face right now.

I once had the pleasure of meeting the UI designer for Tivo at a party. Sadly, this was before it had become popular and I was not yet a customer, so I don’t have any great stories to tell about her philosophy toward UI design. In any case, I remember that some time later I mentioned this encounter to a software engineering friend of mine, and he responded with great distaste, “Boy would I like to give her an earful!”

To this day I am stunned by my friend’s callous disregard for the Tivo UI. Of course Tivo isn’t perfect — no UI is — but there’s so much they could have done wrong, that most companies would have done wrong, that they got right. I still regard Tivo as a landmark product that changed people’s perception of what’s possible with technology.

So what of my friend and his disdain for Tivo? Sadly it’s not too uncommon to hear techies skewer products with otherwise good UIs. And that is the crux of what I call the Elegance Paradox.

I often say that it would be awfully painful to be a top-notch designer whose boss doesn’t understand design. The design process is about whittling away distractions, making the obscure feel obvious, making the obvious feel implicit, and doing it without anyone noticing. To the untrained eye, your best work looks like you’ve done no work at all. If you’ve done a stellar job, then your design will feel utterly obvious.

The Elegance Paradox is this: to create elegance requires entirely inelegant preparation, but nobody should be able to see that. How many times have you said to yourself “that person makes it look so easy.” That’s a pretty common reaction to seeing an expert in a field you’re not familiar with — their presentation looks smooth, spontaneous, and simple. But the more familiar you become with a particular field, the more you recognize how difficult it all is. As you get more proficient, you realize that creating elegance isn’t smooth and effortless, it’s full of strains, grunts, gasps, hard work and complexity.

And once you’ve whittled away and acheived some modicum of simplicity, what’s left for the outside observer to see? “Obvious” flaws.

When I first became interested in UI programming (and more specifically, sane user interfaces), I thought that I was one of the rare programmers who “got it.” I would look at the world of tech products out there, and I could see their numerous flaws instantly. I was certain that, given the chance, I would be able to do better.

Several years later I’ve learned the toughest best lesson I could: it’s easier to see the flaws than it is to see the elegance. As much as I’d like to believe otherwise, I often don’t “get it” when it comes to UI design, which is why I rely heavily on the opinion and judgement of my designing coworkers. Anytime I might pick at something I perceive as a UI flaw, I remind myself that there are a myriad of design decisions that I can’t see. If I were put in the same position as the designer, would I have made the right choice on all those decisions? Likely not.

So now we come back to my friend who thought the Tivo UI designer needed a good talking to. What’s his problem? His problem is that he doesn’t understand the Elegance Paradox. The simplicity of the design led him to notice only that which was missing. To him the design felt entirely obvious, and he mistakenly therefore assumed creating such a design is an straightforward process.

Amongst software engineers, the designer of Rails or Python or jQuery will receive much credit for their work (and rightfully so) because we’re all familiar with the problem space, and we all recognize that we likely couldn’t (or didn’t) make the same good design decisions when put in their position.

For UI builders, it’s a different story. All too often, the problems of UI elegance are dismissed as “something we just need to do better,” or “an area where we need to pay more attention.” Well-intentioned critique, no doubt, but not remotely grasping the scope of the problem.

Good UI is hard. Not just the design, but the programming too. Coding an elegant UI is an endless process of fixing twitches, hitches, and glitches that no one will ever see or know about. When done well, the end result is a smooth, elegant, effortless UI interaction, but your customer won’t recognize the tireless effort you put in to make it happen. And that’s how it should be. Is there any better way to serve your customer?

If you want a responsive software engineering team with reliable development schedules, here’s one simple rule:

Make sure that every developer’s checkin leaves your product in a state where it can be compiled, built, and demoed.

That’s it. Focus on that and the rest works itself out.

Why? Because you and your team are smart — if you can see problems, you’ll fix them. But you can’t react to what you don’t know. For every week/day/hour your gestating product is AWOL, your team ventures further into the unknown, adding unpredictability to your development cycle.

Sound difficult? It’s not. It takes effort and diligence, but pays back in spades.

Amongst the many new features contained in Firefox 2 you’ll find JavaScript 1.7 support, a small but significant language enhancement that includes python style generators.

A generator allows you to suspend a function’s execution and resume it at a later time. While typically used for advanced looping constructs, a generator can also be flipped inside-out and used as a rudimentary coroutine.

At first glance, this may not look very impressive, especially since generators are unable to yield across multiple frames in the callstack. However, with the help of a technique called trampolining generators can be used to write code in a style similar to threaded programming.

The way trampolining works is that a scheduler object (written in JavaScript) manages the execution of a series of generators, cobbling together a stack-like execution. Here’s how it works: The scheduler sets the starting generator as the base “frame” in the call stack. The scheduler then calls next() on the generator to obtain a yield value. If the yielded value is itself a generator, the scheduler pushes this new generator on the stack and calls next() on it, again obtaining a yield value. This continues until the top generator yields a non-generator value. This value could be a special directive to the scheduler (for example, a SUSPEND value that tells the scheduler to freeze execution of the “stack” of generators we’ve piled up). If not, the scheduler treats it as a return value. The scheduler then pops and closes the now complete generator and sends the return value back into the next generator in the stack.

Sound confusing? It’s a mind-bender — I had to read a trampolining description and its sample code a few times before I understood how it works.

The coding style when trampolining is a little awkward. You need to yield any function call that will suspend execution of the stack. Here’s a contrived example:

  function myThreadedCall() {
     while (!ready) {
       yield sleep(100);
     }
     yield waitForInput();
     if ((yield post(getInput())) != null ) {
       yield animateUI();
     }
   }

In this way, using generators to trampoline is a very explicit form of concurrency. It’s verbose (unlike, say, Lua-style coroutines), but that verbosity has the upside of execution clarity — it’s much easier to see on visual inspection where race conditions can occur.

(Those of you with sharp eyes will notice that the technique described here is not true threading, but fancy coroutines. That’s the underlying implementation; to the programmer using this technique, it looks a lot like threading.)

No discussion like this would be complete without a pointless example, and this post is no exception. Check out this example (only works in Firefox 2), along with the example source and the threading library.

The use of generators and trampoling isn’t a panacea for concurrency in JavaScript. The technique renders code essentially “stackless” as far as the JavaScript interpreter is concerned, which means that you won’t get a meaningful stack trace if an error occurs. Thus debugging can be a bit painful.

However, it’s worth noting that the trampolining Thread.js is a slim 4K (uncompressed). And there’s no pre-compilation, no parsing, no AST manipulation, and no code generation. Simple. That’s the benefit of native language features.

All in all, I wish JavaScript had a more directly supported concurrency mechanism. I raised the topic on the ES4/JavaScript 2 discussion list, but in the end it was decided that the inability to yield through native C stack frames at the implementation level made it infeasible for some embeddings (such as cell phones and other devices). We’ll see what happens in later versions. (Brendan Eich has hinted that JS3 will be ready for multicore desktops.)