I was getting out of my car when a small plane buzzed over my head. Sam was parked in a grass field amongst many other Subarus and SUVs. The clouds above were breaking; it was going to be a hot day in Boulder.

I let my gaze follow the plane as it buzzed down the field. A wide gate was set in the air like a high-jumper’s bar, but instead of going over it, the plane went below it. In the distance, I could hear a roar of approval come up from the crowd of spectators. It would have been a trivial flight maneuver for a human, but no human was at the controls: the plane was flying autonomously.

When I think of robots, I think of autonomy. Sure, remote-controlled devices may technically qualify as robots, but that’s always seemed a bit like cheating to me. Imagine my thrill, then, when I found out that one of the largest competitions for amateur autonomous robot designers would be held an hour from my home in Denver.

The Autonomous Vehicle Competition draws participants from all over the country, and indeed, the world. It’s the effort of Sparkfun, a Boulder company that supplies electronic parts and kits to hobbyists of the robot kind. The competition is split into two different challenges: one requires navigating a ground course, roughly a square 100 ft on a side in a parking lot with obstacles; the other requires flying from a judging area over about 300 feet of water, crossing a peninsula, and returning to the origin. Each run is scored according to navigation time and extra challenges completed.

About a decade ago, my friend Joey and I made a GPS-guided self-driving Lego car for a class project. It was crude and didn’t work very well, but the thrill of having wrought into existence something that could actually drive itself around — well, I was all smiles even back then. The same enthusiasm was written on the faces of the hobbyists and engineers at the competition. I’m sure the same excitement is shared by those people working on the slightly bigger toys at Stanford and Google.

A large crowd of spectators packed the viewing stands and spilled out along the safety fences and grass. They were young and old, overwhelmingly male but not wholly without female representation. Some were entrants waiting for future heats; others were simply there for a passive thrill.

I spent some timing watching the aerial competition before moving to the ground track. Much to my surprise, the plane I had viewed upon my arrival was one of just a few fixed-wing entries. Though there was one true helicopter in the mix, the vast majority of aerial bots were quad- or octo-copters.

I’ll admit that a certain part of me wanted to see a big splash in the aerial competition, but that didn’t happen: the designs were surprisingly resilient, albeit not often successful. Also, the makers were generally standing by ready to cut over to manual control should everything go sideways.

Some entries ran the course and chalked up bonus points without breaking an electronic sweat; others failed to do much more than lift off the deck, hover for a few seconds, and set back down.

Over at the ground competition, the range of entries was a diverse affair. Everything from self-balancing two-wheeled contraptions the size of a coffee cup to a big-wheel tricycle made attempts on the course.

The course proved deceptively difficult. Very few of the ground vehicles successfully navigated the circuit. For at least half the entries, that meant failing to make the first of the four turns.

Some bots slammed into the far fence. Others turned too soon. A couple spun around at the starting line and zoomed off at high speed the wrong way around the course. The defending champion’s bot got loose in the infield, leading to a college-age nerdy guy running as fast as he could to chase it down, with the bot swerving to and fro as if it were trying desperately to escape some tyrannical master.

Oh, and crashes! During the unlimited-class heat, I got to see the carnage I had paid (nothing) for: one smallish slammed itself into the far fence. Meanwhile, a large gas-powered go-kart bot gained speed off the starting line, started going for the first turn, and then apparently decided to give it a miss and accelerate into the fence — right where the small bot was hung up! The go-kart tried to get away and dragged the small bot a good 20 feet down the fence, leaving bent wire and miscellaneous bits of expensive plastic in its wake.

During a lull in the competition, I took a walk through the team pit tent. At table after table, teams (and they were teams — I saw almost no solo entries) were hunched over laptops, sifting through telemetry, tweaking code, and mending broken bot bodies. The people were as dedicated as any I’ve seen in any other competition.

