Hacker News Reader

Comment by bradleyjg | Hacker News Reader

I like the xkcd definition "I'll need a research team and five years" with the implication made explicit -- "and we might not figure it out."

View on HN

Yeah, this is pretty much what i'd say qualifies as hard software tech

Unlikely Google would've qualified then, but I would certainly have put Google into the hard software tech category.

If we're talking about Google before Brin's PhD thesis, I think it would have qualified. It was not at all clear back then that using backlink data would yield more useful results than mere textual analysis of page content. One can definitely imagine a scenario where you try to build a search engine based on going down the rabbit hole of natural language processing as the key feature and then end up with something that doesn't work all that great.

Perhaps I'm just not as conversant in reverse-engineering as some of the people here, but my understanding is that if a key part of your product relies on patching somebody else's software for which you don't have the source code, this is also fraught with potential dead-ends and uncontrollable risks. What if they're using ASLR? What if they change the functions involved in the next version? What if the functions you're trying to patch have side effects that you can't afford to ignore?

That's why I prefer to put the dividing line at "must figure out things by poking at them rather than by reading documentation". The definition of "research" can be pretty vague - is a security team poking at a product conducting research? How about a UX team trying to figure out how their users behave? A search team doing language modeling? All of these would count in my head, and if a startup built their product around one of these results I would consider it "hard tech", but evidently not everyone agrees.

I think Research = Observe-Theorize-Experiment works. Reverse engineering is not research because someone already has the answer.

> Reverse engineering is not research because someone already has the answer.

Someone potentially had the answer at one point. That person/organization may be dead/defunct, or the knowledge may otherwise be lost to time.

Yes, but an answer exists.

...an answer always exists, even in pure scientific research. Nothing is inexplicable.

Why not? The research just happened in grad school [1] before the startup.

[1]: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.109.4...

"Research team and 5 years" != "Two [1] grad students and 2.5 years".

Dropbox, BTW, was 4-5 engineers and 1.5 years.

[1] Actually more like 4-5, Larry & Sergey had help.

Google's other big innovation was building with commodity machines instead of high-end servers. That definitely puts them in the hard software tech category.

I'm personally sympathetic to "I'll need a research team and five years" missions. I think both university research and xkcd are great! But it's a critically different from YC's definition that:

Hard tech = "There is doubt that the technology can be built at all."

Though many pieces of technology face huge doubts, what's key is often a team can get to a working prototype or partial release in way less than 5 years! (E.g. Dropbox.) YC is exactly the type of environment to refocus a 'research style' team exclusively on demonstrable progress.

The problem with the xkcd definition (if attempted in a startup) is very few research teams can continue to fundraise for 5 years without a product or significant prototype.

A partial solution to the "doubted" tech is often good enough to build a great company.

Reply on news.ycombinator.com