Now, this assertion is absurd on its face, so it took me a while to grok what these veteran founders and investors were talking about. If the idea doesn’t matter, why does the application even ask for it? And even among the alums present, some (such as SendGrid) had succeeded with essentially the same concept they’d applied with. Sure, obviously the ability to execute—to write good (or, preferably, amazing) software in a limited timeframe—is more important than the idea. As one speaker put it, “An A team with a B idea is way more likely to succeed than a B team with an A idea.” But what’s this about ideas sucking?

That glib pronouncement finally made sense as the founder alums spoke about their experiences. As it turns out, most (like SocialThing) applied with an idea in a certain space (they’d wanted to create a competitor to MySpace), realized during the summer that there was a better opportunity in the same space (a utility that lets you sync information across multiple social networks), and built that instead. Aha! Now I got it: “Your idea sucks” is just a pithy way of expressing the following:

1. No matter how good your idea may be, do not regard it as sacred.
2. You need to spend time listening to (potential) customers and modifying your idea accordingly.
3. Having a good idea does matter, but only insofar as it a) shows that you are capable of generating good ideas, and b) shows that you’re interested in a market with potential.

As it happens, I read Steve Blank’s The Four Steps to the Epiphany on the flight over, on Dug Song’s recommendation. Blank’s theme is similar to the above, saying that startups should center their efforts on “customer development” rather than “product development,” lest they develop a first-rate solution to a problem no one has. To cite one of his examples: The Segway had a great engineering team, but they fell in love with their idea rather than getting feedback from the folks they were planning to sell the thing to.

So, how does this relate to Theoryville, the idea I’ve been fleshing out with my teammates since November? Based on early feedback from potential customers, I believe that our strategy should be to resegment the statistical software market into “collaborative” and “non-collaborative” software by introducing the first collaboration-oriented stats app for professional researchers and students. That’s the space we want to go into. But beyond that, our ears are open. We’ve designed a non-linear graphical workflow interface that we all think is quite clever, but we won’t really know if it solves a problem until we start showing it to people. We think our initial target market will be social scientists, but we’re also considering classrooms, and some of the folks we talked to at TS4AD suggested that financial analysts and MBA students would love our easy-to-use interface. We need to test those assumptions, and we can’t wait until the end of the summer to do so. We have to do so constantly.

I have to admit that Paul Graham compressed all of the above down to just seven words in What Startups Are Really Like, #10: Fast iteration is the key to success.

Meanwhile, following the Theoryville team’s surprise chat with Harj of Y Combinator, we’ve received more and more positive signals. First, we were invited to TechStars for a Day; so, one week from today, Noah and I will be networking up a storm in Boulder! (Tom had a conflicting obligation.) We were named as Momentum MI finalists, and awarded free summer office space by TechArb, putting us into contention for the TechArb Accelerator (this year’s successor to the RPM10). We’ve received encouraging queries from the folks at DreamIt Ventures and BetaSpring. And all the while, we’ve been building our first functional demo, set to go online before TS4AD.

On Tuesday, Noah and I had lunch with Dug Song, the central hub of Ann Arbor’s entrepreneurial ecosystem. The guy is a walking gold mine of startup business knowledge. The thing he emphasized most was Paul Graham’s highest principle of startup success: Know your customers. It’s an obvious rule, but we realized that we haven’t been giving it the priority it deserves. Sure, a working demo is nice, but input from prospective customers is priceless. We need to fill in the blank in “I’d pay for Theoryville if it let me _________,” and convince investors that there are tens of thousands of researchers with that same blank.

We also realized during our conversation with Dug that a secondary market we’d only been glancing at might actually be our primary market: education. These days, introductory courses on statistics are typically taught using Stata, SPSS, or R. Many of those students have never written computer code before in their lives, so they’re encountering both programming and statistics for the first time—a harrowing experience! Wouldn’t it be nice to have a code-free environment that could be used for rigorous hands-on data analysis in the classroom?

So, our strategy right now: Finish our rough, built-in-two-weeks proof-of-concept demo (what we’re calling Version 0.01a). Then contact as many potential users as we can (not just the handful of profs and grad students we know personally) to find out how we can make their research/teaching simpler, faster, and more fun.

And what about you, dear reader? How might Theoryville make your life better?

