Programmers Learn to Check Code Earlier for Holes

Carl Bialik from WSJ writes "Many companies are teaching programmers to write safer code and test their security as software is built, not afterward, the Wall Street Journal reports. This stands in contrast to an earlier ethos to rush to beat rivals with new software, and, of course, brings tradeoffs: 'Revamping the software-development process creates a Catch 22: being more careful can mean missing deadlines.' The WSJ focuses on RIM and Herb Little, its security director, who '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. Mr. Little has also ramped up security training and requires programmers to double-check each others' code more regularly.'"

static_analysis++

[tcopeland]

Static analysis is great stuff. I've worked on an open source Java static analysis tool, PMD [sf.net], for the past few years and I've gotten lots of feedback from folks who have used it to find all sorts of things in their code. Just a quick scan for unused variables can yield some excellent results, and the copy/paste detector works quite nicely too. And there's a book, too! [pmdapplied.com]

Coverity's doing a nice job with their tech marketing, too - l think a couple of open source projects are using the stuff they found to clean things up. At least, there's been a fair amount of traffic on the Ruby [ruby-lang.org] core list about some things Coverity's scan found. Good times...

Well I learned that at Uni

[Yrd]

Correct-by-construction programming is a fundamental part of a proper education in software engineering, I would have thought.

Where did these people learn to code?

Re:Well I learned that at Uni

[truthsearch]

In the real world... where the client says, "I don't care about security, just get it done!" Of course they start to care after a break-in, so they have things fixed in hind-sight.

Re:I hold any bet

[NineNine]

You're right... The problem is that software consumers already have a mindset that makes broken programs OK, and the way to fix them is by buying the new version. One of the worst offenders that I've seen in Intuit. Intuit is famous for releasing new programs every single year, regardless of whether or not anything has actually changed. They're also notorious for simply not fixing old code after the new version is released, with the official response of "Your problem is fixed in the new version. Buy that one." This is grossly fraudulent, in my opinion.

The problem is that we all, as consumers, already accept this kind of shit as acceptable. I wish I knew a way to reverse this, but realistically, I don't see this mindset changing any time soon.

Re:Thinly veiled ad?

[cant_get_a_good_nick]

Seems they've been astroturfing for a while. wasn't that long ago they did a big writeup on flaws Coverity found in certain FLOSS projects. at least then they found some bugs and helped fix.

I'm all for tools like this. YOu can find a billion text editors on sourceforge.net but very few good programmers tools. Just this smells like an add for me.

Re:This just in:

[Anonymous Coward]

We were drilled to do tons of test cases.
Every different category of data structure had to be described, outlined, and an example given. This was in entry level courses. The Data Analysis and Definitions part of our assignments were pages long, while the code was rarely more than a paragraph or two.

Now people wonder why I love just putting in comments about the variables, inputs, and functions. Apparently they don't do much in a lot of places.

Re:static_analysis++

[Anonymous Coward]

> When we say we're going to prove something we actually prove it, rather than just tossing out a few random examples for demonstration.

Out of curiosity, what do you do when you can't even prove whether the algorithm halts? Like ... suppose I write a little function that counts the number of steps it takes for the collatz problem to reduce a random number to 1? ;-)

/*
  * Assume this fictional C-like language natively supports an
  * arbitrary-precision type called 'bigint'. Also, assume the
  * standard test case is a randomly generated number that has
  * at least 1-million decimal digits.
  */
bigint collatz_steps (bigint n)
{
  for (bigint steps = 0; n > 1; ++steps)
    n = ((n % 2 == 1) ? 3 * n + 1 : n) / 2;
  return steps;
}

Re:static_analysis++

[addaon]

You say "I am unable to prove this correct" and, if such a proof is required for acceptance of the feature, re-write in such a way that you can deliver it along with a proof, or demonstrate that doing so is unreasonable.