And yet, the mood remained light. There was an overwhelming air of fun and excitement. Even the entrants whose bots had failed wore big smiles as they carried their creations off the course and developed stories of what went wrong and how the big victory got away. Fishing stories are not just for fishing.

Entries ranged from the simple (an 8-year-old boy made it half-way around the track with a Mindstorms-based four-wheeled bot) to the ultra-sophisticated (the university quad-copter teams running using GPS, computer vision, and other whiz-bang gadgetry). Complexity seemed to be poorly correlated to success, at least on the ground course: the slow and steady bots, apparently using dead-reckoning, generally performed more reliably than their fancier, faster, GPS-enabled, optical-sensor-encrusted cousins.

I felt more inspired than ever to make an entry for next year. How hard could it be?

 

What does your web browser think you like?

Many modern browsers, including Google Chrome, have a nifty predictive-text feature in the address bar.  You start typing, and it predicts what you’re trying to say. This works even after a single letter. The results are shaped to each individual based on one’s browsing and search histories.

So, I got to thinking: which web sites does Chrome predict for me for each letter of the alphabet?

Here’s what I found:

a – amazon.com (I recently got an Amazon Prime subscription, and it’s pretty awesome)

b – blurity.com

c – classic.wunderground.com (I like the classic interface much better than the “normal” one)

d – digg.com

e – ebay.com (A bit of a surprise, as I haven’t bought or sold anything on eBay in a while)

f – facebook.com

g – goaliestore.com

h – hipmunk.com (Best travel search site at the moment)

i – istockphoto.com (I sell some stock photos here. I also seem not to visit many other “i” sites)

j – join.me (I must not visit many “j” sites either)

k – keacher.com

l – linkedin.com

m – maps.google.com

n – news.ycombinator.com

o – okcupid.com (Still searching for love!)

p – paypal.com (About 30% of Blurity purchases are via PayPal)

q – qrz.com (Very surprised by this one — I think I’ve been here once in the past year, and the site isn’t even all that useful)

r – reddit.com

s – slashdot.org

t – theonion.com

u – uspto.gov (Google is better for searching patents, and freepatentsonline.com is better for viewing them, but only here can I view the PAIR data)

v – vail.com

w – wellsfargo.com

x – xkcd.com

y – youtube.com

z – zappos.com (Per my records, the last time I bought something from Zappos was August 2007)

 

Based on this data, what picture can we draw of me?  Maybe that I’m a tech-savvy engineer who likes to travel, laugh, keep up with friends, and buy and sell things on the internet?

The problem with this data is that it is not directly correlated to the frequency of visits. For that, it’s more useful to look at Chrome’s “Most Visited” sites, visible when a new empty tab is created.

For me, the sites are:

• reddit.com
• okcupid.com
• facebook.com
• news.ycombinator.com
• cnn.com
• blurity.com
• craigslist.org
• wellsfargo.com

Curiously, two of the entries on this list (CNN and Craigslist) were absent on the predictive list. This gets at a second problem with predictive input: it doesn’t work as well when there are multiple sites that start with the same letter or sequence of letters.

I wonder how self-reinforcing these sets of sites are. That is, am I more likely to continue to visit them because the effort required to change is higher than to not change?  It’s possible.

CNN in particular might be an example of that. Most of what they publish comes from the wires, so I could just as easily make something like the Denver Post or Reuters my hard-news mainstay. In fact, I’ve done exactly that on my phone. Still, the motivation to switch on my desktop computers is lacking.

It should be interesting to see how this changes over time. I expect that Hacker News, Wells Fargo, and Blurity will stay on the list for the foreseeable future. OkCupid may drop out if I manage to find that special guy. And Facebook? It’s an unknown. Will I still care about it in four years? Not sure. The next shiny thing might have come to the fore by then.

Six months ago, I got a scratchy cell phone call from Tyler while he was hiking at Arches National Park:

“We’re going to Mountain View!” he exclaimed.

“What?” I asked, scared I had misheard him.

“Y Combinator said ‘yes’ for our interview!” Tyler clarified.

