DARPA’s quest for better software quality is honorable but misguided.
DARPA, the US military agency that oversees the technologies used by the military is looking for innovative ways to improve software quality. To make this happen, it’s soliciting proposals from private organizations to help them come up with new ways to make software quality and security work. The agency is looking for unconventional approaches that, as they put it, “have the potential to radically change the established practice.” DARPA says the current software quality methods don’t work well.
But is this really the right approach? Do we need innovative, self-healing systems, or should we instead take a step back and look at whether we’re even implementing our software correctly using what we already know –patterns, best practices and standards.
Let’s face it; we all know software is filled with bugs. An app on your phone crashes and you simply restart it. A website messes up and just refresh the page and forget it. People have come to expect this kind of behavior. But then something big happens that we can’t just shrug off: A major retailer’s servers are hacked, and data is stolen. Banks respond, people react, and while this was a big deal, six months later everything settles down and our lives go back to normal. Until it happens again.
Everybody agrees that this is not good, and while people may have grown accustomed to it, DARPA must have hit its breaking point as it sees systems contunually getting broken into. Now, DARPA is looking for something innovative. And when it finally establishes some new and novel ways to fix it, what will happen when those measures are cracked? Come up with even more new and novel ways?
Perhaps this isn’t the answer. Perhaps we need to look at what we have and ask ourselves: Are we truly following software engineering best practices? Are we truly capable of creating code that is reliable, secure, and stable? Is quality software possible?
Consider the reality of how systems are broken into. We hear on the news that a password file used the wrong kind of hashes. We hear that a program has a vulnerability that allows a “Shellshock” attack, whereby somebody can gain unauthorized access to the computer. Then we all install the patches.
But what are these patches fixing? An underlying bug in the encryption? No. Today’s encryption is still strong, requiring thousands of years of computing power to break. What they’re fixing is almost always problems in how the encryption was coded and implemented. They’re fixing a software programmer’s mistake, not the encryption algorithm itself.
The answer is for programmers to learn the best practices, for managers and executives to use tools that can give them high-level reports on whether the software is constructed using the best practices, sound software engineering techniques, architected well, and to understand if software developers or IT vendors are taking shortcuts. Mistakes happen, and often these mistakes are due to a programmer not being aware of a security risk in his or her code. Certain types of vulnerabilities (such as SQL injection) are easy to avoid, provided the programmer knows to write code correctly to avoid the problem.
DARPA’s mission to improve software quality is honorable but misguided. We need to continue striving towards better execution in our software, and make use of the software quality tools and technologies available to us to help us find the problems in our code, rather than simply throw away our old approaches. Only then will we finally have quality software that we all safely can count on.