When I first came here, I liked to tell people that in five years I’d be an absent-minded professor, most likely of Economics. My advisor helped me to find novel areas of research, and I started perusing the literature and creating theoretical models. But I soon found that I was much more excited about building stuff that people could actually use than I was about writing academic papers. Last summer, when I built a social bookmarking app called Quocial (now defunct), I thought the two interests could co-exist. Since then, though, I’ve gradually reached the conclusion that the optimal allocation of my time is 100% software development, 0% academic stuff. Which means leaving grad school and seeking funding for my dream: To create an amazing, web-based alternative to STATA.

Now, of course I don’t expect to attract investors on the basis of my idea alone. (What do you think this is, the 1990s?) To quote a trope that’s rightly permeated the startuposphere: “Ideas are worth nothing unless executed. Execution is worth millions.” And I know I’m not the only one who’s had this idea. Someone posted a rough prototype to Hacker News just two weeks ago that was very similar in concept, in fact.

Fortunately, I have more than just the idea. I have two amazing SI Master’s students as teammates, Noah Liebman and Tom Haynes. We call ourselves Theoryville. We’ve been meeting since November to flesh out the concept and do some basic market research, and we’ve recently started pitching our idea around.

Today we got a nice call from Harj Taggar, founder of Auctomatic and currently a part of Y Combinator, asking us some informal questions about our application. One of the things he encouraged us to do was to build a demo before it comes time for him and the rest of the Y Combinator folks to pick finalists. Coincidentally, I’d told my team the same thing earlier this week: We need a demo. We need to show that we can execute.

And that’s the story so far: Leaving grad school. Two weeks to show that my team has the potential to turn our idea into a useful, slick-looking app this summer. No pressure.

But the work the Photosynth team has been doing since their acquisition by Microsoft is truly mind-blowing. I had to check my watch during this 8-minute TED talk by Blaise Aguera y Arcas to make sure that it was still 2010, not 2100.

One problem, though: It takes a few milliseconds to load up and render those fonts. That’s not so bad in itself; what’s bad is that the browser renders everything in non-Typekit fonts first, creating an annoying flicker every time the page loads as the text gets replaced by fancier fonts.

Fortunately, there’s a fairly easy solution (though not an officially supported one—see below). Just add this to your site body:

1
2
3
4
5
6
7
8
9
10
11
12
13

<body id="domain-com">
  <script type="text/javascript" src="http://use.typekit.com/KIT_ID.js"></script>
  <script type="text/javascript">
    document.getElementById('domain-com').style.opacity = 0;
    setTimeout("document.getElementById('domain-com').style.opacity = 1", 1000);
    Typekit.load('KIT_ID', {
      afterLoad: function(data) {
      	setTimeout("document.getElementById('domain-com').style.opacity = 1", 1);
      }
    });
  </script>
  <!-- content goes here --> 
</body>

Then substitute your actual domain for domain-com, and (important!) your site’s unique Typekit ID for KIT_ID. You can get this ID by logging in to Typekit, launching the Kit Editor, and clicking the “Embed Code” link; it’s an 8-letter alphanumeric combination.

Here’s a breakdown:

1. The <body> ID on line 1 isn’t just a good selector; it’s good form. The most common convention is to use your domain (with a dash instead of a dot), which makes things easier for the Greasemonkey types.
2. The script include on line 2 brings in the Typekit description of your site’s kit. You can move this line up to your <head> section if you want.
3. Line 4 makes your entire site disappear. Because this is at the top of your body, nothing is going to get rendered. It’s important that this line be here, rather than in another file or even at the foot of your body.
4. The call to Typekit.load does the actual loading of the fonts, and the afterLoad callback will be executed right after that happens. That’s when we want to make the body opaque again, right? Well, not quite. It seems that there’s a small delay between the callback and text refresh. Fortunately, using setTimeout to add a tiny delay (1ms) seems to eliminate this, finally ridding us of the dreaded flicker.

Caveat: The afterLoad event is currently considered experimental. An official solution for avoiding flicker is likely to be added in the future.

But that’s still not enough. Why navigate the depths of a file tree when you can simply type the name of the file you want? This is the most important feature an IDE can offer. In Eclipse, it’s called Open Resource. In TextMate, it’s called Go to File. In Coda and Apple’s own XCode, it’s aptly dubbed Open Quickly, and goes one step further by performing full-text search on the files in the current project using Spotlight. Personally, I prefer the instantaneous of the Eclipse/TextMate approach; but either way, it’s certainly faster than using the mouse.

If you’re a developer who isn’t using this feature, find it. It will change your life at least as much as I’m guessing Quicksilver already has.

