The Errant Idea

(This post is the third in a series; see also Track 1, Track 2)

Lamb was one of those groups that could almost do no wrong, from Andy Barlow’s lush production (their few nonvocal tracks are some of the most energizing and entertaining pieces in the drum-and-bass genre — e.g. Ear Parcel on the same album, Fear of Fours) to Lou Rhodes’ smoky and powerful voice, and a string of gems spread across too few albums. Bonfire is a paean to single-minded determination and refusal to be distracted by things we cannot change.  The lyrics sound better when sung by Rhodes, unsurprisingly, but:

(Excerpt)

Have you ever wondered why
those days exist
When life just seems to be
a conspiracy against you

I don’t know where
the answers lie
But I try not to get caught up
on the questions

And I burn like a good bonfire
in whatever I do
Burn like a good bonfire
and I know I’ll come through

[...]
Above all, don’t stray from your chosen path

Meaningless buzzwords last a few years at best before they lose their cachet with the digirati. So it is with the too-clever-by-half coinage “Web 2.0″, which after over three years of wide usage has overstayed its welcome. Obviously it must be replaced, and just as obviously, the replacement must be “Web 3.0″. Duh. The only problem left, really, is just determining what Web 3.0 means — details perhaps, but important. Some have taken it upon themselves to supply definitions, sometimes self-serving, sometimes vague to the point of meaninglessness, but all just armchair futurism.

Nevertheless, some themes keep cropping up. Mobile, for one. The Semantic Web, for another. It seems that in casting around for new buzzwords, it’s been a no-brainer to simply grab hold of one that’s been around a while but never materialized, even though intelligent people kept insisting it was just around the corner (kinda like AI).

I’ve long been of the opinion that the Semantic Web — herein “SW” — was clever, ambitious, and doomed to fail. It imposes structure on information rather than deriving structure from information. There’s a reason why we no longer use web directories and switched to search engines instead. Remember the original Yahoo directory? Yeah. Didn’t think so.

Even if it was feasible to impose this structure, who exactly do we expect to do it (and do it well) and then maintain it? The internet is organic and large because there’s a low barrier to entry; do we really expect every site out there to start layering a (very complex and difficult) new set of concepts and standards on top of what they already have — and everything they introduce in the future — which in many (or, likely, most) cases is completely secondary to the things they actually care about? And if they do, who’s going to get all these domain-specific ontologies (the schemas, if you will, of the SW “databases”) to interoperate — since, realistically, most sites which were at all innovative would end up with their own domain-specific ontology? The two biggest browsers on the planet can’t even get HTML and JavaScript to work consistently with one another, and getting diverse ontologies to integrate is a hell of a lot more difficult — and has to be solved many times, not once. In computer-science terms, it’s an O(N^2) problem, while getting HTML right isn’t even O(N): it’s O(1). So I’ll believe it when I see it.

Which brings up the main point of this post: I haven’t seen it. The underlying technologies and ideas are used here and there within enterprises and single applications, using rdf and ontologies to structure information internally. And that’s great; I don’t doubt that they could continue to flourish in many such niches, and provide structure that is sorely lacking today. What I haven’t seen is the emergent thing that everybody talks about: the pieces of that cohesive SW itself; actually using this stuff to expose and connect information.

But it’s not just me. Despite the futurists throwing the term around because it sounds so Next Generation, interest in the technologies themselves has been steadily declining. The graph below shows Google trends for a few SW-related keywords (ontology, rdf, and “semantic web” itself, picked for diversity: ontology is a concept, rdf is a concrete technology). Obviously this means little about the inherent worth of the technology, but search trends these days tend to correlate reasonably well with how much interest there is and, more significantly, how much a technology is actually being used.

Lo and behold, they’ve all declined pretty steadily for the last three years now (which is as much trend data as Google provides). And they’ve all declined at a pretty similar rate, suggesting that this is a real trend and not just a bias in one of the terms.

Ontology and rdf are higher than semantic web, which makes sense — they’re real technologies in (limited) use today, and do have a purpose outside of the high-concept SW.

There’s some noise, of course (for instance, a spike in the rdf curve in July 2007 correlates to news stories about the Rwandan Defense Force). There was a lot more noise when I tried to search for the Web Ontology Language, “owl”, for obvious reasons. These three terms seem to match the intended targets pretty closely, though.