“Woohoo!”

A week later, we were in Mountain View.  We interviewed in the afternoon, and in the evening we were rejected.  Here’s how we got to that point.

Note that I have not titled this “How to get a Y Combinator interview” — that’s a different problem.  This post is simply about what we did.  If you want a proper guide, I suggest Jason Shen’s Unofficial Y Combinator Guidebook.

Y Combinator Funding Application Summer 2012

Company name:

Snaposit

It started one evening in early February 2012, when Tyler pitched an idea to me: “Backup for photographers.”

Since we both dabbled in photography, that seemed like a real problem, and after some cursory research, we felt we could solve it.

The gist was that photographers generate so much data that it’s impractical to do backups over consumer internet connections. We polled some of our photographer friends: Did they currently have an off-site backup solution? Would they pay to have that problem solved? Encouraged by the responses, we pushed forward with our solution: Snaposit.

What is your company going to make?

Offsite backup service for photographers

We decided that our first deadline for Snaposit would be the Techstars Boulder application. Both Tyler and I lived in Denver, so it was an obvious choice. The early application due date was  February 26th, so we filled out the TS application form, spent too long over-producing an application video (which was viewed precisely zero times by Techstars), and sent it in. Fairly quickly, we got a question back from Nicole Glaros of Techstars: when would a prototype be ready?

It was a good question, because it prompted us to actually build the prototype. In a mad dash, we put something together in just a few days. The result was horribly ugly and barely functional, but with the clock ticking, we sent it along anyway. Unfortunately, it was Windows-only, and Nicole seemed to have a Mac. Oops.

For each founder, please list [various biographical info]:

tghw; Tyler G. Hicks-Wright; 2007, Stanford University, MS, Computer Science (Artificial Intelligence); 2005, Rose-Hulman Institute of Technology, BS, Computer Science & Economics (Double Major); Homepage: tghw.com [portions redacted]

teuobk; Jeff Keacher; 2009, Stanford University, MS, Management Science & Engineering; 2004, Rose-Hulman Institute of Technology, BS, Electrical Engineering; Homepage: keacher.com [portions redacted]

Needless to say, we got rejected by Techstars. We laughed it off, called it nothing more than a practice run, and buckled down so that we’d have a really good prototype to show to Y Combinator.

Why did you pick this idea to work on? Do you have domain expertise in this area? How do you know people need what you’re making?

We are both avid, published photographers, with huge photo libraries that we have not been able to reliably back up off-site. We are friends with and have worked with other professional photographers who have expressed that they have the same problem.

As the summer Y Combinator application deadline loomed, we filled out that application and made another video.

Oh, the video. We spent a lot of time on the video, which we justified by thinking that a crummy video made by people claiming to know photography probably wouldn’t be very credible.  I’m not sure that it mattered in the end, but nobody could argue that our production values weren’t high.

Please tell us about an interesting project, preferably outside of class or work, that two or more of you created together. Include urls if possible.

How about an adventure we had together instead? Like when the two of us were backpacking in Denali National Park, Alaska, where we were nearly killed by hidden waterfalls and again the next day by grizzly bears. But both times we overcame!

In the software realm, we’ve successfully created the Snaposit beta together in under a month, with each of us developing a major component.

We set up good lighting (two 500-watt halogen lamps into two silver umbrellas, one on each side of the camera, plus a large white disc reflector on the table in front of us for fill). We shot with a good camera (Canon 7D in 720i mode). We used a dedicated microphone (Zoom H4n’s built-in mics, just out of frame above us).

We did take after take. We drank whiskey. We debated what to cover and what to leave out.

Finally, after a couple hours of takes, we did the final one: the one that would become the submitted video.  Although parts of the video might seem a bit scripted, it was all improvised. Honestly, we probably would have done more takes had the camera’s battery not died about 10 seconds after the final take concluded.

Was the video kind of cheesy?  Yes.  Were dark shirts a bad idea? Sure. Did it work? Apparently.

