There’s a myth in the sciences, I feel. At least in computer science.

I think people working in CS have a general love of complexity. They like complex algorithms that do something “clever” (e.g. Personally, I love the way NTP syncs clocks even across computers connected with networks with unknown delays). There’s also a sense of triumph on discovering subtle issues (like finding out a Heisenbug that some compiler-optimization caused).

Unfortunately, this love of complexity also overflows into the kinds of problems that people want to solve. I’ve seen people taking special pride in solving a complex problem (a general template is improving an algorithm so it works for all cases, not just 99.999997% of them).

My recent visit to Seattle (Redmond, actually) where we demo-ed a project at TechFest has convinced me that the world in general cares about something very different. TechFest is an internal Microsoft conference that enables researchers (ie. Microsoft Research) reach the Rest of Microsoft (i.e. product groups like Office or Windows).

Given its scope, TechFest usually has demos and research ideas that product groups are most likely to want to use in their own products, and so is a good case for understanding what people actually care about (the reasoning being that product groups, with their limited resources, will attack problems important to their customers).

Now, here’s the thing that strikes me about the TechFest demos– in (nearly) every case, research seemed to attack a simple problem. Actually, an obvious problem. It might propose a really complex solution, but the problem was always obvious.

I can’t give any real examples (confidentiality– I never know what’s ok), but an automobile-equivalent would be finding your car in a huge, crowded parking lot. The solution may be complex (my fantasy solution to the parking problem involves the keychain going hot-or-cold depending on how far you are from the car– somewhat like this), and may involve a lot of effort from different domains (wireless devices, UI, location…). However, the problem is pretty obvious–someone’s lost their way in the parking lot–and it has obvious value.

I think the obviousness-of-problems has implications both for how to pick problems (looking for interesting solutions seems to be more valuable than seeking out interesting problems) and how to sell your solution (if your solution has several parts, expect the part that solves the most obvious problems to be adopted earliest).

It helps that we are so surrounded by obvious problems– on the Web, for instance, remembering which sites you’ve visited (I consider bookmarks a broken solution). I’m sure there are many more.

In hindsight, it all sounds obvious; I wonder what took me so long to figure this out.

I was lucky enough to be taught by a professor who actually knew what he was talking about–understanding his domain deeply in a way that would withstand unbounded questioning. (I’ve slowly come to realize his is indeed a rare breed)

So, one day he walks into class and asks “when can you use the Divide-and-Conquer algorithm to solve a problem?”. And we all pounce on this easy question “when you can divide the problem into sub-problems that you can solve”. And of course the professor isn’t satisfied (we should have known better– he never posed easy questions to while away time).

In typical classroom fashion, we began to add more jargon to the problem, mentioning details such as finding non-overlapping sub-problems and suchlike (at the Wikipedia, someone like-minded has added a considerably detailed entry about this method algorithm).

After letting us listen to our voices for sometime, he gave in. A divide-and-conquer only works if the solutions to sub-problems can actually be combined to yield the solution to the original problem. Missing this crucial proviso would make nearly every problem solvable by D&C. Say, for example, the knapsack problem, or even, the map-coloring problem (i.e. coloring every country in a map such that it has a different color than its neighbor). In this case, we could just take each country separately, color it with some color and “solve” by coloring all its neighbors with a different color: combining these “solutions”, of course, is the problem.

Besides the obvious “coverpage-value” of understanding D&C better, I feel this lecture helped me mold the way I think in a subtler way.

More often than not, humans tend to concentrate on the details of a particular problem, framing it and reducing it to something that is soluble. Sure, this is a great way to solve problems most of the time. But every once in a while, this method scheme fails, and we discover that binary search is broken.

Over the past year or so, I’ve consciously been trying to “break out” of the details occasionally and it’s been very interesting. I haven’t really made any path-breaking discoveries, but it’s fun, and I’m hoping it will be profitable.

If you don’t already, you should try it too!

The computer engineering equivalent of a prank would be the easter egg– the inside joke that made it to the released product, the hidden feature that prints out the developers names, or simply the flight simulator tucked away in a mapping application.