Web 3.0 may be about Seth Godin’s “Web4″, or Marc Andreesen’s Level 3 Platforms, or location-aware / mobile, or who knows, maybe we’ll finally even get that 3D web when virtual worlds meet social networks. Hell, maybe it means killing off the browser as we know it altogether. Most likely we won’t know it ’till we see it. Sorry, Tim, you got Web 1.0; let somebody else have a turn.

I’d love to hear rebuttals (I’m fully expecting them from some corners). ‘Cause, you know, sometimes I’m wrong.

One of the top five rules of starting a company is that if you have a good idea, 50 other people have had it as well and a half-dozen are working on making it a reality (actual numbers subject to change on a whim). We knew that. What we didn’t anticipate is that they were working on it within a couple miles of Jectiv HQ.

Fortunately, DisrupterMonkey — whose Head Monkey we finally had a chat with earlier today — is going after a different market and has pretty different goals. Nonetheless, one might say that the core of their target technology is — mathematically speaking — a strict superset of Jectiv’s. The downside is that the way they’ve framed their problem is bloody ambitious, and will be Hard to solve well. The upside is that if they do it — and it sounds like they’re pretty much doing everything right, and are pretty bright guys to boot — then it could not only be significantly useful, but could actually shift the direction the web is taking. Or, at the very least, give the Semantic Web quite a little run for its money (but that’s another post).

And they have a mind-numbingly cool logo.  We’re jealous.

Jectiv’s a bit more targeted. Technology-wise, we’re only biting off a specific piece of what they’re going for — which is in some ways the same basic thing, really, just stripped down to its essentials — but sometimes it’s the simple stuff that has the most impact. And, like I said, we’re using it in a pretty different way; even if both companies succeeded, chances are they’d never become competitors.

Quite possibly the two companies will be able to help each other out here and there. Or at least steal each others’ ideas over lunch (muhuhahaha).

Assuming funding issues don’t prevent them from having a chance to play the game in the first place, which would truly be a shame. But then, that’s a dance for which Jectiv will get to try out its moves in a few months…

(This post is the second in a series starting at Track 1)

From Soul Coughing’s final album (though certainly not Mike Doughty’s last), we have So Far I Have Not Found The Science. The lyrics speak for themselves. This one serves as part of the soundtrack to the rest of my life, as well.

I don’t mind worry following me like a dinosaur.
I don’t fear I am descending into the molten core.
So far, I have not found the science.
So far, I have not found the science –
but the numbers keep on circling me…

This post is the first in a series spread out over… well, let’s just take it one post at a time.

Back before Moby’s (wonderfully creative) breakthrough mainstream hit Play, and long before his subsequent albums calcified into mostly blandness, he wrote some of the most deeply felt, minimal songs you can find under the (broad, vague) label of “electronic”. Many were vocal, many can be classified as “dance”, but some of his most powerful works are simple, relaxed, lush instrumental tracks.

So it is with Living (which, if you don’t have any early Moby, I recommend picking up as part of the compilation MobySongs, which has a number of other breathtaking pieces). No matter how many times I hear it, the deceptively relaxed piece hits me in the gut by the end.

From its first notes, Living jumps directly into a simple melody: a straightforward theme on guitar, backed by quiet strings and a consistent snare-and-bass drum backbone. The melody very gradually builds, is embellished with plenty of small flourishes and wandering harmonies, becomes gradually more exuberant and rich, but still maintains the theme introduced in the first bars. It builds for a full seven minutes, in a constant crescendo.

Without warning, at the 7:00 mark, it starts to cut out as though a wire has come loose.  By 7:01 it is over, and the next song has begun.

If the mortality illustrated so effectively in this song is not one of the most primal motivations to stop coasting and create something important — for instance, a startup — I don’t know what is.

We were fortunate enough to meet briefly with Jason Caplain of Southern Capitol Ventures, a Raleigh-based VC firm, and Scot Wingo of Channel Advisor (and a rather successful serial entrepreneur). They both seemed to “get” the idea, which was encouraging — especially given the brevity of the pitch. They provided some useful pointers, though I couldn’t shake a feeling they were pulling some punches on real criticism; surely, at this early stage, the idea must have some significant blindspots. Granted, they only had a few minutes to digest the plan and provide feedback. Probably the most gratifying aspect of the meeting, though, was that they both requested invites to the alpha test when it’s ready.