The video (posted on Posterous) was our only real tool to gauge interest in our application after submission.  We watched the view counter slowly tick up as the days went buy.  As the views went up, so did our excitement.

Our dream came true; Tyler relayed the good news to me.  We booked flights to San Francisco, celebrated, and buckled down to really refine our demo for the YC partners.

The morning of the interview found us in the upper floor of Red Rock Coffee Shop in Mountain View.  We were banging away on the code, trying to deal with some major performance bugs that had emerged when we switched to a local demo web server.

If you’ve already started working on it, how long have you been working and how many lines of code (if applicable) have you written?

We have been working on the code for about a month. Currently, we have about 3,000 lines of Python in the cross-platform client and another 2,500 lines of Python, HTML, Javascript, and CSS in the website.

About half an hour before our scheduled interview time, we made the short drive from downtown Mountain View to the Y Combinator offices.

I’d never before been somewhere so orange.  Hundreds of young guys — they were almost exclusively male, and most seemed to be in their 20s — milled about the large common area.  Laptops bloomed from tables like daffodils in the spring.

We checked in and went through our demo a few more times.  Several other people tried to chat us up, but we politely declined.  We were focused on the interview, and everything else before then would just be noise.

Finally, the time came.  And went.  And we still were outside of the interview room.

Paul Graham came out and made himself a smoothie.  He needed a short break, he said. He was barefoot.

Please tell us something surprising or amusing that one of you has discovered. (The answer need not be related to your project.)

* USGS topographical maps in Alaska are not detailed enough to show hidden waterfalls. Discovering this fact was nearly catastrophic for us.
* The best cinnamon roll yet discovered is about 75 miles north of Fort Nelson, BC
* eBay generates almost 27% more revenue on Sundays than on any other day.

Since research has shown that judges are more lenient on full stomachs, Tyler and I thought it was great that Paul was eating something.

The interview began.  Paul, along with Trevor Blackwell and Robert Morris, grilled us on our business model over and over.  They seemed to accept our problem as genuine, but they seemed unconvinced that our solution was the right one.  Minutes went by.  I felt that I wasn’t paying enough attention to Robert, but I couldn’t seem to fix it.

More time went by. They kept wanting to compare Snaposit to Dropbox, and we kept trying to tell them that we were solving a different problem. Finally, the 10-minute timer beeped zero — and we hadn’t even shown them our demo.

We raced through the demo of our prototype, and the three YC partners seemed unimpressed.

We were ushered out of the room, and I knew that we had failed to make a good impression.  We should have been better prepared to defend our solution.  At the same time, we shouldn’t have appeared so set on our existing solution and expressed more willingness to adapt (should it prove necessary).

Our heads were swimming as we left the YC building. We decided liquor was in order.

We spent a couple hours at a bar in downtown Mountain View and then met some friends from undergrad at a nearby restaurant.  All the while, we were waiting anxiously for a phone call from YC.  It never came.

Halfway through dinner, we got the rejection email.

Tyler and I resolved to continue working on Snaposit, and so we did. The private beta led to the public beta, which gave way to the general launch. However, the YC partners’ concerns proved prescient: we had identified the right problem but the wrong solution. Not enough people wanted Snaposit.

After evaluating the opportunities for pivoting and surveying our non-customers to find out what would make them happy, we decided that there were no realistic paths to salvaging Snaposit. We tried, we failed, and we were going to move on. Snaposit will be dead by the end of the year.

In the meantime, my other photography software tool has taken off. Blurity, a tool for unblurring blurry photos, is doing great.

Tyler is also doing well, with no shortage of projects to keep him busy.

Snaposit didn’t work out, but we had a great experience building it. Interviewing with YC was fantastic, and the partners were even sharper than we gave them credit for. Was it all worth it?  Without hesitation: yes.

(For an alternative treatment of this story, see Tyler’s write-up from May and his later discussion about why Snaposit failed)

