I am 99% certain that the software engineers involved--that is, the ones who did the actual development of the software--had almost no say in the process that c

I am 99% certain that the software engineers involved--that is, the ones who did the actual development of the software--had almost no say in the process that created this debacle, and were almost certainly powerless in steering the project's direction. To take something from the article as an example, the QSSI executive's hedge about security not being part of his contract illustrates one of the real problems with our government contracting system. The sad fact is that it is more likely to have technologically illiterate "Business Analyst" and (cost-conscious) "Project Management" types making critical technology-related decisions about the scope of a project and contents of contracts than people who are technology-savvy, such as software or systems engineers, even if said people have some input. A companion problem to this is the nature of government contracting. The QSSI guy is just doing what contractors do: they fulfill the letter of the contract (sometimes completely, sometimes by handwaving) and then when the government complains that the product doesn't work the way they wanted the contractor wins an extension or a follow-on (paid) contract to do the "additional" work. It works like this for a reason. The "Analyst" ass-clowns in the government get better job security, because they're overseeing a project that can have its duration extended almost indefinitely. The contractor owners get to reap huge contracting windfalls. The lobbyists for the contractors who continue to bilk the government continue to get paid, and the Congressmen who the contractors buy, er, provide donations and campaign support for continue to hold their seats of power. Look it like this: from their perspective, badly run projects that don't actually accomplish what they need to are a feature of government contracting, not a bug or problem to be solved.