Skip to content
loading...

re: The Hawaii Missile Alert Was the Software Developer's Fault VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Firstly, I totally agree, this was far more a failure of design than operator. Secondly, it wouldn't surprise me in the least if the design failu...
 

One can only hope we learn from this, but I could see a possibility where this could make requirements even more rigid in the ways you've described. We need checks and balances that account for actual risk and a design process that can improve with feedback and testing.

It seems like some organizations are hamstrung into no-win scenarios.

 

One of the things FedGov has always struggled with is how to enact "checks and balances" that don't ultimately become /rigid requirements/. There are a lot of complicating issues in government acquisition, and political maneuvering can completely crater otherwise great ideas (this is true at companies, too, but I would argue is less prevalent).

It's worth noting that the National Defense Authorization Act of 2018 actually has a section devoted to piloting an Agile development & acquisition process for defense software systems to address a slew of issues, including the one we are discussing, here.

All of Subtitle H in the NDAA-2018 is relevant for people with an interest in how the FedGov handles software, but Section 873 specifically lays out the Agile Development initiative:

congress.gov/bill/115th-congress/h...

code of conduct - report abuse