Monday afternoon, Al gave the word: “[A-Basin] will be opening for the season on Wednesday.”

In some parts of the country, that might not mean much, but here in Denver, Arapahoe Basin’s first day heralds the return of ski season.  It was to be the first American resort to open for 2012-13, helped in part by its position along the Continental Divide at around 11,000 ft.

“Want to go to opening day?” I asked Tyler.

“Yes,” he replied. And so it was settled.

After I hastily acquired skis and boots — I did a season rental the previous season, but it was too early to do that again — Tyler and I laid plans for Wednesday morning.  We hadn’t seen any solid numbers for past opening days at A-Basin, so we weren’t sure when we would need to arrive to secure a decent spot in the lift line.  We figured that arriving around 5:30 a.m. would provide sufficient buffer against the 9:00 a.m. opening time, so we settled on leaving Denver at 4:00 a.m. on Wednesday.

The alarm clocks blared at 3:30 a.m., and we got out the door on schedule.  An hour later, we were crawling up Loveland Pass amid falling snow, the steep cliffs and occasional snow plow demanding unyielding concentration.  It had been 80 degrees in Denver the previous day, but in the depth of night, 7,000 vertical feet above Denver, the temperature was only 25.  The relentless wind made it feel that much colder.

Twenty minutes on the pass, and suddenly we rounded a dark hairpin curve to find the lights of A-Basin laid before us.

We pulled into the parking lot and found few vehicles.  Those that were present were emblazoned with the logos of major Denver-area news media, including at least two satellite trucks.  The journalists outnumbered the subjects.

Giddy, we quickly unloaded our skis from Tyler’s Subaru, donned our ski boots and jackets, and clomp-clomped our way towards the slopes.  It was dark save for the lights on the snow guns, the TV lights, and one lonely Sno-Cat prowling the mountain.  We could barely make out the lifthouse, yet we trudged faithfully toward it.

…only to find that we were not the first in line.

Yes, there were others in front of us. It was 5:30 a.m., just as we had planned, and that was not early enough.

We chatted up the handful of guys by the dark lift.  How long had they been there, we asked?  The astonishing reply: since 9:00 a.m. the previous day.  Yes, the people waiting for the first chair were willing to take 24 hours out of their lives and spend it in the cold at the bottom of a chairlift.  That was more time than either Tyler or I were willing to invest in the endeavor.

Still, we were enjoying our time there.  Gradually, the darkness eased, and the first hints of daylight let themselves be known in the sky.  Fluffy clouds moved above the peaks, and dawn colored them so orange that the mountains seemed to be on fire.

More people arrived, and the maze filled out.  Several companies handed out free donuts.  Print and TV journalists worked the crowd, looking for new angles and interesting personalities.  The clock ticked towards opening.  The WiFi was turned on.

By 8:30 a.m., we looked forward and found but a dozen people in front of us.  We were queued up for the fourth chair.  Behind us, a growing sea of people.  Hundreds.  The mood was electric.

At last, slightly before 9:00 a.m., the barriers were taken down, and the crowd pushed forward.  Though the first two chairs were highly orchestrated and went to their rightful owners, the commotion that followed threw our patient waiting to the wind.

The crowd surged forward, and we found ourselves somehow bumped to the fifth chair.  A guy who had arrived after 8:00 a.m. but had snuck up the singles line made it onto the chair behind us.  One of our chairmates had arrived after 7:00 a.m.

It was madness, and I should have been irked, but… I wasn’t.  I was too giddy with excitement. Who cares if we got up the mountain 20 seconds later than we otherwise would have?  It was still skiing!

At the top of the lift, Tyler and I disembarked and ski-skated over to the top of the run.  We were in a rush; smiles were on our faces.

That first run down the mountain took just a few minutes.  Were the three hours of driving and three and a half hours of waiting worth the reward? Indisputably!

We celebrated with a beer and headed back to Denver.

In a milestone of sorts, my photo deblurring software Blurity received its first negative review today. This, after receiving numerous positive reviews on much larger sites over the past month.