Several well-respected hackers, like jwz, shot to Internet-fame based on easter eggs they created (jwz’s page on his about:authors egg is a pretty good read).

At large (and possibly small) companies, however, a series of events conspire and would prevent an easter egg from ever hatching. For example, you have managers whose job is to give you enough work that you aren’t idle and dreaming up easter egg ideas. Then, you have other developers who’ll see the code you add in a code-review and wonder what it does (of course, it works fine if you already have an understanding with them). Then you have testers who might just notice it and raise a bug. And we’re just talking about the process of adding an easter egg. Even if one has official sanction to add an egg, once you factor in policies and the business and legal side of things, matters quickly get trying.

Organizations as a whole simply hate easter eggs. Surely, that hate is not misdirected– an easter egg could possibly present a security vulnerability (especially if it escapes testing), attract lawsuits, or simply annoy some users. Several large products seem to frown upon the idea of easter eggs, considering them an unnecessary ego-boost. Some organizations even have a policy against easter eggs.

This state of affairs, I feel, is rather unfortunate– pranks (and in the context of computer software, easter eggs) are a good indicator of whether people who created something had fun doing so, which in turn is an indicator of how good their creation is.

An easter-egg isn’t about getting an ego-kick out of seeing your name in a released product, but really a way of having fun and looking at things differently. It isn’t for nothing that Isaac Asimov said “The most exciting phrase to hear in science, the one that heralds the new discoveries, is not ‘Eureka!’ (I found it) but ‘That’s funny…’”. Taking a non-serious look often exposes one to (possibly laughable) approaches that one may never consider otherwise (It happened to me!).

Furthermore, the prankster needs to be pretty good to get away with planting an easter egg. And I don’t just mean “be smart enough that it goes unnoticed for some time” but “be good enough at his paying job so people don’t want to fire him/her for the easter egg”.

Isn’t this the sort of people every enterprise is supposedly after?

Will encouraging people to play pranks and insert easter eggs actually benefit in the long term? Or maybe simply tolerating ones that are harmless help? I honestly don’t know the answers; but I’m wondering what people think. Pour your thoughts in the comments below!

Scratch that surface and you’ll see why demos can be tiring, frustrating events with very low RoI unless they are handled well (Sidenote: RoI is return on investment: working for Microsoft has bestowed on me a deep affection for three-letter acronyms).

Last week, I was demo-ing at TechVista, a Microsoft Research event here in Bangalore. The event was remarkably well organized, and wonderfully crowded– work we put in over the last few months was finally seeing the light of day! While I’m happy with our demos in general, the experience taught me a lot about how to handle crowded demos, and I’m hoping to share and learn more through this blog.

I must clarify this post is NOT about how to give great demos, but about avoiding common demo problems (my ultimate goal is to become the next Pranav Mistry — but I’m so far away from that goal!)

In this discussion, I’ll use “SmokeAndMirrors” as the name of a fictitious project  you’re demo-ing. Below, I talk about potential problems we’ll face demoing SmokeAndMirrors, and ways I’ve thought of to mitigate them. Please add your own suggestions in the comments.

Crowds

The number one problem with public demos are the crowds. Frequently, the demoer is mobbed. What’s worse is that people don’t arrive all at once– they keep trickling in. The traditional model of a talk falls flat: you can’t repeat since the folks who’d arrived before are bored, you can’t continue since the folks who were “late” don’t get the context you set up at the beginning of your talk.

The solution I have is to stay in a constant recap mode, briefly summarizing the talk every 15 seconds (approx): “As I mentioned to you earlier, the idea of SmokeAndMirrors is to…”.

Another help is a putting up a poster that explains SmokeAndMirrors so visitors get in context.

A related problem is that researchers (and other folks in technology) are trained to listen. This means that everytime someone in the crowd starts talking, the demo-er begins to listen, losing the flow of the practised talk, and generally making room for confusion. Should this happen often enough, the demo booth would be left with a babbling crowd of visitors discussing Microsoft-vs-Apple (or something similarly inane and irrelevant.)