So, I’ve decided to start cataloging these frequent sticking points. Eventually, I’d like to organize them into a book, tentatively titled The Web Application Checklist. But for now, I’m just going to post them here on an as-I-think-of-them basis, with the tag wach. These entries are rough drafts and subject to heavy revision.

Today’s item: passwords. If your application has enough of a need for security to require a password, it should require a good password. So when a user tries to create an account secured by the string 123456, just don’t let them. If their password is in the first 10,000 guesses that Password Recovery Toolkit might try, tell them to pick another. Then implement some kind of throttling and/or CAPTCHA. If you fail to do this, accounts will be hijacked. This goes double for admins: As Twitter learned, you can’t even trust your own colleagues to pick good passwords.

Each time someone picks a password, run it by the Top 500 Worst Password of All Time. Reject it if it differs from anything in the list only by one or two characters. There ought to be a good, standard, open-source library for doing this, but I’m not aware of any (suggestions?), so you might have to hack together some regex yourself.

And, for those of you who’ve never done this before, don’t forget to only store the hash in the database, and salt the hash. Here’s why.

[Update, 1/21: Here is a nice overview of security concerns for webapps, including passwords. And here is some JavaScript code used by Twitter after The Incident to reject common passwords.]

Most curious moment: An ad for bullets that are touted as both Certified Lead Free and offering Optimal Soft Tissue Penetration. I get that lead bullets are a serious environmental issue, but still, there’s something odd about seeing these two claims in the same set of, er, bullet points.

I have no idea why I received this issue. It served as a nice reminder, though: Print is not dead. It just grew a longer tail.

As with Deadwood, Ian McShane alone makes the series worth watching. But there’s something else that struck me after a few episodes. If there is a message to the series, it’s this: Everyone loves King Silas for the occasional mercy that he shows. (Most acutely, we learn in episode six that there’s an annual holiday, “Judgment Day,” on which the king hears exactly ten appeals from the lower courts.) To us, the sophisticated, democracy-loving viewers, this is obviously absurd: Why should the king get credit for rectifying injustices that he merely restrains himself from committing? And yet, any government, even an elected one, is subject to this same paradox. Having an unquestionable king is just the extreme case.

I can’t say for sure whether King Silas is intended to be the complex, conflicted, sinister yet sympathetic personification of “Big Government.” But it’s certainly possible to interpret him that way. Ayn Rand could learn a thing or two from Kings.

But then, as the millenium came to a close, and non-protocol related subdomains like webmail and blog began to proliferate, the www prefix began to fade away. To be sure, it remained on many sites as a vestigial reminder of the days of dial-up and Netscape Navigator, but most of the web’s denizens had learned that it could be safely forgotten. As hip newcomers like Twitter and foursquare dropped the prefix altogether, the augurs seemed clear: www was going gently into that good night.

Or was it?

Yesterday, someone posted to Hacker News that the domain nasa.gov is broken. You have to put www in front of it, or it won’t work. (Note that many browsers, like Firefox, automatically put www. in front of the domain you enter if it can’t reach it without it. But the most popular browser, Internet Explorer, doesn’t.) I replied that it had to be a temporary glitch—some idiot added a new subdomain to their DNS records and accidentally deleted the root!—but no, someone else pointed out, army.mil and navy.mil suffer from the same issue. It’s like they don’t want recruits who don’t habitually triple-tap ‘w’ before every web address!

Look: www has got to go. It’s a waste of bytes and time, our nation’s two most valuable resources. If you own a domain, here’s how to fix the problem:

1. Find your nameserver settings, specifically your A records. Make sure that your root domain is pointing to the same IP address as your www subdomain.
2. Redirect www.yourdomain.com/whatever to yourdomain.com/whatever. If you’re using Apache, you just need to add the following to either your configuration or a .htaccess file in the domain’s document root:

   
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.yourdomain\.com.* [NC]
RewriteRule ^(.*)$ http://yourdomain.com$1 [R=301,L]

That’s it! Now if anyone tries to use www, even in a link to a specific page, they’ll still get to the right place. It’s so easy, even a rocket scientist could do it.

P.S. If you absolutely must keep www, at the very least allow those who omit it get where they’re trying to go. To do this, just modify the instructions above by using these lines in your Apache config instead:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourdomain\.com.* [NC]
RewriteRule ^(.*)$ http://www.yourdomain.com$1 [R=301,L]

This is what Facebook does, for instance. But just as they dropped their superfluous “The” (remember?), rest assured that there will come a time when Facebook.com will truly stand alone.