While I could pick apart the author’s review, I’ll focus on two bigger ideas instead: that selling software is about managing expectations, and that selling software does not mean giving it away.

Selling software is about managing expectations.  No real software is perfect.  Real software crashes, has usability issues, and has limits in its capabilities.  Unfortunately, when users lack details about the software or don’t understand them, the expectations about the software can break free and ride well ahead of reality.  The challenge is how to keep users from being disappointed.

With Blurity, the comparison is inevitably made to the deblurring software that will “surely” be in “the next version” of Photoshop.  While Adobe did put together an impressive research demo of single-image deblurring in the autumn of 2011, they have since been mum about including the technology in commercial versions of Photoshop.  Why?  I suspect that they set expectations too high.

The most impressive images from that demo were synthetically blurred (a much easier problem than natural blur), and the deblurring results they displayed were the result of close user direction of the algorithm.  The real software, operating on real blurred images, in the hands of real users, probably can’t perform at the level of the technical demo.

The trade-off is always between perfection and shipping something at all.  Engineers and artists are notoriously reluctant to let go of anything that is not “perfect,” which is why so many products seem to die due to failure to ship.  In the case of Blurity, the decision was between shipping something that doesn’t quite meet the “Enhance!!!” Hollywood-style expectations of the populace, or shipping nothing at all.  I chose the former.

So how is a software developer supposed to keep expectations low while still running an effective sales campaign?  One way is to show numerous real-world examples on the web site, like I do with Blurity.  All of the examples are available for download in blurry and processed forms, so the user can do their own before-and-after comparison.  Going a step further, every image on the Features page also shows the exact settings used to produce the results.

Another way is to outline the limitations of the software.  This is done in the Blurity user manual.  It is also done with clear alerts display at runtime when the user attempts to do something that is not allowed.

Unfortunately, users don’t read.  I’ll admit it: I don’t always read the manuals myself.  So, I deal with this by providing great, personalized customer service.  Often times, the questions asked have already been answered in the user manual, but instead of giving a gruff “Read the manual!” reply, I simply give them the answer itself.  Quicker resolutions, happier customers.

Selling software does not mean giving it away.  If software is your business, it is there to make money. The most difficult and important change I made in the development of Blurity was to stop producing a free-trial version, and instead switch to a watermarked demo.

From April through the end of June, Blurity was distributed with a 30-day free trial. During those 30 days, it was completely unrestricted. Hundreds of people installed it, and almost nobody bought it.

I was crushed. I thought that the problem was that people simply didn’t like Blurity.

However, further investigation showed that wasn’t the case. Instead, many of the people installing Blurity had just a photo or two that they wanted to fix, and since the free trial fully met their needs, they had no reason to purchase a copy. What’s more, by the time the free trial expired, a month had elapsed, and Blurity had passed to the dark recesses of their minds — or out-of-mind completely.

My inner businessman silenced my inner engineer, and I got rid of the free trial period. Moreover, I made the demo watermark so obtrusive that there was no practical way to avoid it.

Switching from a free trial to a crippled demo was the best decision I’ve made in the history of Blurity. In the first month alone, sales increased by 2400%. Let me repeat that, just to drive the point: changing to a demo model, in which the only limitation of the unregistered program was to have a watermark on the output image, increased month-to-month sales by a factor of 24. If that was the wrong decision, then I don’t want to be right.

The heavy watermarking has been the most common complaint in reviews, and that’s fine with me.  Enough of the image is visible for the software to prove it works, and enough of the image is degraded by the watermark to ensure that there are no freebies.

The second most common review complaint? The price. Blurity used to be far less expensive than it is now, and raising the price substantially was the second-best Blurity decision I’ve made.  Blurity is priced on value, and there is nothing else on the market that can do what it can do.  While axing the free trial boosted sales volume, it was raising the price that made Blurity a viable business.

So how has that worked out for Blurity?

Great!