Already we’re seeing that the world of startups — or perhaps, at least, startups in RTP — is a surprisingly small one. Scot made a suggestion that we talk with DisrupterMonkey, as there could be some overlap between our technologies and we might be able to help each other out. Ironically, Nick Napp — DisrupterMonkey’s founder — and I had been exchanging emails already, having met through Nick’s blog, and were planning on meeting for lunch soon — but neither of us really yet had any idea what the other’s working on.

Thanks to Scot and Jason; if luck holds we’ll be darkening their doors again at some point.

I received a sad little note in my inbox this evening, thanking me for my interest in career opportunities at Google but informing me that, alas, they had no openings that matched my resume.  They’ll keep my application on file, fortunately.

This would be somewhat depressing — had I actually applied to Google.  In the real world, though, I’ve turned down no fewer than five inquiries from three different recruiters at Google over the past three years.  As eager as I might have been to work for Google, I’ve never been interested in relocating to do so.

Perhaps there’s a bug — or a confounding inefficiency — in the recruiting systems in use by the most renowned information processing corporation on the ‘net today.

Or maybe they took the recent hiring throttle a little too much to heart, and have gone into reverse, rejecting people who’ve never even applied.

Or maybe they just wanted to turn me down for a change.

Whichever it is, sounds like this relationship is on the rocks.

