Re: Statement of intention
Um, no, that's not it at all.
Once upon a time, like about 18 years ago, I was hired to do "software maintenance" on a product. Well, what I received was a .zip file 20Mb in size, and that was it. The product was a gateway router, running in the background on MS-DOS. 2/3 of the code was C, and 1/3 was assembly. The compiler vendor was out of business, the software had been hacked on for a decade, there were over 100 unique compilation flags (#ifdef, for memory models, code that wasn't used, and on and on), a terrible number of global variables, structures that were accessed from anywhere in the code, and the mess was absolutely not portable to either Borland or Microsoft. The source code control database was missing, and evidently the programmers weren't using it anyways because the product was compiled from many similar directories depending on what they were kind of trying to do.
I had to get everything compiling again, and fix bugs in it. And yes, I fixed every bug I could reproduce.
So when DARPA wants a tool that can handle a mess like this, I say, "Go for it, fools!"
The closest that I've seen has been from Microsoft, with the Pex tool. The tool can follow a C# program's path, map it out, and generate tests. However, it's easy to write code that Pex can't map, and so the tool becomes useless.
Here's another couple of tools from Microsoft: Stylecop and FXcop. Stylecop works on the source code, and fxcop works on the compiled code. How often are these avoided? All the time.
The problem is not the lack of tools or methodologies, it's the lack of will to write good code. Java was supposed to be a write-once-run-anywhere solution, and provide a marvelous bulwark against malicious and heinous activities by miscreants. Now, how many times has Java and .NET been patched for security holes? Does using either result in inherently secure programs? Sorry, no, try again.