Comment by rayiner | Hacker News Reader

Comment by rayiner | Hacker News Reader

> Many hard tech founders come from academia or big company backgrounds, where projects can be expensive and slow. We help these founders shift into a much more iterative mindset so they can move faster.

I think this is key and I hope it takes off beyond YC. I used to work on a DARPA-funded R&D project in the wireless space. DARPA's culture is really cool: throw a bunch of money at PhD program managers, give them a ton of directorial discretion, and let them fund "blue sky" projects they think are really cool. But it's a very academic mindset and the mission creep is huge. DARPA kept sending us down these "oh can we do this?" rabbit holes. At one point our radio grew an expert system that processed XML-formatted regulatory directives.[1] We spent huge amounts of time doing things other than solving the core problem. A decade later consumer deployment is still a ways away. It would be so much further along if DARPA had the focus of something like YC.

It seems like a no-brainer to those in Silicon Valley that you should find a tractable subset of your problem and pound on it until you've figured it out. That's not the way the big research institutions working on "hard tech" usually operate, and it's not really how major research universities teach people to think.

[1] https://en.wikipedia.org/wiki/DARPA_Agent_Markup_Language

What do you mean mission creep and how can you avoid it when you have "blue sky" projects? As I understand it those types of projects, by their very definition, are trying to do something so unprecedented that they don't have a clear roadmap and will always go off into many tangents before circling back to their main goal. Take the moon landing for example: early rocketry pioneered technologies in chemistry and controlled explosives, material science, mathematics, and computation before the first Mercury mission to say nothing of systems engineering, a very broad field born almost entirely from the NASA space program. DARPA is the agency that takes on projects that are way outside of the capabilities of any other research organization in defense and its a lot less focused on commercializing technology than the NIH or even NASA.

The very interesting thing about DARPA is how its management is structured so differently from every other government agency. DARPA has a $3 billion budget with a staff of less than 300 people who are mostly project managers and administrative staff (compare to NIH - $30 bil/20,000, NSF - $7 bil/1,700, or NASA - $19 bil/17,000). By policy these PMs have a strict term limit of four years and the only DARPA PM I know of that served a second term did so over two decades after his first. These PMs have scientific advisory boards that don't have any term limits but the mandatory turnover for management means that they come in with clear goals and deadlines that seem to remove career advancement out of the picture (although to be fair, most DARPA PMs are way beyond worrying about their career prospects). No other government agency works this way and it has paid dividends not only for our defense but for technology and society as whole.

Unfortunately there isn't a DARPA equivalent of https://spinoff.nasa.org

> What do you mean mission creep and how can you avoid it when you have "blue sky" projects?

Imagine if during the Mercury project, someone threw in: "oh, and while we've got someone in space, we should do a spacewalk too."

Can you give a specific example as it relates to DARPA? A space walk would have been mission creep for the Mercury program only in the most trivial way because the technology was already developed by that point. The problem was the unacceptable risk and lack or reason to do any kind of spacewalk (Mercury and the mission procedures were not even remotely designed for in-flight repair).

So our project (XG) was about developing radio networks that could opportunistically use spectrum without a priori channel allocations. That was hard enough when you took into account challenging environments (terrain obstacles, jammers, etc). But DARPA decided the radios also had to be able to make decisions in conformity with regulatory policies written in this declarative XML language. It became this huge tangential AI project: http://xg.csl.sri.com/technical_reports.php.

Honestly, sounds like the side-AI project could be the exact point of a "blue sky" project but that open ended "maybe this won't result in a explicit result in this decade" ain't for everyone. Neither good nor bad.

The ability to produce AI tuned opportunistic spectrum allocation could have far reaching implications in fields outside of spectrum analysis. Many of the biggest problems faced by modern organizations is dealing with beaurocracy while efficiently allocation resources. Maybe this never lead to anything, but then again who knows if this could lead to a whole future field of efficiently scaling large organizations ... Take a look at the outputs of undirected DARPA funding and the results still bearing fruits decades later: computer animation by people like Ed Catmull (culminating in Pixar), Alan Key and object oriented programming, tcp/ip, etc. The bigger question of whether this side project could yield fruit has more to do with the type of team environment of the project and whether the pursuit came from a genuine "I wonder if...". E.g. One of the best predictors of the useful of such blue sky discovery is whether there's a large element of "this seems fun/intruiging!" as appeared to the driving motivation of Ed Catmull when he invented texture mapping.

And thanks for the links! I'm actually _very_ interested in reading these papers. There's been a lot of intruiging work and research on type-valued types (c.f. Iris programming language). But there's a difficulty of describing and translating rulesets from various vague human logic into effective computer passable rulesets.

> Honestly, sounds like the side-AI project could be the exact point of a "blue sky" project

As a separate follow up project; not as a sub-project that stalls the main project (which is how it will be done since "What else are we going to do with the money? Doing the boring work of ironing out the kinks in the main project?").

> systems engineering, a very broad field born almost entirely from the NASA space program

What's the evidence for that? The Idea Factory, a history of Bell Labs, claims that it was originally "system engineering", back when America's phone network was called the Bell System. Of course, there was a lot of overlap between Bell Labs and NASA. Echo, Telstar, transistors and so on.

DARPA does a great job when they design competitions especially. Look at what they did for self-driving cars (they held all their competitions before Google or any company was putting any effort into it). A couple years later and suddenly it's a burgeoning field and now companies are being acquired. Their competition for humanoid robots likewise resulted in teams building real hardware on a deadline with impressive results.

DARPA can be ahead of the curve. A few years ago, I met a VC that worked in the wireless sector. He seemed surprised to learn DARPA had been working on what I guess you'd now call whitespace technology back in the early 2000s. Industry interest came significantly later than that.

Though that can be a bad thing. You don't want to be in a position where your DARPA project ends but VCs aren't ready to look at you yet.

Strongly concur. In the mid-2000s, I was looking at a couple of collaborative filtering investments (in the days of RSS readers, the early mainstreaming of recommendation engines, etc.) and in doing some background / tech diligence, discovered that the entire thing had been done in the early 1980s at Xerox PARC.

That happened a couple of times during my first stint in VC in the mid-2000s -- ideas pioneered (and often reduced to practice) at PARC or other pure R&D facilities were finally finding mass-market or industry adoption.

Reply on news.ycombinator.com