In my demo, I tried to encourage people to ask questions at the end, but man, it’s hard to interrupt people when they are speaking, and harder still to listen to a question and not answer it right away.

Low attention spans

A crowd’s attention span seems to be determined by that of its most impatient member. These are the folks who will interrupt and ask  ”How does SmokeAndMirrors compare to Adobe Photoshop?” regardless of whether or not SmokeAndMirrors is related to photos. Hate them you might, but these guys aren’t an endangered species.

I think the best way to combat this is to keep the basic demo to less than an “impatience threshold”. Let me hand-waive and say this limit is around 30 seconds. 1 minute tops.

Anything more you should answer through your Q&A session at the end. Keeping the demo short also helps with the “trickling crowd” problem above.

The colors aren’t important!

This one hurts. You enthusiastically show a demo of your super-cool SmokeAndMirrors project and people get fixated on something minor and irrelevant– like, you know, the color scheme you picked, or something that bounces as you move it across the screen.

And then they’ll get distracted.  And they won’t pay attention to your demo. What’s one to do? My way is to repeatedly remind people to not focus on colors or bouncing shapes or whatever is likely to distract them. I like this method, though it makes the job tiresome, because I want my demo to look good. (Alternatively, you could make your interfaces really boring, devoid of color etc, but…so ugly!)

Visitors getting distracted is also a hint that the demo pitch is weak and needs to become crisper.

When will it be released?

If your demo is well-loved, someone will definitely ask this. Sadly for the interested visitor, you’ll rarely know the answer. I hate questions I can’t answer :X

Grin and bear it.

OMG, is it going to crash?

My greatest fear. Unfortunately, when your demo crashes; your visitors get distracted, and until you get the demo up-and-running again, have time to ask (often irrelevant) questions (e.g. your opinions on Windows 7 stability).

Why squander time? Next time, I will have a backup spiel for when the demo crashes (and crash it will: if it didn’t, we could ship it already). My idea is to use this time to make meta-points about the demo, painting the bigger picture that might be missed in the demo otherwise.

Is it worth it?

Trust me, it is. Besides providing great feedback, demos are a great opportunity to make your work understandable to the public at-large and convince them that yours is an idea who’s time has come (sorry, couldn’t resist ending the post by vandalizing a Victor Hugo quote– On résiste à l’invasion des armées; on ne résiste pas à l’invasion des idées– here is one thing stronger than all the armies in the world, and that is an idea whose time has come).

PS: The project we demo’ed at Techvista is called Digital Heritage.

Of course, there was a reason behind the question: “You know, as web search engines get better, people will stop creating links and simply use web search to locate the most relevant information [link directories, Yahoo's original business, are nearly dead today; for example]. But today’s search engines depend on links for their search quality.”

I think there’s a point here. It’s almost chicken-and-egg, but in reverse.

But then, I remembered SEO: a whole industry is out there, creating the right links! Dr H, however, differed “Well, a few years ago, when I searched for recipes, I’d find some special recipes created by people that they’d put on their homepage. Today, I reach a grocery store”.

Search engines want to make sure they aren’t being manipulated by SEO, so the practice has become a race of sorts between the SEO industry and search engines (Meta tag keywords are nearly useless now, for example). Grandmas with secret recipes don’t stand a chance in this gruesome battle.

This tussle between various entities which try and optimize search rankings for commercial interests, coupled with the tragedy of the commons (due to which “normal” people will slowly stop linking) creates an interesting scenario: I wonder if the search engines of tomorrow will be a lot less powerful than they are today. Maybe, they could reduce to a librarian of sorts– pointing you in the general direction where you could learn more, but leaving it to the reader to find the exact book she wants.

This is, of course, the opposite of Universal Search, the holy grail that major search providers are gravitating towards, but one can already see the signs of this development: when I wanted Wordpress themes for this blog, for instance, Google first pointed me to Smashing Magazine. Once at the site, I used Smashing’s search engine to find the theme (in the end I didn’t use it though: just went with a default for now)

I’m sure you’ve encountered similar situations yourself (searching for travel destinations, restaurant reviews, code samples…), and it would be interesting to know what you think of this problem too. Comment below.