I don't know about this; one of the professor's big complaints was that the code he saw was sloppy and buggy. You don't need to be able to talk to people outsi

I don't know about this; one of the professor's big complaints was that the code he saw was sloppy and buggy. You don't need to be able to talk to people outside your organization to produce clean, bug-free code, you just need to be conscientious, have knowledge of good coding practices, have a good background/education in it, etc. You can learn this stuff just from self-study: there's plenty of books about it, plus you can read all about it on the internet. You're not going to learn good coding practices by going to security conferences or whatever. Bad professional code usually comes from either piss-poor management setting unrealistic deadlines so developers throw together something that mostly works as fast as possible, and/or from lousy developers who aren't very competent or motivated. This can and does happen all over industry. Now if you're talking about the crypto parts, that sounds like organizational incompetence; if there's anything the NSA should be really competent at as an organization, it's cryptography, so if they can't get that right, that's indicative of serious problems. But it's also possible the tool was designed by some crypto PhD who handed off most of the coding to a low-level lackey who wasn't very competent. If you want to know the more likely reason these leaked tools seem to suck, just go look at the article again, and look at the comments. The one comment there hit the nail mostly on the head: it's the federal government, and their pay scale sucks, and the security clearance process hinders them even further in getting good engineers. How can they possibly expect to compete with private industry with those roadblocks?