[Update: Unsurprisingly, the true reason is much more mundane -- the (quite friendly) recruiter replied that she'd just hit the wrong button while updating my record, and (unnecessarily) apologized.  Ah well.]

“Everything should be made as simple as possible, but not simpler.”

– Maybe Albert Einstein

One can start a technology company by spending time working on a slick pitch and pounding the investors with pavement (that’s roughly how the saying goes, isn’t it? Doesn’t sound quite right) until one is given enough money to put a team together and finally sit down and start making a product. Or — at least in the web industry — one can start making the product first, and then go after money when one has something real to show off — both for a visceral demonstration of how you’re going to change the world, but also (and perhaps more significantly) because you’ll be that much closer to revenue, have that much less risk, and hence be that much more fundable. As a bonus, you have a nice built-in Plan B: even without significant funding, you can conceivably launch slow (as long as you can beg and borrow just enough cash to cover operations in the short term), start refining your product, make connections with users, and even start making revenue.

But there’s also a pretty clear downside. If you have a good idea, a viable opportunity with the right timing and a decent market, you can be bloody certain you aren’t the only one with that idea. That means if you don’t get to the starting line before your competitors, you’ll lose first-mover advantage — which isn’t everything, certainly, but is certainly better than a poke in the eye. And for whatever method B’s strengths, the necessarily small and often part-time team means that time-to-market isn’t (usually) one of them (though don’t forget that it does take time in method A to woo investors — time not spent on making a product).

Jectiv is taking the latter path, for better or worse. But this means that time and effort are precious, and the goal is to put together a prototype with the absolutely lowest effort feasible on the shortest timeline possible.

It helps, here, if the founder is also a software developer.

So you gotta pick technologies based on how efficiently they’ll let you build a product. Agile development is the name of the game, The Simplest Thing That Can Possibly Work is your mantra. Perfect is the enemy of good enough, yada yada. This can be a difficult process for perfectionist engineers who habitually do everything in their power to make things three times sturdier and more flexible than they strictly need to be.

But then, this is complicated further by the fact that, unless dollars fall from the heavens from gushing angel investors and VCs as soon as they’re given the faintest hint of a demo, chances are what you build now is the same code that you’re going to launch your beta with, and probably your public launch, and the first few years after that… so you’re not really building a prototype after all, you’re building The Product. Just the smallest, simplest, most important subset of that product you can identify. But you’ve gotta build that subset well enough that it won’t hold you back once you do make it. It’s bad enough to shoot yourself in the foot, but doing so just before running a marathon is a Bad Idea.

So: architecture is important. Just don’t furnish any of the rooms you won’t be living in the first day.

We’ve learned some lessons already while going down this road. Sometimes shortcuts aren’t as short as you’d like (ever notice there’s no reasonable Ruby Servlet-level solution under Apache if you’re not using Rails? Ever notice JAXB and RelaxNG simply will not work together?). Sometimes the most expedient technology is simply the one you know best.

We’ll keep trying to do this thing fast, but damned if we’re not going to do it well at the same time.

Developer’s journal, September 21, 2007. First urge to refactor. Dammit.

The Brain prototype isn’t even complete yet, and that developers’ eternal nemesis, the desire to change how it works, has already reared its ugly head. We’re not a NIH-obsessed shop here, but we make a conscious effort to keep unnecessary dependencies down, both to reduce risk and — in the case of dependencies on commercial products — hold down the cost-per-CPU, as we’ll be throwing a lot of CPUs at this thing, so they gotta be cheap. So — for a variety of reasons, most of which were simply expediency-related — we’re using Java servlets and have rolled-our-own dead-simple REST functionality based on simple regex pattern matching (one of the times we’ve really wished we were using Ruby). Not rocket science — REST is simple, that’s one of its biggest virtues. Nevertheless, we just looked a bit more into JSR-311 and Jersey, and realized that despite their youth, those APIs were actually thought through rather well and could’ve saved us some minor headaches, and resulted in that part of the codebase being significantl cleaner.

But… we really can’t justify switching our code already, given that the REST frontend is already done and there are miles yet to go. Right? Discipline. Curses.

The term “pitch” has a number of meanings, several holding a great deal of weight in American culture: the initiating action of our national sport; the measure of a singer’s tone; a thick, tarry substance using in roofing and paving; or a sudden, uncontrollable, and often tragic plunge over the side of a precipice.

A startup pitch has elements of all of these.

Plus, it’s bloody hard to write one (much less present one). You have this great idea in your head, you’ve thought it over and through in an endless loop for months, you know all the wonderful and subtle and worrisome ins and outs, all the opportunities and risks and challenges it presents. You know exactly how you’re going to exploit and mitigate and attack them (well, more or less), what needs to happen for you to succeed and what to blame if you fail. And you need to take this complex web of thoughts and distill it into an eloquent, engaging, brief package which anticipates all confusions and concerns, isn’t too vague or too technical for any member of an audience, doesn’t make you look like either an out-of-touch visionary or a beancounter without an imagination, and reliably leaves your audience hungry to hear more and desperate to be a part of what you have.

I mean, it doesn’t sound hard, but actually it is, believe me.

Plus, you need two to four versions of this: an elevator pitch (one paragraph, thirty seconds), a full pitch (a dozen slides, twenty minutes; sometimes more), optionally a one-page of prose to get sent and resent (one page never looks intimidating to read), and — if you’re old-school — a business plan (which will never actually be read by anyone outside your company anyway, so you needn’t worry about your audience).

Worse, you probably need multiple sets. Most likely one for potential investors, one for prospective employees, another for partners, and perhaps a last one for customers (depends on your business, of course).

Fortunately, I’m going to describe for you exactly how to do it.

A pitch should include an overview of your business (the problem you’re solving and what you’re providing to solve it), what your market is, how you’re superior to alternatives, how you’ll make yourself known to (and deliver your product to) your customers, how you’ll make money, how you’ll implement your solution (technical and process-wise), what technical challenges and other risks you face, and what your status and plans look like. Mix-n-match depending on format and audience, of course, and add audience-specific things like what kind of investment capital you’re looking for and what you’ll do with it, or how a partnership would benefit both parties, etc.

Well, that’s it, actually. I should revise my statement above to read “I’m going to tell you very vaguely in maddeningly hand-wavy terms how to do it”. If you want more detail, do some research. There are tons of templates and examples out there for each format; read a few, learn from them, and then throw them out and write your own — there’s nothing worse than following somebody else’s template and simply filling in the blanks. Read a book — Guy Kawasaki’s The Art of The Start has a decent overview of pitching, for example. Write, distill, rewrite, repeat. Most of all, keep it brief. Concise. To the point. Don’t repeat yourself. Avoid extraneous words. No repetition, no unnecessary detail. Don’t bore your audience. If you don’t get the joke by now, please re-read the preceding seven sentences a few times. As for me, it’s Wednesday, so I’ve gotta go rewrite my pitches.

By the way — if anyone is particularly interested in Jectiv’s pitch, email me. I’ll consider it.