[HN Gopher] A Note on the Changing Faces of (D)ARPA - By Eric Gi...
___________________________________________________________________
A Note on the Changing Faces of (D)ARPA - By Eric Gilliam
Author : rbanffy
Score : 24 points
Date : 2025-01-03 13:20 UTC (3 days ago)
(HTM) web link (www.freaktakes.com)
(TXT) w3m dump (www.freaktakes.com)
| IX-103 wrote:
| I was only involved in government contracting for a bit in the
| twenty-ought tens, but the whole bit about silly requirements and
| by picking the lowest bidder you were selecting the contributor
| that "often is the one who understands the technology least"
| gives me flashbacks to my time in government contracting.
|
| I wasn't around for the whole JTRS fiasco, but from what I heard
| this effect played out there as well. Ridiculous requirements
| such as requiring only software updates to support new waveforms
| and restrictions on SWaP as well as unrealistic network sizes
| resulted in radios so expensive they couldn't be widely deployed.
| I know some people like to point to SRW as a success coming out
| of that, but it never has been successfully deployed to within an
| order of magnitude of the number of radios in the requirements
| and resulted in a third, incompatible, radio system used by
| infantry. Meanwhile, a company that was excluded from the program
| built the radio that the military _actually_ needed, which could
| communicate to both of their existing systems.
|
| I _was_ around for it 's successor where they swapped software
| for FPGAs and made the same "software only" update requirement.
| The primary winner of the contract had no experience in digital
| logic and decided to implement the thing in MatLab (which
| provided no real mechanism for multiple clock domains or other
| features needed for high performance large scale digital design).
| Other contractors had to fit their design into this mess of a
| system. When it didn't fit in any FPGA, they opted to put it in
| an ASIC. And another of the contractors managed to convince the
| PM that their newest dev board was perfect for integrating this
| -- allowing them to pay for the internal R&D for that board on
| the project's expense (after all PCIE and SRIO are practically
| the same, right?).
|
| I left at that point because failure was the only option and I
| could make more money writing code to meet silly requirements in
| the tech sector.
| hinkley wrote:
| The lowest bidder thing has always upset me. Either they are
| delusional or they are lying. If they understand the domain,
| they are going to sell you a system they built for someone
| else. Or they think the system they build for you can be resold
| to someone with deeper pockets. In which case they will push
| and push for you not to make it too niche.
|
| Sometimes prebuilt is exactly what you need, but only
| sometimes, and that's not what you paid for.
| jazzyjackson wrote:
| The term is Lowest Price _Technically Acceptable_ , gov't
| ought to be pickier (/have more domain knowledge) with what
| is acceptable.
| jimmyswimmy wrote:
| Article is very interesting and focuses on the historic faces of
| DARPA, not really getting too much into the modern state of the
| agency. Over the past 10+ years DARPA have embraced the OTA -
| other transaction authority - as a contract vehicle to allow
| DARPA PMs additional flexibility and speed in letting contracts.
| This has allowed, perhaps, a return to more of the ideas of the
| old days in which a performer and PM might seek that "meeting of
| the minds" mentioned in the article, and issue funding to start
| work.
|
| A real limitation perhaps that DARPA has is the 3-5 year PM
| timeline. PMs start with a project and vision for their work,
| often a multiphase effort. We often joke that the challenges
| DARPA offers are not all that difficult, only the schedule is. A
| few years ago I worked on what would have been a wonderful
| project on a 2 year timeline which was compressed to half that,
| with the usual shifting sands of requirements consuming the
| majority of the allocated time.
|
| I can't say that giving PMs a longer timeframe would be a good
| thing - that 3-5 year PM clock keeps everything moving apace.
| Perhaps the longer-term programs ought to be given by the office
| directors to PMs, but then you have the disadvantage (mentioned
| in the article) of PMs having to execute a project they don't
| believe in. That hasn't worked well; disengaged PMs, focused on
| their passion projects, don't give the needed attention to
| inherited assignments.
|
| The future of the agency is concerning. Given increasing time and
| funding limitations, coupled with the Heilmeier focus, there's
| been a tremendous push towards immediate results. Which means
| simpler targets that don't provide the amazing leaps ahead that
| DARPA was once known for. Look to their current SBIR topics,
| which include one on the use of language models for suicide
| prevention, and another on processing data to generate facility
| clearances. These are not leaps ahead, but instead incremental,
| focused improvements. We once lost a DARPA proposal because our
| plan was too certain to work, they wanted more risk. Quite a
| change.
|
| DARPA still hires visionary PMs, and they have the tools again to
| realize these visions. I hope to see a return to the DARPA
| referenced in the early article. It will be fun to pitch ideas to
| those guys. I'm tired of talking to the ones who are too focused
| on today to think about tomorrow.
| jvanderbot wrote:
| The few DARPA tasks I've worked on or had steerage over usually
| involved getting results quickly and iterating. The initial
| kickoff call with the stakeholders were about shared vision,
| but then there was a quick feedback loop until a final report
| was derived from the call notes and slides.
|
| In that respect, it's a very decent way to do R&D - you have
| access to a highly motivated stakeholder with a clear vision of
| how your work fits in the larger scheme, and are allowed to
| iterate your way to a product both are proud of.
___________________________________________________________________
(page generated 2025-01-06 23:01 UTC)