alt Hacker NewsI worked on the control systems for Predators and Reapers back in the mid and late 00s, and the inefficiencies around process were enormous. Safety is extremely important, so you expect some slowness as a result, but it got pretty extreme. I remember one time having to do 6 weeks of testing around a one-line code change because a "helpful" dev fixed a small bug that had no practical impact. Yet because it changed the release build hash, we had to go through a full acceptance test. As you can imagine that incentivized only fixing important bugs, and even those we had to consider whether it was worth it or not. As a result there were a hole pile of bugs that we (and customers) ended up just living with.
On a separate note, I'm curious as to whether AI is making an inroads in that space. I would imagine very minimal, if at all, but very curious.
Replies
cf the other thread: https://news.ycombinator.com/item?id=48845442 ; Ukraine has a hugely inventive and effective drone industry because it has to work. If it doesn't succeed, there is no Ukraine, and everyone involved in making the drones is dead, fled, in a POW camp, or sucked into the internal Russian displacement system away from their family.
By comparison, if the US products fail, there's no real negative effect on the mainland United States.
> As you can imagine that incentivized only fixing important bugs, and even those we had to consider whether it was worth it or not.
Or you're batching your releases into larger builds because you know it'll take 6 weeks to test regardless. This increases the duration of each development iteration because you have 100 things you want to do and you could do that in, say, 4x13 week efforts, but with the added 6 weeks between iterations (and possibly more after it leaves your shop) that takes a one year effort and turns it into about 1.5. So the program office decides you should do one big release each year, which also ups the risk because a lot of testing that would catch bugs isn't done until the end in that big 6-week test effort. Oops, now your 1 year + 6 week effort just got turned into 1 year + 6 week + (unknown rework time) + 6 weeks. Probably 2 years.
This is one of the reasons weapons and technology development overall explodes during wartime. Desperation is the cure for risk aversion.
It's also a reason to be skeptical of a military spending a bunch of money developing technology during peacetime. In reality the expensive stuff they went into the war with is always going to be less effective than the cheap stuff they came out with.
Life critical software that gets visibility by congress tends to be a very bureaucratic process. Your boss doesn't want your commit being the one that causes a worldwide diplomatic issue.
I assume that smaller/cheaper drones avoid a lot of this because the stakes aren't near as high and quite a bit of the development occurs in private industry first.
Why would those fixes not be batched up? So fix 20% of those and do one round of testing?
This just seems like poor planning. If it were planned better, you could group a bunch of smaller bug fixes under the same acceptance test. The full acceptance test is a good practice for safety critical systems. Project management just has to get better at doing smaller unit/int testing on each bug and then grouping those changes under the full acceptance test.
In contrast I read that Ukraine is approving 4+ new weapons systems PER DAY !!
Even when it comes to more expensive things like cruise missiles it seems the planning has to be that some high percentage of them may be shot down (and much higher for slower moving drones), so you really want them cheap and in high volume, with reliability somewhat of a secondary concern.
This is why Ukraine is making equivalent tech now for 1/10th the price. It's great to see.
This only makes sense if you have to test each fix in complete isolation which seems silly even for government employees and contractor body shops. You can't batch 80 real bug fixes and 20 "silly bug with no practical impact" fixes together?
Surely the dev wasn't able to merge that one-line code fix causing 6 weeks of testing without any other eyes on it and without someone else's PR-like approval...right?
The bureaucratic development process sounds like Autosar in automotive. I am not surprised that newcomers from USA and Chinese auto companies are able to completely dominate in software because Autosar based development has been like giving a birth to a hedgehog. Slow and painful.
a "hole pile" of ...?!
I'm surprised that someone who uses such a phrase was working on classified hardware in the "mid and late 00s".
> Safety is extremely important, so you expect some slowness as a result, but it got pretty extreme. I remember one time having to do 6 weeks of testing around a one-line code change because a "helpful" dev fixed a small bug that had no practical impact.
Not to bring Tesla into this, but the contrast here is stunning. From a component manufacturer about the mindset of Tesla:
"Hey, we sent you over the new firmware for the component, check it out." (The test suite for this component takes approximately 36 hours to execute.)
Three hours later:
"This is working so much better, thanks a lot!"
"???"
"Oh, we just flashed a car we have here and took it out for a drive."
"?!?"
Oof.
> one time having to do 6 weeks of testing around a one-line code change because a "helpful" dev fixed a small bug that had no practical impact
Roll back the change? Also, fix the approval process - no way that should have been approved.
Generally speaking that is risk management, an unavoidable engineering tradeoff. In lower stakes situations, for example a critical application or server for a small office, we let low-impact bugs accumulate: Imposing risks, and therefore eventual costs, to avoid minor workarounds and low-impact bugs is poor engineering and risk management.
Engineering and all risk management includes tradeoffs. It's easy to criticize the downside of the tradeoff - the same people criticize the reverse decision when the server (or drone) crashes - when someone is not responsible for both sides of it, when they are not accountable for their words when the outcome occurs.
That's speaking generally. It's also poor risk management to be overly safe. I don't know about the parents' situation. But drone crashes (risking humans), mission failure, $50 million losses, and associated downtime (including delays) and labor costs, seem like high costs that are worth some pain to avoid.
"Software saved the aerospace industry. Every other way of adding cost to an aircraft also adds weight."
If safety is extremely important, why there were bugs in the first place? Surely these should have been caught before code would get into main, no?
I don't really understand how any of this contributes to "defense". Sounds like "offense" to me. Just patrolling the skies over non-white countries and launching missiles at weddings. The reason the Pentagon invests so heavily in this kind of technology is our wars are so indefensible, they can't convince Americans to sacrifice blood in any quantity for other people's natural resources.
In Ukraine, the first place that was bombed was the red tape factory.
The drone industry was allowed to basically "do whatever as long as it works", consequences be damned. So they use civilian motors, batteries and SoCs, sketchy firmware with zero code inspection, and more. Does it work perfectly? No. It works well enough.
I wonder if anyone is going to learn a lesson about overregulation.
I'm not sure if "AI for red tape mitigation" is a thing, but "AI for killer drones" sure is. I suspect that "killer drones are insufficiently smart" is easier to fix with AI than "too much red tape". Because the amount of red tape, if unopposed, will expand to consume any capacity of dealing with it, AI or not.