And sadly, this is endemic to a lot of industry as well, outside of pure software organizations. Leadership often doesn't understand tech well enough to make intelligent choices about what they really need, and doesn't understand why old-fashioned top-down management doesn't work well in software. Granted, in DoD, some of that is mandated by Congress, but that doesn't make it right.
FTFY. The problem is that in software, the end user often doesn't know what they want until they start seeing it. And it's hard to predict how long stuff is going to take to get done, or how much it's going to cost, because writing software well is a weird combination of empirical science and the equivalent of the art of writing a good novel.
That's why the modern approach to software is to write the smallest possible thing in a short period of time that you can demo to a user and get feedback, while maintaining an acceptable level of quality. Then you add small increments onto that small thing in equally short periods of time, but you do so while incorporating the feedback you get along the way while always maintaining your codebase in a continuously releasable state. The product is done when the end user either has what they need, or wants to stop paying. The customer should be able to walk at any time when they've decided the product (not the project, the product) is what they need.
There's a few things that you need to do this that DoD sucks at. The first is senior leaders and managers willing to take the incremental approach instead of Big Design Up Front and rolling everything up into a multi-year contract. The second is a development team that you can trust to be independent thinkers, who essentially think like O-3 and O-4 TACAIR strike leads and element leads instead of just executing the contract blindly. These folks are not cheap, and getting them doesn't lend itself to the lowest bidder. But the ROI is huge, because the proverbial aces of the base in coding can save you thousands if not millions in rework and efficiencies by getting it right the first time. And you also need to facilitate communication between real end users and those developers, not some gargantuan requirements document.
The trouble is that this works in two ways. Getting it right builds upon success, and it gets easier. But the majority of companies and government agencies fuck up software development because they refuse to do those things on some level. And then the good devs don't want to work for you. And then management says "I'm going to take charge, because I knew I couldn't trust these clowns." And the whole thing collapses in a self-fulfilling spiral of mediocrity where you end up where DoD usually ends up when they don't contract with Microsoft or Amazon. With bottom of the barrel entry-level coders writing shit for leaders and end users who don't know any better than shit. And I give you JMPS . . . I still remember the unhandled MouseOver exceptions in a production release of that POS.
