In the article Tech Companies Check Earlier for Flaws, the WSJ almost does a good job bringing the need to slow down an inject slack into an organization in order to produce higher quality code. I say almost because while it hits some good points, like:
While the BlackBerry had escaped serious scrutiny for security holes, Herb Little, a RIM security director, worried the company hadn’t paid enough attention to the software that runs on the BlackBerry and other devices. “The idea was that we could be doing more,” says Mr. Little, who is based at RIM’s Waterloo, Ontario, headquarters. “We had to raise the bar.”
and
Revamping the software-development process creates a Catch 22: being more careful can mean missing deadlines.
It also has suggestions like:
Now Mr. Little uses Coverity every night to scan the code turned in by engineers. The tool sends Mr. Little an email listing potential red flags. He figures out which problems are real and tracks down each offending programmer, who has to fix the flaw before moving on.
which is only about halfway there. If you want to increase the quality of code, one way is to have more frequent code reviews. I suggest after about every word a developer types in. Surprisingly, so does the WSJ:
Since then, Mr. Ludwig has adopted Fortify software and improved communication between his team of security experts and programmers who write software. A few years ago, each group worked more or less separately: The programmers coded, then the quality-assurance team checked for mistakes. Now, programmers and security types often sit side by side at a computer, sometimes lobbing pieces of code back and forth several times a day until they believe it is airtight. The result: “Issues are being found earlier,” Mr. Ludwig says. But, he adds, “I’m still trying to shift that curve.”
Pair programming. Whole Team. Slack. Guess these things do make sense.