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.'"

Catch-22

[kentyman]

Revamping the software-development process creates a Catch 22: being more careful can mean missing deadlines.

That's not a Catch-22 [wikipedia.org]. That's just a tradeoff.

Good at publicising themselves

[derek_farn]

Tools are a cost effective way of checking source for lots of different kinds of problems. I have no direct experience of the Coverity tool, but see that they are certainly good at getting lots of publicity. A List of static analysis tools [wikipedia.org] is available on Wikipedia.

Re:static_analysis++

[Stellian]

Enough whith Coverity allready. It's like the 50th slashdot article that talks about this.
FYI, it costs about 50.000 $ for a medium sized project (500.000 lines), and is no more than a lint on steroids. Here [infoworld.com] is a somewhat cheaper competitor.
None of this tools is a mach for a manual audit performed by a professional.

Re:This just in:

[AcidTag]

The difference is that writing a paper that can stand a proof-read means it has one execution path, you read the article top to bottom and are done.

A program has any number of execution combinations, and without a decent test-harness some paths may not be checked. If ever piece of software written was tested in every concievable scenario we wouldnt have any bugs, when that day comes I'll be a happy coder. The more 'features' one adds to a program, the problems of detecting bugs increases. Simply creating a piece of code once that doesnt break, doesnt mean the addition of more code that does something else wont break the older code.

So for every new line of code, you have to go back and verify that all the previous lines of code have no negative outcome to the new line. So we developers use our experience and foresight to hopefully avoid this problem, but the problem can still occur... How many rev's of the Linux kernel we upto now?

But what is a Bug? Is it simply that a new piece of code was written poorly?
Is the bug the new code you wrote, or the interaction with the old code? I can write solid bug free code all day long, as long as it doesnt have to interact with anything.

Re:Good at publicising themselves

[Anonymous Coward]

I approached Coverity recently regarding their tool. It is astoundingly expensive. And that is understating it. $49,000 for a license to work on 500,000 lines of code. For one year. Thats right, after one year that $49,000 piece of software no longer functions. Ouch. If I remember correctly support is extra.

That is the pricing for the entry-level product "Prevent". The other product "Extend" is more expensive.

They do offer discounts for larger amounts of code.

We didn't purchase.

Re:This just in:

[Anonymous Coward]

'Revamping the software-development process creates a Catch 22: being more careful can mean missing deadlines.'

Not if management alots the proper amount of time to the project instead of ignoring the proper testing and extra time that unexpected problems always eat up.

Customers, refer to basic project rules:

[SeaDuck79]

Good. Fast. Cheap. Pick any two. You can define the scope, the deadline, or the budget. Pick one. Not two. Not three. One.

Re:This just in:

[kcbrown]

No point you proofreading you own code. You see what you think you've written, not what you've actually written, therefore don't spot any problems with it.

Sometimes.

But sometimes, you do spot problems. I'll often spot errors in prose I've written here prior to submitting it. It's one of the reasons I use the "Preview" button (as shocking and unconventional as that may be). I don't necessarily catch everything, but I do catch a lot.

It's the same for coding. If I go over what I've written first, there's a decent chance I'll spot something wrong. I won't necessarily spot everything, but something is better than nothing.

Back in college they made us use punch cards on a mainframe in one of our classes. I'm sure part of the reason was that they didn't (at the time) want to upgrade to newer equipment because of the cost, but another part was to force people to proofread their code before submitting it for compilation/execution. The turnaround cycle was long enough that it was worth reviewing the code in detail to ensure that it would compile and that it would do what you intended. After a while, you got good at this.

There's not nearly the incentive to do that with an interactive system, and in some ways that's unfortunate. The discipline of reviewing your code is useful. That said, the perception of improved productivity of letting the machine figure out all the problems is so great that even those who have done it the other way will naturally gravitate towards letting the machine do all the work. People are naturally lazy that way, and there's no getting around human nature.

The bottom line is that you're probably better off reviewing your own code, even if it feels less productive.