5 ms·
Tell HN: The Quiet Collapse of US Defense Research Infrastructure
I've spent 20 years watching defense research deteriorate from the inside - from Naval Nuclear Lab intern to Raytheon, UARC, and now boutique contractor. What I've seen is concerning, but not for the reasons most might think.
The first wake-up call came at Raytheon. Fresh out of college with signal processing coursework under my belt, I joined a program that would balloon from $150M to $250M, ultimately requiring congressional approval to continue. The issue wasn't typical defense contractor bloat - it was a fundamental disconnect in how we approached technical work. Systems engineers would develop algorithms in MATLAB, throw them over the wall to us software engineers, then vanish to other programs. We'd struggle to translate to C++, often discovering the algorithms didn't actually work. We eventually had to pull a retired expert back to make the core algorithms functional.
The real kicker? The most sophisticated signal processing work was subcontracted out. Raytheon had become primarily a software integration shop. When I and four other recent grads in their fast-track program predicted our site would significantly downsize within 10 years, management dismissed us. Today, that campus has shrunk from five buildings to one three-floor facility. Those other fast-track folks? They've gone on to start their own companies or become tech executives.
I moved to a UARC hoping to do more meaningful work, bringing GPU computing expertise just as CUDA 1.0 was emerging. My pitch was simple: CUDA's backward compatibility meant we could double our speed every 18 months just by buying new hardware. It worked brilliantly - I even won the lab's highest award. I became known for turning academic papers into polished prototypes that management used to secure major programs. But then the system's flaws emerged. A manager circumvented my chain of command to keep me on his program. Despite delivering field-deployed systems (still in use today), when funding dried up, I was stuck. All those relationships with operators and government management evaporated. It's not even the government's fault - their hands are often tied by funding structures.
The PhD years opened my eyes further. Working full-time while completing my doctorate in 4 years, I published 6 papers, won awards, and got promoted to chief scientist at $190k. But without funding, titles mean nothing. I jumped to a boutique defense contractor, secured $2M in grants within 9 months - and walked straight into another systemic issue. I'm managing PhDs who lack fundamental signal processing knowledge, delivering sloppy work that explains why we struggle to convert to Phase 3 programs.
The current state of government ML research is particularly troubling. Everyone's working 3+ projects, spreading themselves thin. Most groups just take off-the-shelf models like Hugging Face and apply them to their specific data. Nobody uses more than 4 GPUs for training because they can't afford more compute. I watched 5 contractors tackle the same MWIR video problem, all delivering similarly mediocre results.
The solution seems obvious: instead of every group rolling their own mediocre models with insufficient resources, we need 1-2 primes building proper foundation models for others to fine-tune. Most of this could be done in the open before moving to classified environments. But the current structure of defense funding makes this nearly impossible. VC-backed defense startups aren't the answer either. They're making the same mistakes - small compute, off-the-shelf models, requiring relocation from experienced 40+ year old scientists who won't move. They're essentially just spending the money the government can't, without solving the fundamental issues.
My former students who left for industry are thriving. The system needs fixing, but I'll be joining them unless someone's building something to actually address these fundamental issues.
- aserenity 2y agoIt appears that all the emphasis defense places on breaking communication barriers in projects is completely disregarded when it comes to these particular projects.
- ipunchghosts 2y agoIf anyone's building something to address these systemic issues, I'd love to chat.
- meltyness 2y agoThere's kind of a product space to support "buyers", specifically calling out your section regarding "software integrator" vs "knowledge worker / domain expert." BTW "buy vs build" is a common engineering management language for this sort of thing I think; https://en.wikipedia.org/wiki/Component_business_model https://en.wikipedia.org/wiki/Component_business_model ... there's some silliness here in this space too since software itself is intended to already be maximally flexible; so "sellers" spending time building lots of flexibility is sort of a smell. To motivate some of the machinery, you know systemically it's kind of a no-brainer for how financing and oversight works I suppose; overseers want to see early results which you might get from a knowledge worker rehashing or tweaking an existing solution, and then integrators get to play 'pick up sticks'. So you have the integrator is the "buyer" because they have opted to defer product expertise (disregarding whether there's even any real cost, i.e., a FOSS solution, etc. "buy" meaning "not build"). The buy side has popular tools like linters, static analyzers; this is pretty huge. If you look at the "cloud native" space, treating lots of the cloud software players as "integrators" of software that's intended to be distributed, public, always-on, and at a cost of 'ad-supported' the buy side has the "Security and Compliance" layer: https://landscape.cncf.io/ https://landscape.cncf.io/ ... a lot of money is flowing there too, since it simplifies precisely what you mention there, so you're in good company. Granted, "integrator work" might be a bit less specialized than the sorts analyses these tools might perform, but it's the same problem applied instead of abstractly "domain expertise" to "domain expertise of deploying existing software solutions." It might not be popular thinking, but doc tools like CodeViz, doxygen, any worthwhile IDE, and other tools in the space are probably somewhere between the next space: OTOH managers are sort of 'friendly buyers' for the expertise of their employees, so you can look at the tools of requirements elicitation, definition, capture, scheduling, prioritizing, and lifecycle management too, thinking specifically of like stories, epics, kanban, and presumably legacy systems like DOORS, which I don't have any experience with. If you want to avoid too much philosophizing and want to defer to some pretty broad experience SWEBOK has a lot of words about this more 'pre-compiled' approach rather than 'just-in-time' approach that most agile-type firms will use for their usually simple value props. The same sorts of things might apply though; identifying whether "coverage exists" for "domain-expert produced prototypes" -- specifying the form of those, in say what you mention, signal processing. Basically, TDD -- does the shipped code match the tests? Does the integrator know enough to write such tests? Essentially using 3rd party machinery to establish acceptance criteria, and clear targets to ensure that the "buyer-builder" contract is fulfilled.