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

Comments

This just in:

[r_jensen11]

Writers are encouraged to proofread.

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:This just in:

[orielbean]

This just in after that : Business models sacrifice quality for speedy delivery of product. :-)

Re:This just in:

[Andrzej Sawicki]

You have no idea how insightful you sound to a translator...

Re:This just in:

[Anonymous Coward]

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.
The trick is to get 2-3 other people to review it.

1. The earlier you spot a defect, the cheaper it is to fix.
2. Test results are only as good as the test code written.
3. Edge cases don't normally show up in test code. Test cases are typically designed to show that the code works, rather than finding the boundary where it fails.
4. You can suggest better ways of writing the code/learn new tricks during code reviews.

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.

Re:This just in:

[Anonymous Coward]

Not only that, but this isn't a catch 22. It's called a tradeoff, of course being more careful requires more up-front time and a bigger budget. And management would rather see late shipping than going overbudget, as customers are probably already sold on the product, or in the case of custom work the software is already paid for. The loss of respect your company recieves is something that can be passed off to someone else. Going over budget is something a manager is held accounted for immediately.

What's the saying: Quick, Cheap or good: pick two. (And actually, you can sacrifice two of those to excell in one area. Low quality and you get it whenever, and it can be extremely cheap: picture bargain stores, dollar stores, overstock stores etc and the merchandise they carry. Very high craftsmanship merchandise takes time to make and the materials can be quite costly. A microwave burrito takes very little time to get ready to eat, but costs more and is not as good healh or tastewise as a home-cooked meal.

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: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.

Re:This just in:

[mattyrobinson69]

Thats true, sometimes, if i'm having problems with an 'unfixable' bug, I get my non-programmer girlfriend to read through my code, she understands the basic, like every ( should have a ), every { should have a }, a { is not the same as a (., almost every line should end with a ; (presuming most lines have that), if she makes a mistake and thinks and if (a = b) { should have a ;, its no big deal.

She finds a fair few bugs that way. Like i said, she's not a programmer, far from it.

Re:This just in:

[milimetric]

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

He keeps using that word. I do not think it means what he thinks it means.

Re:This just in:

[Psyonic]

I hate to nitpic, but I have to object to your statement that, "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." That would be true if they all got fixed, but having worked in the business for a little while I can say that most companies know of hundreds, perhaps thousands of small bugs in their code, but they just don't know the manpower or motivation to get them all fixed.

Re:This just in:

[geekpowa]

I think that comparing software review to proofreading is a highly abused and inappropraite analogy.

Unlike writing prose, setting down human thought onto paper, writing code has simple, measurable and testable outcomes and objectives that the writer should be able to evaluate with ease. Consequently reviewing and testing your own work does have alot of value. Sure, getting someone else to look at your code usually has even more value because they are likely to find things you are blind to at the time. Self review is still a valid tool in a suite of possible QA practicies that like all tools has its place which you pick and choose from based on the balance of risks+costs+consequences. Self review usually comes down to how much pride you take in ensuring your code actually hits the intended target as opposed to throwing something that barely compiles over the fence for QA to deal with.

Re:This just in:

[Anonymous Coward]

The trick is to get 2-3 other people to review it.

I use 2-character variable names, no whitespace, and don't comment my code, you insensitive clod.

Have some common courtesy for christ's sake.

Re:This just in:

[readin]

The earlier you spot a defect, the cheaper it is to fix.

On the other hand, defects are a lot more expensive to spot earlier in the process. It's much tougher to find a flaw during design than during coding, and tougher to spot a flaw during beta testing than during coding.

Re:This just in:

[StrawberryFrog]

3. Edge cases don't normally show up in test code. Test cases are typically designed to show that the code works, rather than finding the boundary where it fails.

It depends on how you test, doesn't it? Edge and out of bounds cases don't normally show up your in test code. You know this, so fix it.

static_analysis++

[tcopeland]

Static analysis is great stuff. I've worked on an open source Java static analysis tool, PMD, 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!

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 core list about some things Coverity's scan found. Good times...

Re:static_analysis++

[Jonboy X]

Umm, about your comment: The link goes to a blog entry of yours about the inefficiency of using StringBuffer.append(String) to append a single-character string instead of just using StringBuffer.append(char). Sure, it's a good idea, but there's another kinda-orthogonal piece of advice that will likely improve runtime performance a good bit more:

The vast majority of the code that uses StringBuffer could save a bunch of time by using the new-ish(JDK 1.5) StringBuilder class, which has the same API but is not internally synchronized. This translates to a runtime savings of approximately a KAJILLION percent by avoiding the horrendous synchronization overhead hit when the StringB*ef in question is only being used by one thread. It's very similar to using an old-skool Vector when an ArrayList will do just as well and not slow down your code.

Like I say every thime this kind of thing comes up, Java isn't slow (any more), but we're certainly not helping matters with this kind of sloppy coding.

Also, back on topic, try writing financial software some time. It's like a different world. Everything is unit tested, and the unit tests don't so much check for bugs as prove that your code works. That way, when a million-dollar bank wire doesn't go through, you can prove that it's not your head that should be on the chopping block. It's actually kind of refreshing knowing that any code you touch is pre-vetted so you don't have to worry about trusting it enough to build on it.

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 is a somewhat cheaper competitor.
None of this tools is a mach for a manual audit performed by a professional.

Re:static_analysis++

[nogginthenog]

Copy/paste detector? I don't like the sound of that. I could be out of a job :)

Re:static_analysis++

[Coryoth]

If you want a truly powerful Java static analysis tool consider ESC/Java2 which includes not just the usual extra static checking you would expect, but also includes a theorem prover which can provide warnings for all kinds of deep and subtle errors. Read through this presentation (warning PDF) to get an idea of exactly how many things ESC/Java2 can catch, including warnings about race conditions and deadlocks. If you want powerful statsic analysis of Java code ESC/Java2 is definitely the way to go.

Jedidiah.

Re:static_analysis++

[Coryoth]

Also, back on topic, try writing financial software some time. It's like a different world. Everything is unit tested, and the unit tests don't so much check for bugs as prove that your code works.

Unit tests don't prove your code works any more than drawing a few right angled triangles and measuring the sides proves Pythagoras' theorem. If you want to prove your ode works you use a theorem prover. To do tht you usually need to provide more detailed specification (beyond just type signatures) about how your code is intended to function. That tends to be more work, though if you really need to know your code is going to work it can often save time in the long run (over ridculously long and exhaustive testing). There are things out there that provide toold support for theorem proving aout your code: SPARK Ada along with the SPARK tools provides a powerful theorem prover, and HasCASL with CASL tools (including the HOL theorem prover) provides string theorem proving for Haskell. Even ESC/Java2 utilises a theorem prover (called Simplify) to provide extended static checking of Java code. I'm sure there are more examples.

My point is not that Unit testing is bad (it's very good), but that you shouldn't overstate its effectiveness. Unit tests are a great way to provide a reasonable degree of assurance that your code will hopefully ork as intended. It isn't a substitute for actual assurance however. It really depends on exactly how sure you need to be - how much an error will cost, and whether that can be tolerated.

Jedidiah,

Re:static_analysis++

[Anonymous Coward]

You fucking scum. Stop advertising your book in every post you make.

Re:static_analysis++

[blandarfleck]

PMD's an amazing tool - In v3.6 there's the ability to scan JSP's, I've written an entire suite around secure coding guidelines using both the Java and JSP engines.

Re:static_analysis++

[mattwarden]

None of this tools is a mach for a manual audit performed by a professional.

At $1/line, not everyone can do this.

Re:static_analysis++

[Jonboy X]

Let me guess: you've never worked in industry, have you?

By "prove", I mean to present evidence to someone that will cause them to believe whatever it is that you're proving. This of course depends both on what you're proving and whom you're trying to convince. The unit test may not convince you that my code is "correct", but it will convince my boss not to fire me.

It's not all about satisfying your theorems, buddy...

Re:static_analysis++

[Herkum01]

A dirty little secret for Perl has been Test::Devel. As you write your tests in Perl collects stats on what has been called in your tests, and has what not. An excellent book for learning about Perl testing can be found here Perl Perl Testing: A Developer's Notebook

Re:static_analysis++

[Coryoth]

I've worked in industry as a mathematician. When we say we're going to prove something we actually prove it, rather than just tossing out a few random examples for demonstration. Given that a piece of software is, at its heart, just a lot of mathematics, and the fact that it really is possible to prove things about code in the real sense of the word, I would be very careful about saying you "prove" your software works.

Jedidiah.

Re:static_analysis++

[tcopeland]

> using the new-ish(JDK 1.5) StringBuilder class

Sounds like a good rule for the migrating ruleset!

Re:static_analysis++

[Anonymous Coward]

You are both arguing about things that can be the same. You can PROVE something by exhaustive case. And really good unit testing is exactly that, exhaustive. Also note that proving your code works as intended means proving it meets requirements. Requirements can often be proven simply by test case analysis and often can not be proven by theorem. For example, proving that your code will run on a fully loaded system doing X, Y and Z in time A 9 out of 10 times is a perfect case where you need to run it to show it. It would be nearly impossible to generate a proof that proves that due to the number of variables.

In short, some times proving something IS unit testing. Sometimes it isn't. Knowing when it is and isn't is key to using it correctly.

Re:static_analysis++

[Skim123]

Your post brought back a flood of memories from grad school that I would have cared to have forgotten! :-) (Namely, having to spend a semester on exploring correctness theorems, which are about as exciting as spending a week to prove that paint will dry when it would clearly be more entertaining to just sit there for a day and watch it dry.)

Re:static_analysis++

[Jonboy X]

TFA is about software engineering, not mathematics. When I used to word "prove", I used it in the software engineering context. Just because you personally interpret that word to mean something that I did not intend does not imply that I misspoke. Neither meaning is the "real" sense of the word; the intent of the speaker is usually obvious from context.

Software is not "a lot of mathematics". It is a methodology for getting computers to do what we want them to do. It is an engineering discipline. Mathematics is a mental representation of reality. 5 pixels on a screen are real things. The 5 key on a keyboard is a real thing. The number 5 is just an idea.

Re:static_analysis++

[Anonymous Coward]

Apparently you haven't worked on anything more complicated than a raytracer, because to create a constructive proof of correctness of most software using formal methods would be rather time-consuming. Perhaps if you look at some of what they actually using automative theorem provers for, you'll shoot yourself in the face and do us a favor. Or I guess you can write more crap on K5 highlighting that your mathematical education is superficial.

Re:static_analysis++

[TheGreek]

You should be.

Re:static_analysis++

[Anonymous Coward]

Isn't engineering the application of mathematics? :)

Re:static_analysis++

[discstickers]

Oh right, computers run on ideas.

All code is mathematics applied and thus can be proven or disproven to work in the way it was intended.

Re:static_analysis++

[ajbajb]

As Gödel's incompleteness theorem clearly showed. Um, wait...

Re:static_analysis++

[IamTheRealMike]

FYI, it costs about 50.000 $ for a medium sized project (500.000 lines)

Yes it's incredibly expensive. Yet, plenty of well known companies pay for it, so I suspect it's worth it to them.

is no more than a lint on steroids.

Er, no. No, no, wrong, no.

I've got access to the Coverity results for WineHQ. It's already found many problems that evaded both manual code review and unit testing. Its rate of false positives is remarkably low once properly configured. A lot of these problems would only occur in obscure circumstances or on error paths - but these are precisely the kind of errors that unit testing tends not to reveal. It can detect problems like race conditions or memory leaks that lint cannot. The recent X security bugs were revealed by the tool first.

I've seen tools like this before, but not one as good as this. I've never used competing commercial products, so cannot speak as to their effectiveness, but for a large C++ codebase I would certainly be happy to have such a tool helping me out.

Microsoft have used similar programs developed by MS Research on the Windows codebase for some time now and they're apparently very effective. Quite a lot of security problems revealed by them were silently fixed along with other problems in updates.

None of this tools is a mach for a manual audit performed by a professional.

Totally wrong. Every patch that gets checked into Wine passes code review by at least Alexandre who is without question the best programmer I've ever met. He is easily as good as Linus but his much quieter and more conservative personality means he doesn't get Linus' press attention (a good thing, imo). And all the patches are posted to a public mailing list where several other people can and do review patches too.

Static analysis can reveal problems that simply don't get spotted by the human eye because they're too complicated to follow, because they occur in very weird situations, or because the code evolves over time under the direction of many different people and inconsistencies creep in.

Re:static_analysis++

[Jonboy X]

Nah. Engineering used to mean something along the lines of "applying scientific and mathematical principles in order to design useful stuff", but now it's generally tossed around to mean "building useful, complicated stuff". Again, it depends who's using the term and in what context.

Re:static_analysis++

[Anonymous Coward]

Dear Sir, how dare you introduce facts when it is well-known that my personal opinion is what matters?

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.

Re:static_analysis++

[bugg]

I know plenty of software engineering folks- that is, folks that are pushing hard for the acceptance of software development- as a full fledged branch of engineering- who would cringe at your definition of the word "prove" with regards to software engineering. Proving code is a relatively hot research topic in software engineering precisely because it's something that is rarely done and difficult to do. It's not typically done in industry.

Our math friend was right to say that arguments that your code works do not constitute a proof. What needs to be pointed out, however, is that it's not currently cost effective in the industry for most programs to actually be proved.

Re:static_analysis++

[Anonymous Coward]

TFA is about software engineering, not mathematics.

See, and that misunderstanding is the fundamental reason, why YOU cannot prove anything about YOUR programs. You'll always stumble in the dark, test code, "convince" people that it works, then act all surprised if it doesn't. In a more sensible world you would be kept away from sharp knives, open fire and compilers for your own good. The only reason you can get away without knowing what you're doing, is that you don't have to assume responsibility for failures of your code.

Re:static_analysis++

[Coryoth]

I never said proving theorems about your code was easy, and I agree, for a lot of projects it isn't going to be the cost effective way of doing things. On the other hand there is a reasonable amount of middle ground, and increasing tool support for actually doing some degree of theorem proving. ESC/Java2 is a great example of this - it's not about completely proving your code correct, its about using extra specification to run a theorem prover over parts of your code and provide warnings about all the possible corner cases and implicit assumptions made - essentially it is just extremely powerful static checking, made all the stronger by actually using a theorem prover. Certainly that level of checking is reasonably cost effective for any Java solution where bugs are going to be costly (like security or financial software), and because of the way it works it can scale down to projects where assurance isn't that important: putting less explicit annotations in simply means the static checking provides less assurance, but it still does a good job... and running ESC/Java2 over your code generally takes no longer than compiling it, so it can definitely be worth doing.

Jedidiah.

Re:static_analysis++

[Dan Farina]

There are a couple of bundles of lecture notes (#41 and #42 at http://www-inst.eecs.berkeley.edu/~cs164/sp05/lect ures/index.html) about proof checking in programs. Simply put, solvers can't handle programs of normal size in industry. Proof CHECKING, on the other hand, is quite fast, but that means the programmer has to provide a proof, which the slides show can get quite tedious for even small examples.

Re:static_analysis++

[Anonymous Coward]

Proof in software engineering means exactly what Coryoth is talking about. Unit testing, static analysis, and so on, or not proof techniques. Just because you how to write a little code does not mean you are a software engineer kid.

Re:static_analysis++

[nuzak]

Like I say every thime this kind of thing comes up, Java isn't slow (any more), but we're certainly not helping matters with this kind of sloppy coding.

Amen to that. Apparently no one at Sun got the memo though when they designed these craptacular libraries in the first place. Saddling us with locks, locks, locks, locks everywhere we look because it assumes you're using shared state in the first place -- even if there's not a thread API method to be seen in the app.

The JVM is not slow. Java the language is still slow. For the developer, and because of the cruddy foundation libraries that are somewhere south of NIHCL in quality.

Re:static_analysis++

[Schwarzchild]

When we say we're going to prove something we actually prove it

I'm not so sure about that. A proof is usually a series of statements that convinces somebody that something is true. Because of this there are many proofs that are wrong. If someone were to prove something it would be more likely to be correct, that is you actually proved it, if a series of formally specified steps were taken like in a declarative language such as Prolog or something of that nature. There is at least one project that is attempting to provide a rigorous framework so that mathematicians can write something more exact than "yes, it clearly follows..." when in fact it may not follow at all.

Re:static_analysis++

[Anonymous Coward]

What needs to be pointed out, however, is that it's not currently cost effective in the industry for most programs to actually be proved.

Which is chiefly because industry does it all backwards. They hammer at the code without much thought until it compiles, then try to prove it correct. That will never work. It can't work in general (Gödel says so) and it will be hard if it works.

Instead, write a program along with the proof of its correctness. That's far easier, always possible, and easily checked by a machine. But that requires thinking ahead, and there's not much thinking done in industry these days, let alone thinking ahead.

Re:static_analysis++

[backslashdot]

Can PMD vulnerability checking? Can PMD be used to find source code vulnerabilities? For example can it be used to detect if Cross Site Scripting can be exploited on a servlet? Or SQL Injection?

This is what security oriented source code analyzers (such as those from fortify software, ounce labs etc) do.

These commercial tools are REALLY damn expensive so it would be great if there were open source alternatives that can plug into an IDE such as Eclipse etc like the commercial ones do.

Re:static_analysis++

[tcopeland]

Check out Joseph Hemler's "Network Security Tools" book referenced here; it's got a chapter on using PMD to do just that.

And yup, PMD has an Eclipse plugin; docs for installing it are here.

Re:static_analysis++

[Coryoth]

http://us2.metamath.org:8888/mpegif/mmset.html

Re:static_analysis++

[Anonymous Coward]

To do tht you usually need to provide more detailed specification (beyond just type signatures) about how your code is intended to function.

Of course to be REALLY correct you'ld need to prove that this more detailed specification does in fact meet the requirements, and then you'ld need to prove that the requirements are actually what they should be. Ultimately there can be no proof without accepting that the assumptions that the proof is based on are true; in the case of software engineering the assumptions are the requirements specification.

Real world experience has shown that most of the time requirements are misunderstood, meaning that, at least in the initial stages of a project, sloppy code is less of a problem as it is used as a means to discover more accurate requirements.

Hence the focus of Agile methodologies that aim to continually put to test the theory that the requirements are correct. Not that I'm undermining mathematical proofs, just that if the requirements are fuzzy then the proof is not that useful; nor am suggesting that Unit testing alone helps much, its the process of discovering requirements that's the challenge.

Security adds an extra difficulty, especially since often security requirements are also not clearly specified (often nonexistent), but thats no excuse to write code that is trivially shown to be flawed securitywise, so any move to make developers think about security as they write code is a good thing.

Re:static_analysis++

[Coryoth]

There really needn't be any clash between proper requirements specification and agile methods. As you point out, a lot of the time agile development offers a productive way to explore and refine a set of requirements. And providing you have a decent means for properly (hopefully formally) expressing requirements it shouldn't be too much effort to use an agile process to start with a very loose high level set of requirements and refine it into something detailed. Simply having requirements and checking against them (potentially using theorem provers if you have suitable tool support) during agile development can help elucidate how requirements need to be refined by helping to highlight unanticipated corner cases or inaccessible functionality. In many ways formal requirements specification with static checking via theorem proving goes hand in hand with agile development and the usual unit testing. It's an extra power tool for your toolbox.

Jedidiah.

Re:static_analysis++

[Captain Zep]

All code is mathematics applied and thus can be proven or disproven to work in the way it was intended.

In theory - yes, in practice - absolutely no way.

Before you even begin to think about proving your code, you'd have to start out by proving that your compiler, and every library you are going to use does exactly what it is supposed to, and whilst you're at it, prove from basic physical principles that your hardware will do what you think it will. If you don't bother proving the foundations, but just assume that they work based on past experience, then there's no point proving what you are building on top of it. There's a world of difference between an abstract algorithm, and an implementation of one.

You're also assuming that you can get a completely defined, totally unambiguous specification of what exactly a piece of code is supposed to do in the first place. And that's an immense assumption, because people who want code don't know exactly what they want, only 'sort-of' what they want. Some of what they want will be directly contradictory. And they'll keep changing their minds as well.

The reality is that it's not practical to prove that real code is correct for anything even remotely complex. So what happens is that it gets tested until we're reasonably confident that there's nothing seriously wrong with it. The degree of testing depends on the application.

Yes, claiming that a piece of code is proven because it passed a bunch of tests is wrong. But complaining that people don't actually prove their code is completely unrealistic.

If you think you can do it, you should be able to find extremely well-paid work working on development of safety critical systems.

Z.

Re:static_analysis++

[yerfatma]

You can PROVE something by exhaustive case.

No, you cannot. Prove a negative that way.

Re:static_analysis++

[GileadGreene]

And really good unit testing is exactly that, exhaustive

That is blatantly false. Almost any non-trivial piece of software has far too many possible input and output values to perform truly exhaustive testing. What unit testing can do is test "representative" inputs. But, unless you've done some rigorous analysis of your code, there is still a leap of faith there that the "representative" inputs do actually represent input equivalence classes for the program in question.

Re: static_analysis++

[gidds]

While StringBuilder is neat, it may not give much improvement for long.

According to this, Sun's next JVM (1.6 'Mustang') performs escape analysis. For example, if it can see that a StringBuffer is only used locally in one thread and never 'escapes' to the heap, then it knows no synchronisation will ever be needed, and it can bypass all that, effectively reducing it to a StringBuilder anyway. Mustang can also change lock granularity, move stuff from the heap to the stack, and make many other optimisations.

Tony Hoare said (and Donald Knuth quoted) that premature optimisation is the root of all evil; 'premature' is starting to look more and more like 'by the programmer', as decent compilers and runtimes start to do a better job of it than we can.

Plug

[locu]

Time to buy Coverity stock? =)

I hold any bet

[Opportunist]

After missing a few deadlines, the marketing goons will push to abandon security for more crap on the shelves.

After all, that's how the software market works. People buy anything. "LOOK! THE NEW (insert program/OS name here)! I MUST HAVE IT!"

Stable?
Secure?
Mem-leak free?
In one word: FINISHED?

Who cares? It's new, it's shiny, it's been all over all the mags and preview pages, the hype is on, WANNAHAVE!

And as long as we keep buying the unfinished crap, it won't change.

Yes, I'm sure everyone in the tech departments would see this as the right way to go. Test your software, preferably during development, not afterwards. Go through memleak tests, go through stability tests, have some experienced whitehats poke at it, and if it survives, let it go into beta.

If anyone gets that idea past marketing, I will bow down to him.

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:I hold any bet

[Gnavpot]

After missing a few deadlines, the marketing goons will push to abandon security for more crap on the shelves.

Is it a fact that early testing will delay a project?

I must admit that I don't know much about large software development projects. But I do know a lot about large development projects in my own profession. It seems that any problem which was unresolved/ignored/insignificant during early development will turn into huge problems a few days before a deadline.

Are software projects different? I would think that early warnings about bad coding practices at least would make a programmer change his coding habits so he doesn't make the same error again and again and finally has to correct it in 200 different parts of the code after the final quality check.

Re:I hold any bet

[Anonymous Coward]

"I will bow down to him"

You won't have to. If your software company did all that, it'd be bankrupt before you'd have time to.

Re:I hold any bet

[bladesjester]

Unfortunately a lot of (bad) managers don't judge on quality. They judge on lines of code or features that someone produces. The mentality is "get it out the door and worry about the nitpicking later" (and later never comes).

While you will never fix every single bug and not all bugs make sense to fix, this practice leaves a lot of bugs that should be fixed.

Re:I hold any bet

[Fordiman]

Hold on... you BUY software? Do you work as IT for a company or something?

Seriously, I haven't bought a piece of software in years... Not that I have any commercail software, or anything. I'm all OSS at home, and at work, there is no non OSS user (read: me) installed software either.

Meanwhile, I just bought a sweet used small-form 933MHz Dell to replace my old 500MHz Dell. Not much of a step up, but lets face it: I don't use this thing for gaming.

Re:I hold any bet

[Opportunist]

If the alternative is early testing or no testing, then yes, early testing delays a project.

Re:I hold any bet

[Fordiman]

Acutally, I haven't bought any in years.

Playing NES games on my GBA requires no recently purchased software. I have an old NES with games I bought in the late 80's/early 90's. I download the corresponding ROMs to those games, place them in PogoShell (an OSS project) and upload them to my GBA's X-ROM cart (a commercial product, but hardware) using a non-open freeware driver for it.

Now, what were you saying, Troll?

Re:I hold any bet

[Kjella]

Acutally, I haven't bought any in years. I have an old NES with games I bought in the late 80's/early 90's. I download the corresponding ROMs to those games

Well, I'll excuse the troll. You're not purchasing games, you're infringing on copyright. At this point you're going to quote me several quite valid justifications, but it is not the law. Whoever you downloaded it from doesn't have distribution rights, you don't have reproduction rights and in any case a copy of an illegal copy is an illegal copy.

Re:I hold any bet

[Fordiman]

I assert that downloading is not illegal if I already posess a licensed copy of the game, but I won't debate that.

If I'm guilty of infringement, I can't give a shit. Legal or not, I don't believe that copyright should be binding past ten years - check my past posts, I've got a record of saying five-ten should be the copyright limit, and I do live by that.

Ever read 'The Moon is a Harsh Mistress' by Robert Heinlein? In that book, the character Bernardo De La Paz states his political 'affiliation', which pretty much sums up how I feel about the law.

Re:I hold any bet

[thePowerOfGrayskull]

Yes, early testing (compared to no testing) will delay a project. Those small issues will still exist, but they will be discovered in a production environment -- in other words, /after/ the deadlines have been met, which is all most management cares about.

Re:I hold any bet

[TheGreek]

If I'm guilty of infringement, I can't give a shit. Legal or not, I don't believe that copyright should be binding past ten years - check my past posts, I've got a record of saying five-ten should be the copyright limit, and I do live by that.

Unfortunately for you, what you believe doesn't matter.

"I'm sorry, officer. I don't believe that the speed limit should only be 45 on this road. I'm far enough away from the urban area, aren't I?"

Re:I hold any bet

[Phisbut]

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.

The problem is that we let companies sell software with licenses that give them all the rights, while at the same time they waive all responsibility... I don't think I've ever seen a software piece that didn't come with a disclaimer of the type "This is provided as is and we are not responsible for whatever happens when you use it".

Re:I hold any bet

[NineNine]

"Letting" companies sell things like software with nasty licensing is called capitalism. Socialism would be a system under which governments can dictate what can and cannot be sold. With capitalism, the only choice we have is to vote with our wallets, which is STILL much better than what you're suggesting.

Re:I hold any bet

[kv9]

Unfortunately for you, what you believe doesn't matter.

fortunately for us, you don't make the laws

"I'm sorry, officer. I don't believe that the speed limit should only be 45 on this road. I'm far enough away from the urban area, aren't I?"

truly insightful. i'm sure him downloading ROMs is the same as going over the speed limit, crashing into a gas station and blowing away a good chunk of road.

these analogies... please stop.

Re:I hold any bet

[Kellay]

Yeah, i couldn't agree with you more, it's complete madness!!!

Re:I hold any bet

[Fordiman]

Fortunately for me, copyright law doesn't matter in the manner I infringe.

In other words, I don't participate in a way that will get me sued. Yes sued. You can't get arrested for copyright infringement, much to the chagrin of copyright abusers. They'd have to identify me as an infringer who is egregious enough to warrant the cost of a lawsuit, then prove that I infringe. Since I'm not terribly egregious (ie: what I 'infringe' by your definition are items that I could, theoretically, have duped myself for personal enjoyment under fair use), I'm pretty sure I won't be marked as egregious.

If you'll go have your date with the health inspector, I'm gonna go play some Zelda.

Re:I hold any bet

[Phisbut]

"Letting" companies sell things like software with nasty licensing is called capitalism. Socialism would be a system under which governments can dictate what can and cannot be sold.

I'm not suggesting government shoud dictate what can or cannot be sold. What I'm saying is, if you buy a car and the brakes fail every now and then for no apparent reason, the car manufacturer is responsible and they need to take action, either by fixing what they sold you or by giving you your money back. Consumer laws protect consumers from salesmen who sell crap.

However, when it comes to software, crap is the norm, and nobody is ever held responsible when whatever piece of software you bought (erhm... "licensed" actually) doesn't deliver what it was promised. When someone sells you a drill and the manual says this drill has such and such specifications, and you can you it to do such and such, you can take the drill back for a refund. When a piece of software advertises a bunch of features, and nothing actually works, you're out of luck, and you can't return an open box.

Capitalism vs. Socialism has nothing to do with it.

Catch 22?

[Tourney3p0]

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

Alright, so writing better code means you might miss a deadline. But not writing better code means.. things are exactly as they've always been, or the software development cycle will be revamped appropriately?

Not much of a catch 22.

Re:Catch 22?

[supra]

The catch 22 is quite the opposite from what the article proposes.
Being careful almost always means improved schedules, not the opposite. It's better to spend 10 min reviewing code before committing it each day than have a lump of crap after 12 months which can't float for more than 5 min w/out a problem.
Debugging problems takes orders of magnitude longer than small incremental reviews. Some things that attribute to this are awareness (the code is fresh in your mind after being written; it's half forgotten when problems surface), scope (the problem will likely surface after the system grows making it harder--and thus consuming more time--to find the problem), and complexity (even after the problem is found, a solution is easier to apply when the code is fresh because the interfaces are new; if a bug entails an interface change or worse--a design change--then the time will really grow).
The catch 22 is really an old-school mentality forced into this generation.

Re:Catch 22?

[Fordiman]

A good revamping would be for management to learn what the word 'rediculous' means in the context of the word 'deadline'.

Re:Catch 22?

[CCFreak2K]

The problem is, if you miss a deadline, whatever was submitted prior to the deadline -becomes- the product. Such tight schedules don't allow for things like quality control.

Think about, for example, Windows Server 2003. In the days prior to the betas (I think), there was what was called a War Room. Every day, the heads of each design part of Windows Server 2003 met in the War Room to discuss the current status of each part. If a department had a bug and their team leader didn't show up, their [potential] fixes to the next build of Windows NT wouldn't make it into the build process.

Re:Catch 22?

[Anonymous Coward]

learn what the word 'rediculous' means

Apparently it doesn't mean anything.

Re:Catch 22?

[Kapsar]

A Catch 22 is a "damned if you do, damned if you don't" circumstance. In this case if you miss your deadline because you created a better product, or you make your deadline but end up with crap and then miss it later. catch 22 is not an old school mentality, it's a realistic way of looking at situations, read the book you'll understand then.

Re:Catch 22?

[IpalindromeI]

A Catch 22 is a "damned if you do, damned if you don't" circumstance.

No, it isn't.

Re:Catch 22?

[IpalindromeI]

Reading further, I see that the article agrees with you. Oh well.

Re:Catch 22?

[Fordiman]

Hey, look, a grammar troll.

*stops paying attention*

Re:Catch 22?

[Anonymous Coward]

describing a general situation in which an individual has to accomplish two actions, both of which require that the other one be done first

I blame people attributing "damned if you do, damned if you don't" to it because they are too god damn lazy to say, "Damned if you do, damned if you don't.", or more appropriately, a no win situation, as opposed to circular requirements.

Oh well, I'm sure I've used some phrase or words wrong in my lifetime. I'll just chalk it up to karma and move along.

Re:Catch 22?

[Anonymous Coward]

Not only that, but what he describes isn't a Catch-22. In a Catch-22 you need some sort of mutually exclusive conditions, like "We can't fix the bug until this module is finished, but we can't finish this module until the bug is fixed." What he's described is a normal trade-off. Either we are less careful and meet the deadline, or we are more careful and miss the deadline.

Re:Catch 22?

[Anonymous Coward]

Spelling troll, idiot.

Re:Catch 22?

[Anonymous Coward]

The word is spelled "ridiculous". I once mis-spelled it your way in a spelling bee when the announcer pronounced it "REE-dick-you-lus". Lost the spelling bee. So sad.

Anyway, if you're going to fault someone, you'll always look foolish when you don't make sure your own eyes are crossed and your teas are dotted.

Security First....

[HumanisticJones]

...might just make the software more appealing to customers. Recouping the lost market time with a slightly more solid base, combined with less strain on call centers when bugs do fly up. Catch 22 be damned, I'd rather have working, secure software a month later than a buggy, glaring security risk today.

Re:Security First....

[Anonymous Coward]

You'd rather have the first option, your boss would rather have the second. He doesn't have to fix it.

QA is.....

[Wisp]

The new Black!

Re:QA is.....

[Anonymous Coward]

What does hiring quotas have to do with Quality Assurance?

I do this personally.

[cableshaft]

I usually do some quick general design and planning beforehand, then go in and write the software one element at a time, testing to make certain it works properly before moving on to the next. The benefits seem to far outweight doing it the other way, for me, as it reveals problems I wouldn't have noticed in the planning stages in the design or implementation early, and it also helps isolate where any bugs would be located at, so I'm not checking all over the place.

I'm not sure if it really saves me any time in the long run, but I'm much more comfortable coding this way, which is probably more important.

Also, so far, I've been the only coder for my projects at work and my games at home, so it *might* not be quite as effective for large teams, although what I've read on XP seems to suggest that it can still be very effective.

Re:I do this personally.

[matt328]

This is definitely the way to go. I do this myself, lay out a project a single component at a time, and test all along. Sometimes I only change or add a couple lines of code at a time before I compile and test it. Seems like this would take a long time to code anything, but I cut out all the rigorous testing (and possible debugging, and even worse, rewriting entire modules)

Re:I do this personally.

[bigpat]

I usually do some quick general design and planning beforehand

Exactly. I really don't think taking more time to "code" is the answer. The majority of security problems in software come about because of design issues. The focus should be on security as a functional requirement. Sure buffer overflows and such can result from poor coding techniques, but I have found it is just a general lack of functional definition which dooms a project to a lot of revision later in the process.

Re:I do this personally.

[zanzi]

A study at IBM concludes:

Software projects with the lowest levels of defects had the shortest development schedules and the highest development productivity... software defect removal is actually the most expensive and time-consuming form of work for software (Jones 2000)

In "Code Complete 2", McConnell says:

Microsoft's applications division has found that it takes three hours to find and fix a defect by using code inspection, a one-step technique, and 12 hours to find and fix a defect by using testing, a two-step technique (Moore 1992).

So paradoxically code-inspection could reduce development time of good-enough products.

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. That's just a tradeoff.

Re:Catch-22

[Amouth]

yea the catch 22 is if they write better code then they don't have a job to write the patchs

Slippery slope

[metamatic]

Jeez, next thing programmers will be expected to document their code.

What will the XP weenies do then?

Ain't gonna last

[FiveDollarYoBet]

Those aren't security holes.... They're undocumented network transfer features!

It sounds good and all but there's a direct correlation between the deadline and how bullet proof the code is.

insert sig here

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:Well I learned that at Uni

[ximenes]

Probably by themselves, since teaching actual programming is beneath most university curriculums.

Re:Well I learned that at Uni

[Anonymous Coward]

Corporate greedhead scumbags always have the last word, sad, but true.

The street must be obeyed. Back to work, code-monkey!

Re:Well I learned that at Uni

[Anonymous Coward]

India?

That's why...

[GillBates0]

I always make sure I use the highest quality bits when I program. You'll find none of those low-quality, flimsy and occasionally perforated bits in my code.

Agreed, periodic checking for holes has it's own value, but nothing beats using the best quality, industrial-strength (tm) bits to start with, moreso while developing reliable software in the post-911 world.

Re:That's why...

[MasterC]

...but nothing beats using the best quality, industrial-strength (tm) bits to start with...

For those not in the industry sector but in information technology sector, are those the same as the Best Information Technology Strength (BITS) bits? I've used BITS bits before and they were solid and performed quite well.

The Big Unsigned Superior Technology bits are the best choice for the adult entertainment sector. They're so successful that I hear its those bits that dominate the internet and slashdotters' hard drives, mobile phones, CD-R stacks, and push the capacity of their Tivo/MythTV. I wish I had the patent on those bits!

Re:That's why...

[Sponge Bath]

...use the highest quality bits

I bought a box of 'Great Quality' bits from Fry's.
It only contained zeros, but they price was great!

Duh!

[cashman73]

Has Ric Romero seen this report yet?

This Just In From Microsoft

[Metabolife]

After taking this training routine, Microsoft says that Vista will be delayed another 2 years.

Re:This Just In From Microsoft

[cazbar]

If they did this, Vista might actually be worth the money.

Re:This Just In From Microsoft

[The Waxed Yak]

...until they can buy OS X and duct-tape a Start button to it.

gets() and people

[mkiwi]

Sometimes it amazes me what people do with the C programming language, for good or for bad. Take some pro programmers who I caught using gets() instead of fgets(). I'm not a rocket scientist, but I'd say anything that uses gets() is a serious problem, since that function does no bounds checking and is prone to attacks.

How do people learn to code like this? Is it just early habits that do not go away?

Re:gets() and people

[Anonymous Coward]

Wow. I've never seen anybody use gets().

It's good that most systems' documentation for gets() explicitly warns not to use it, so it's a pretty hard mistake for someone learning programming today to make. The OpenBSD linker also warns people not to use it at link time.

But come to think of it: why is gets still present at all in libc? It should be removed, or made into macro for abort(), or print some severe warning (and rightfully so, scolding) on stderr that says if the programmer values his life and all that is holy, he'd better change his code.

At least functions like strcpy(), though unsafe in most usage, can actually be legitimate in some cases where the buffer size is gauranteed to be enough. gets(), on the other hand, has no legitimate purpose: you should never by any means trust that a file descriptor will have data of a given size.

Re:gets() and people

[wjcofkc]

http://rinkworks.com/stupid/cs_programming.shtml

Re:gets() and people

[Richard Steiner]

I've always wondered why such harmful code is allowed to survive. We certainly don't allow it in our own local utility libraries.

Rewrite the standard gets() function, and have the compiler force programs which utlize the old one to handle the new one (either by making the change transparent to existing code or by forcing the programmer to address the problem by making some minor changes).

Problematic standard library functions are traps just waiting to happen.

UNIX is too "steeped in tradition" for its own good sometimes...

Re:gets() and people

[Anonymous Coward]

Except that there is no way to properly rewrite gets(). The size is not specified, therefore not known to the gets() code, therefore a bug every time it is used. The proper solution would be to convert the code to use fgets(), or make your own gets() that tells the programmer not to use it.

gets() is not a "Unix tradition", either. All competent Unix programmers will tell you not to use it.

Re:gets() and people

[Richard Steiner]

What's wrong with adding a required size argument to getc() and forcing code using the old problematic function to alter their function calls?

Isn't that preferable to leaving a potential timebomb out there?

There is never "no way" in software. There might be "not acceptable" for various reasons, but that isn't the same.

Hopefully most compilers treat getc() as a deprecated function, anyway.

Re:gets() and people

[Anonymous Coward]

What's wrong with adding a required size argument to getc() [sic] and forcing code using the old problematic function to alter their function calls?

Two things:

1. When you do this, it is no longer gets(). I hadn't realized that's what you meant
2. Said function already exists. It's called fgets()

Re:gets() and people

[chthonicdaemon]

In many cases they learn to program for their own projects, where speed/ease of coding may be more important than security. If you just pick up an old C book, no-one warns you to stay away from gets(), so people learn to use it, and it works. Then they get told to use something else that is more secure but it is slow or more difficult to learn, so they don't.

In my building there is a whole floor of guys doing simulations in Fortran 77. When I tell them about new functions in F90 or about ways they could solve their problem in C++ they have only one question: "isn't that going to be slow?".

So ultimately the problem is that most "bad" code comes from people who have hacked together a useful tool by leveraging their experience in fields where security or stability doesn't really matter. They have probably been coding successfully for some time without ever seeing anything wrong with their approach until they used it out of context.

OT: not a Catch 22

[cain]

The example in the write up is not a catch 22. A catch 22 requires two things be done, each one before the other, thus neither can be done.

Re:OT: not a Catch 22

[Peyna]

Have you read the book "Catch-22"?

"There was only one catch and that was Catch-22, which specified that a concern for one's safety in the face of dangers that were real and immediate was the process of a rational mind. Orr was crazy and could be grounded. All he had to do was ask; and as soon as he did, he would no longer be crazy and would have to fly more missions. Orr would be crazy to fly more missions and sane if he didn't, but if he was sane he had to fly them. If he flew them he was crazy and didn't have to; but if he didn't want to he was sane and had to. Yossarian was moved very deeply by the absolute simplicity of this clause of Catch-22 and let out a respectful whistle.

'That's some catch, that Catch-22,' he observed.
'It's the best there is, Doc Daneeka agreed."

So actually, based on the origin of the phrase "catch-22", the article seems to be more right that the version you ripped off the top of the Wikipedia page. "Damned if you, damned if you don't," is much closer to the original and (while Wikipedia disagrees) more familiar version of catch-22.

So, with the article we have here, what they're saying is they have two choices: 1. Delay the release and everyone hates you for endless delay; or 2. Release the product on time and everyone hates you for releasing buggy code. Of course, to have perfect code, you have to delay indefinitely, so the product would never get released.

Re:OT: not a Catch 22

[LargeWu]

No, I think you have failed to comprehend the example from the book. Go back and read it again. A catch-22 is a circular set of conditions that can only be fulfilled if the other is true. The second condition in your example falsely assumes that code which is released on schedule cannot also be bug free. Furthermore, "Damned if you do, damned if you don't" is a lose-lose situation, not a catch-22. This phrase assumes that "do" and "don't" are not dependent on each other. Of course, if you have to "do" in order to "not do", and have to "not do" in order to "do", then you've got a catch-22.

A lot of presumption on their part...

[Bomarc]

This would presume that developers know how to TEST software. LARGE presumption on their part... It would be better to have competent TESTERS actually- test the code.

Re:A lot of presumption on their part...

[Richard Steiner]

Software development is an iterative process that involves unit, subsystem, and system testing, optimally by BOTH the programmer(s) and by at least one dedicated third party.

We always had business analysts test our stuff. They knew how it was supposed to work, but more importantly: they usually didn't understand the technical underpinnings, so they didn't know what they *weren't* supposed to test. That sometimes produced interesting results. :-)

Re:A lot of presumption on their part...

[bmalia]

For my company, I am the developer and the tester.

Go ahead, feed the script kiddie community

[Goblez]

Taking the time during development to test and debug your code. I'm sorry, but this isn't something new, nor somethign to be ignored. People mistakenly think that you throw your code together, and if it works you're done. This is wrong. Any production system code should be tested before being put in. Maybe testing and debugging should be considered overhead in an industry that doesn't have much thereof (consider manufacturing of hardware).

Otherwise we are just fueling the fire of exploitation and bad-user experiences.

--
Goblez

Re:Go ahead, feed the script kiddie community

[mikewolf]

the problem is that most QA processes focus on testing for user experience issues and functionality issues. At least in my experience, the QA team isn't typically focused on testing for application security issues (like cross site script, sql injection, buffer overflows, etc...). They are basically trying to find errors before the users find them.

What products like Coverity offer are the opportunity to add in security vulnerability testing that is not manual. Have you ever tried to test a web app for cross-site scripting vulnerabilities, or tried to test an app for buffer overflow errors? Not only is it super time consuming, but new exploits are discovered all of the time.

Whats nice about products like this are that they will auto-magically check your application against this ever changing list of vulnerabilities. In my experience, the QA team has enough to do just verifying that new functionality works as designed and that bugs and issues that a developer resolves are actually fixed.

I would love to be able to integrate this into my team's build process, our QA process, our release process, and even our development process. its just another tool that can double check that everyone is doing things correctly, along side of unit tests and use case scripts.

Thinly veiled ad?

[Mr Z]

Is it just me, or does the article just read like a thinly veiled advertisement for Coverity? It's reads like a generic commercial template: "Meet Bob. Bob thought everything was fine. But then he discovered he had Problem X. That's when Bob discovered Company Y with Solution Z." (etc. etc.).

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:Thinly veiled ad?

[biscon]

Better sheep, sap, root or offtank it then ;)

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 is available on Wikipedia.

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:Good at publicising themselves

[blitz487]

I went to Coverity's web site. There isn't much useful information there about what it does, but there is lots of vague hype and attempts to get you to register. But what turned me off was their website hijacked the 'back' button so you couldn't leave their site.

Why do companies think that is a good idea?

Or, ...

[UbuntuDupe]

to paraphrase Oscar Wilde: Anyone who doesn't have enough time to do it right, has enough time to do it again.

Slashdot Advertisers for Coverity Again

[Anonymous Coward]

Automated static analysis spurs second wave of XP hysteria. Formal methods found dead from apparent suicide in home.

Deadlines are set wrong

[192939495969798999]

If being careful makes you miss the deadline, then the deadline is set wrong. Shipping a product with security holes that you knew about + could've fixed with a bit more time is how we got into the position we're in. Pushing back a release date to fix them first should be the rule, not the exception.

Re:Deadlines are set wrong

[Anonymous Coward]

You've obviously no plans to upgrade to Vista then

Re:Deadlines are set wrong

[bmk67]

In theory, what you're saying makes sense.

In reality, every place I've worked the last 15 years, Sales and Marketing has a hell of a lot more to do with release dates than the level of effort / resource constraints given by our engineering group. Dates are promised before we've even heard that a project exists - and to make it fit within the promised date, guess what suffers? In the rare case where they *do* ask us for a date, we're always told "that's not soon enough, you'll have to make it fit by [insert date]".

The worst part of it is that the dates are almost always concocted out of thin air, with no real NEED to meet.

Re:Deadlines are set wrong

[192939495969798999]

Right, that's because the commercial software development model is broken. It takes longer than they'd care to spend, and that's why the quality of commercial software suffers compared with software properly designed. Of course this costs way more to do, but it should pay off better in the end because of reduced maintenance, etc. costs over the life of the product, which also should be significantly extended because of higher quality.

Re:Deadlines are set wrong

[gatesvp]

This is really the curse in software development: Management!

Programmers are not to blame for any of this cr*p. If a project is late, this is management's fault. If a project is buggy, this is management's fault. If a project is insecure, this is management's fault.

This whole concept of inept programmers cranking out big-bucks software (shrink-wrapped or custom-built) is just utter BS!

If the project spec calls for security, then my manager is responsible for ensuring that security is designed, implemented, tested and budgeted in the project plan. If programmers do not know how to implement secure code, then my manager's job is to fire that programmer, train that programmer or move that programmer elsewhere.

When a project has to choose between security and meeting a deadline, then this project was incorrectly planned. Now in management's defense, software planning is extremely difficult and requires all kinds of skills completely unrelated to the development work that got them promoted there in the first place. But hey, that's why they're paid the big bucks.

Re:Deadlines are set wrong

[bmk67]

I hear what you're saying, and it may apply to the shrink-wrap software business. I don't know, I've never had any interest in working that particular part of the industry. I work as part of a team that delivers custom integration solutions, and everything here is driven by sales, marketing, and the customer's timeline. Time-to-market is everything: we promise to deliver on the customer's scheduler, or the customer goes elsewhere, and if we don't make that promise, someone else will. Oh sure, they may say that a project is cost-driven, or quality-driven, but that fact is this: everything comes down to time-to-market.

I don't like it, nor do I wish to defend the practice. But the reality of the situation is this - we have a small number of very big customers. If we don't deliver on the promised schedule, we risk losing customers, and therefore a large part of our revenue stream - and that revenue is ultimately what pays my mortgage, puts shoes on my kid's feet, and puts food on my table.

But yeah, with those factors out of consideration, I'd agree that the commercial software development model is broken.

Still developing secure code is not easy

[Billly Gates]

Especially if you don't know assembler.

The problem I see is that hackers today use buffer and stack overflows. The compiler creates the insecure code more than the program.

I wonder how secure managed code in .Net is? I know MS boasts that not a single security hole has been spotted so far but I do not know of any apps that use it? I know Java is secure for that reason but less usefull on the desktop.

Unit testing is your friend

[Billosaur]

Assuming you have a good idea of what input to your program is supposed to be, and you have an adequate method of checking to make sure the data is not some sort of goo (love those regexs!), then you should be able to test the software as you go. I'm of the school that tends to build each part, test it, and move on. It cuts down on the holes if I know where a piece of data comes from, where it's going, and what manipulations may happen to it along the way.

Really insulting title

[Anonymous Coward]

We know how to code securely, at least in the same way that every profession has its skill levels on a bell curve.

What the industry needs, as has been pointed out here, is companies that are
A) willing to give developers the time to design software correctly,
B) willing to give testers the time to test software thoroughly, and
C) willing to delay software that the testers find holes in.

Obligatory Fight Club

[Weaselmancer]

Narrator: A new program written by my company is shipped on time, but with bugs. The network stack locks up. The OS crashes and burns and scrambles the hard drive. Now, should we initiate a code review? Take the number of licenses in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a code review, we don't do one.
Business woman on plane: Are there a lot of these kinds of bugs?
Narrator: You wouldn't believe.
Business woman on plane: Which software company do you work for?
Narrator: A major one.

Re:Obligatory Fight Club

[SigILL]

It's funny because it's true.

Re:Obligatory Fight Club

[Anonymous Coward]

Business woman on plane: Are there a lot of these kinds of bugs?
Narrator: You wouldn't believe.
Business woman on plane: Which software company do you work for?
Narrator: A major one.

In fact, we wrote the avionics for this plane.
Business woman on plane: gulp

Re:Obligatory Fight Club

[Fulcrum of Evil]

No, you didn't have to do that. Without the callous disregard for loss of life, that exchange is just stupid.

Re:Obligatory Fight Club

[Weaselmancer]

Without the callous disregard for loss of life, that exchange is just stupid.

Ok then, does this help?

Re:Obligatory Fight Club

[Fulcrum of Evil]

He didn't mention planes. I know that, where I work, a crashed server isn't even a big deal.

Re:Obligatory Fight Club

[Coryoth]

What really makes it troubling for software is this: What is the "average out of court settlement" per discovered bug in a piece of software?

Jedidiah.

Nothing to see here, move along

[955301]

Now advertisements for COTS products are news articles?

While I appreciate the articles on NASA releasing code analysis tools - or pointers to freshmeat - embelishing about something I can't immediately use is boring. Procurement happens at a snails pace for purchased software - gimme something I can throw on the stage and start training dev's to use.

Or at least something in depth that shows statistics on *how much* the schedule slips by when taking this security first approach - that would be news:
"WSJ reports security-first approach to software costs 18% increase in time to deliver"

agreed?

Security is a Voyage Not a Destination

[Greyfox]

I see static analysis and code auditing as an excellent step on the road of security, but at a completely different level you have to also make sure that the processes you're coding are also secure. All the secure programming techniques in the world will not help you if your design itself has flawed assumptions. So not only should you program for security but you should also design for security.

Laws?

[VGR]

From the article:

Many companies rushed to beat rivals with new software, and checking for bugs that could later be exploited by hackers was often seen as a waste of time. That has begun to change in the past few years as new laws force the disclosure of security holes and breaches...

What laws are these? This is the first I've heard of such a thing. And why do I have a feeling these laws have a clause that directly or indirectly exempts certain large software companies?

Re:Laws?

[Anonymous Coward]

It is called Sarbanes-Oxley or SOX. It is part of a concept called management risk mitigation.

Slow and steady...

[rumblin'rabbit]

You are absolutely correct. In general, the more patient and methodical you are, the faster the project gets done. It definitely saves money over the life time of the project. This is particularly true for large projects.

It's when you rush and abandon good practises that the project is in danger of becoming seriously late.

It's something everyone knows, and everyone occasionally forgets.

Bullshit

[suv4x4]

I've some inside info and let me tell you how it works: write the best code, check for holes, make sure there are no bugs and so on and so on, but if you miss the deadline you're definitely fired.

And since the deadline is always unrealistic, all checks get down in priority as you try to keep your job hammeric code that barely works with the speed of light.

catch 22 ... sure...

[Anonymous Coward]

If "many companies" are teaching their programmers to write secure code then "many companies" should recalculate the deadlines and include code-checking in their timepath, instead of complaining about missed deadlines....

i mean either include code-checking and allocate time for it or don't check it and finish earlier... can't have it both ways...

Open Source alternatives

[coreboarder]

Probably fanning the flames here I'm wondering is there a free (as in beer) alternative to these products?

Code reviews aren't new!

[the packrat]

Code reviews by cow-orkers are nothing new. Ed Yourden and many others were publishing books in the late 80s and early 90s showing that it was a really good way to get code that was nicer and had fewer defects. To say nothing of Brooks's programming unit teams from over 25 years ago.

It's nice that someone is waving the security flag to promote it, but a little sad that everyone wasn't already doing it.

Deadlines

[tcolvinMI]

Ahh, deadlines, where would we be without them. Personally, I think that deadlines are the catch 22 of software development. With a strict deadline, you sacrifice quality. However, with a loose deadline, you sacrifice a product to your customer, which then sacrifices money coming into the company, which sacrifices your paycheck and even your job. Deadlines definitely have their place in the world, but I also believe that they should be loose enough to give you time to get a secure, thoroughly tested, and correct version of software out to the customer. Either that or a signed paper that says you're not responsible for anything you code because you were told to get the product out on time. However, that thought is incredibly naive at best.

Re:Deadlines

[Anonymous Coward]

Why is that naive, look at microsoft for example... do they accept responsibility for dataloss (for example) when they have buggy code? i don't think so...

Re:Deadlines

[Xyrus]

Which gets to the crux of th problem: the customers. It doesn't matter how carefully you plan or how many peer reviews you have, the customer will always come back and say "We want this feature".

You don't get any additional time or costs. If you stick to your guns and say no, there's more than a few companies who would be more than happy to agree to do it, and maybe even at a lower cost and shorter time frame.

Of course, you know where it will end up; a broken buggy program that just barely works. But all the "I told you so's" in the world won't change the fact that you're unemployed.

The customers don't want a 100% bug free super product. They want a product that works. In this sense, it's sort of like biological evolution. It doesn't have to be perfect, it just has to be good enough.

It's the customers that drive the market, and until the mentality changes we will keep seeing sub par programs that are just "good enough".

But I'm not bitter. ;P

~X~

What you learned is bullshit

[Anonymous Coward]

There is no such thing as software engineering. Software is still in the craftsmanship stages. Come back 100 years from now and maybe it will be approaching the rigor of engineering, as a discipline.

"Big design up front" does not work for software projects. ALL PHASES of software development are *design*. You have to do continuous evolution of the design and the code in tandem. As the C2 wiki would say: Practice ContinuousIntegration. Do ShortIterations to MeasureVelocity (i.e. to get constant feedback about your progress). RefactorMercilessly. CodeUnitTestsFirst. And most important of all: write something OnceAndOnlyOnce, and DoTheSimplestThingThatCouldPossiblyWork. Because YouArentGonnaNeedIt.

Missed deadlines = poor project management

[tgrigsby]

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

As with everything in a project, adherence to security guidelines must be figured into the time estimates for a project. Time estimates must in turn be based on department-reviewed technical specs. Tech specs are based on design and development reviewed functional specs. Functional specs are based on user and business requirements. If the project manager pushes for concrete time estimates using comprehensive one-to-one project description methodology, deadlines will still get missed, but it won't be because of a single requirement like security. Sometimes this means the project manager has to push back on the developers to say something like, "Are you sure it's only going to take you 80 hours to implement centralized licensing?" But that's what the project manager is supposed to do.

Business sometimes requires that releases occur on a schedule. Ok, fine, but that means scaling back the features included, not the quality of the product, and in today's market, security is one of the variables in determining quality.

Also

[ezeecheez]

More savvy programmers have started referring to crashes as 'security-necessitated shutdowns'.

Miss the deadline?

[Anonymous Coward]

This task should be included in the schedule. If the deadline is missed because of this task then it is due to bad estimation, just like all the other tasks.

The five laws of software process.

[Anonymous Coward]

http://www.corvusintl.com/whats.htm

The Laws of Software Process
There are are some immutable laws that apply to software process, and govern our (software) lives. This issue identifies these laws, gives some examples, and explains the consequences. Here they are:

The First Law of Software Process
Process only allows us to do things we already know how to do.

The Corollary to the First Law of Software Process
You can't have a process for something you don't know how to do

The Lemma of Eternal Lateness
The only processes we can use on the current project were defined on previous projects. Which were different from this one.

The Second Law of Software Process (See also "The Rule of Bifurcation")
We can only define software processes at two levels: too vague and too confining

The Rule of Bifurcation
Software process rules should be stated in terms of two levels: a general statement of the rule, and a specific detailed example (eg. The Second Law of Software Process).

Armour's Observation on Software Process
What all software developers really want is a rigorous, ironclad, hide-bound, concrete, universal, absolute, total, definitive, and complete set of process rules that they can break.

The Third Law of Software Process (also known as the Footwear Manufacturer's Minor Dependent's Law)
The very last kind of knowledge to be considered as a candidate for implementation into an executable software system will be the knowledge of how to implement knowledge into an executable software system.

The Twin Goals of Optimal Termination
1. The only natural goal of a software process group should be to put itself out of business as soon as possible.
2. The end result of the continuous application of effective process will be that nobody actually has to use it.
----
The Five Orders of Ignorance
Did you know

Software is not a product, it's a medium (see Software is not a Product) for storing knowledge. Therefore, software development is not a product producing activity, it is a knowledge acquiring activity. Knowledge is just the other side of the coin of ignorance, therefore software development is an ignorance-reduction activity.

So what kinds of ignorance do we have? It turns out there are five levels or "Orders of Ignorance". They are (starting from zero, 'cos we are computer folk, and we always count from zero):

0th Order Ignorance (0OI)--Lack of Ignorance
I have Zeroth Order Ignorance (0OI) when I know something... ...and can demonstrate my lack of ignorance in some tangible form, such as by building a system that satisfies the user.

1st Order Ignorance (1OI)--Lack of Knowledge
I have First Order Ignorance (1OI) when I don't know something... ...and I can readily identify that fact.

2nd Order Ignorance (2OI)--Lack of Awareness
I have Second Order Ignorance (2OI) when I don't know that I don't know something. ...That is to say, no only am I ignorant of something (I have 1OI), I am unaware of that fact

3rd Order Ignorance (3OI)--Lack of Process
I have Third Order Ignorance (3OI) when I don't know of a suitably efficient way to find out that I don't know that I don't know something.... ...So I am unable to resolve my 2OI

4th Order Ignorance (4OI)--Meta Ignorance
I have Fourth Order Ignorance (4OI) when I don't know about the Five Orders of Ignorance... ...which you no longer have, dear reader.

These Five Orders of Ignorance play an tremendously important role in systems development: our job is the reduction of 2OI. All systems processes and methodologies are 3OI pr

Re:The five laws of software process.

[tgrigsby]

These Five Orders of Ignorance play an tremendously important role in systems development

Apparently they also play a heavy role in Donald Rumsfeld's job.

I don't buy the idea of missed deadlines

[Allnighterking]

The problem is one of doing things in software the way Automobile companies did in the 60's and Japan stopped doing in the 70's. Traditionally in software development you design... then send to engineering to build then send to QA for an endless cycle of test bitch fix bitch retest bitch fix bitch test bitch deadline ooops market. QA should be involved the moment some fool says "I have an idea" and stay in the loop all the way. Testing in increments as things are built. I've done more in a white paper on my site as for writing this all up but this is the jist. Integration of Quality control from the start means less problems. The idea of. I'll fix it later sucks because it never gets to be later.

Its all in the build

[z4pp4]

Everybody makes mistakes. That is how we learn and progress to a more experienced state of being.
By telling people not to make mistakes is letting them know that they cannot try out new and inventive, sometimes even shorter ways of doing things.
Unit testing is fine and should be encouraged, but really the thing you want to do here is make your build process do all the donkey work as much as possible, and let your programmers worry about the programming issues and doing things smarter and achieve the most with the least possible effort.
The build process can do the following, if you do it right:
-> Build the code to executable format and even CD ISO distributables (duh)
-> Do code indenting and formatting etc. to conform to a standard.
-> Do unit testing on code segments, and even tell you what % parts were not tested.
-> Scan the code for bad practices such as strcpy and unmatched mallocs.
-> Gather all your TODO's and your FIXME's into an output file.
-> Run the program live and do input fuzzing testing, with extended debugging logs.
-> Run nessus and other attack scripting languages to take care of the obvious issues.
With all these measures in place, it is a simple matter of having *somebody* go through the build logs and make a priority / TODO list, fixing security first and stability later, and the small imperfections last.

But alas. Nobody looks at the logs. Logs are boring. Thats why you have to keep them visible. Maybe via RSS, IM or email?

Deadlines are set wrong-DNF

[Anonymous Coward]

"If being careful makes you miss the deadline, then the deadline is set wrong."

The guys at 3D Realms agree with you.

No sympathy whatsoever

[grikdog]

The concept of automating code scans to check for "errors" is essentially delusional. You cannot create a catalog of 4,000 known bugs (or some huge number) in software you intend to ship, not when you save money on coding costs by kicking the original bums who understand the code upstairs (or curbside) and then hire RCG's to maintain, or worse, improve, the crap they'll never own. I have never, ever, fixed a bug that wasn't coated with a diamantine millimeter of solid acrimony - but no lintpicking automaton found those errors, either. There was always a human dimension. My favorite was a screaming hysteric who threw a stack of printouts six inches thick at me, all documenting the exact same one-word typo. You want to run a company like coding is the bottom rung of your personal Jacob's Ladder, be my eternal guest.

Wow. A 'Developer' article

[ishmalius]

I'm just so happy that a "Developer" article actually made the front page. I have been afraid that the tech level of the audience of Slashdot has been falling lately. Compare it to the number of "Game" articles on the front page.

But to stay with the topic, analysis tools are just that: tools. They are not a cure to chronic software problems. Developers are not excused from the responsibility of at least attempting to write quality code.

Some current project development methods really contribute to buggy and insecure code. Example: XP. I really think that some aspects of XP programming are a bad idea. Namely, the "code as fast as you can" aspect of it is fraught with errors. A more thoughtful, disciplined approach might seem like it is terribly slow. Yet being inherently less buggy, it can reach the target faster than the sloppier, more haphazard approach. This is much like the Tortoise and the Hare. Or maybe a better analogy would be like a rally driver who is more careful with his fuel and tires.

Don't get me wrong. Some parts of XP are fine. The Buddy System is an excellent way to get things done quickly by short-circuiting the collaboration cycle.

Re:Wow. A 'Developer' article

[Valdrax]

I'm just so happy that a "Developer" article actually made the front page. I have been afraid that the tech level of the audience of Slashdot has been falling lately. Compare it to the number of "Game" articles on the front page.

No, don't. Zonk is a machine that exists to post.
It's not fair comparing any other section to Games as a result.

Re:Wow. A 'Developer' article

[wickedj]

"Some parts of XP are fine."

Yes, I believe they've pretty much got Solitaire down.

Re:Wow. A 'Developer' article

[Anonymous Coward]

Also their calculator and clock programs are solid.

Re:Wow. A 'Developer' article

[ral8158]

Just so you know, when E3 is rolling by, it's always like this. Y'know, it's not like this is E2, or even E1, it's E3. Pretty important.

Who makes the deadlines?

[Anonymous Coward]

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

Those "deadlines" that you speak of:
Are they dictated by the customer? Generally not; there are exceptions, but most customers look to you for an answer of how long it might take.
Are they dictated by the market? Probably not; for one quick example just look at Microsoft and their slipped schedules on OS, 5 years without an update to the browser, etc, etc, all without significant impact on the their software usage.

No, having worked in this field for quite a few years and seen what goes on, these deadlines are imposed by marketdroids and clueless managers who don't know that a deadline is necessary, cannot predict or even measure after the fact any impact of deadlines on sales and they certainly don't appreciate what harm they do to products by imposing arbitrary deadlines.

So this catch-22: it involves creating a better (i.e. more secure in this case) product at the expense of missing arbitrary deadlines that probably didn't have much to do with success of the product in the first place. Does someone need to have catch-22 explained to them?

Software lemon laws...

[Anonymous Coward]

...and a required minimum warranty on software would help to"nudge" this along. Software is a mature industry now, does no longer need training wheels, nor any exception to the warranties all other products require to be sold, leased, or etc. Leaving it voluntary has resulted in decades of code bloat, insecure code, buggy code and perpetual betaware, and an ingrained mindset that this article is talking about, both with the grunts and with the marketers and owners. Every single one of these bigass for profit software companies calls their stuff a "product", so, let us as a society treat it as a legal product, SAME as every other industry.

Less releases, leading to much better quality? That's the entire idea behind warranties. And lemon laws exist when warranties aren't enough. Stocks, billion dollar businesses, huge salaries, patents, etc all say "warranty needed" to the 99.99% of the people out there who aren't coders, the "consumers", the folks who provide the cash for these products.

Free software, given away gratis, I don't care, label it betaware, use the users as testers. For "license" for cash folding money software? Needs a warranty and lemon laws.

Re:warning: not work safe link

[Anonymous Coward]

Yeah, 'cause a link titled "RIM Holes" that leads to a site called "sexymisslizzie.com" couldn't POSSIBLY be a pr0n site.

Mr little will be the most loved person there?

[nietsch]

It is very nice that this bozo has a (very expensive I read) little program that tries to detect problems when they have already happened. So along comes mr friendly one day (or more?) after the fact to dicipline the programmer? That does not sound like a very positive approach to me.
If you want to learn someby something (I hope mr belittle does) it works much better if you have a quick feedback loop, react immediately when something is going wrong, not one weekend later when the programmer has all but forgotten why he did it that way. I agree you cannot use a mr little for such feedback, but unittests and other tests that have to run before the developer can turn in his work can be run automagically. Test are not partial, do not have favorites, and are easy to understand by a programmer. Mr little is probably the opposite. You will either need a pairprogramming or review process to prevent programmers from just disabling the test that fail, but with such a process you will have good software and happy programmers. Mr Little does not make programmers happy.
Have a look at aegis, a Configuration management system that can enforce such a process and do a lot of other commonsense things. The 'problem' with aegis is that it does not have a pretty pictures interface, so it's advantages are hard to explain to pointy haired bosses.

Fortify also very good

[SuperKendall]

I am in the process of evalutating Fortify and it seems like a really good product as well, with security at the heart of the evaluation rather than just mere bug finding.

Have not looked at Klocwork yet but it seems similar.

Re:Fortify also very good

[Anonymous Coward]

SuperKendall, if you are interested in evaluating Klocwork, just give us a call or, if you prefer to contact me directly: artem.frolov at klocwork dot com (I am a software developer with Klocwork). I may be able to answer your questions from developer's perspective. Are you interested in Java, C or C++? What is your main concern: security or defects?

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.

OSS != noncommercial

[colinrichardday]

I've purchased copies of some Linux distributions (most recent, SUSE 10.0).

Your didn't define Catch 22, either!

[Roadkills-R-Us]

A Catch 22 requires two mutually exclusive things to be at the same time.

It comes from the book of the same name wherein the only way to get the army to take you out of the war, you had to be proven crazy, but desiring to get out proved you weren't crazy, so there was no (legal) way out (without getting injured or killed in the line of duty).

--
``...like an alpaca sack full of hairy strawberry ice cream, bleeding, pink toes awry...''

XP != code as fast as you can

[hotsauce]

You should really read Unit Testing in Java: How the Tests Drive the Code. XP is about small, direct steps, and when these are done with tests first, they greatly improve the quality of the code. You can draw all the big, fancy, pie-in-the-sky diagrams you want, and still get sloppy code.

valgrind tool

[AeiwiMaster]

I have been think if it isn't posible
to make a valgrind tool which scans for secuity issus ?

http://valgrind.org/info/tools.html

Re:valgrind tool

[Anonymous Coward]

Check out http://www.fortifysoftware.com./ I don't work there (but I interviewed there) and haven't taken the time to compare valgrind with their software, but if this is possible and they aren't doing this now, I would imagine this is something they would do.

being more careful DOES NOT mean missing deadlines

[syousef]

being more careful can mean missing deadlines

Failing to plan extra time to be more careful (ie. check for bugs) means missing deadlines. Only an incompetent manger, or a dishonest conman setting the team up to fail is going to insist on extra care in coding and/or code review and not put the extra time required on the plan. There's definitely a time vs quality tradeoff but it has nothing to do with missing deadlines since they should be set correctly.

pebkac programming

[sl4shd0rk]

It's sad times indeed when you have to explain to a programmer to test his code. It sounds to me like the easy-buttons are catching up with laziness and breeding stupidity.

UMG v. MP3.com

[tepples]

fortunately for us, you don't make the laws

Unfortunately for you, neither do you. See UMG v. MP3.com . But on the other hand if you build a ROM dumper and copy the data from the cartridge to your hard drive, you're in the right under 17 USC 117 and foreign counterparts.

Re:UMG v. MP3.com

[kv9]

my point was that the consequences of warezing and speeding are (might be) totally different. but he will get his wish pretty soon.

as i see it warezing is in the same ballpark as shoplifting, if you *really want* to make a crime out of it. not genocide, or whatever the fuck ??AA would like you to believe.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Why does Java suck?

[tepples]

I know Java is secure for that reason but less usefull on the desktop.

What specifically makes the Java platform less useful on the desktop? Are there big problems with a widely deployed application for the Java platform called Azureus, other than perhaps memory use?

Re:Why does Java suck?

[Billly Gates]

Dependance on OLE and DCOM and integration with windows for things like business desktops. I can't modify or script any programs like my custom schedule app at work without using vba and dcom.

I wish Java did have more prorpietary hooks for htat reason. I can at least do this with python or perl if I dont have c# lying around.

Formal Verification

[sr180]

You can use the techniques of formal verification to prove that software is correct. http://en.wikipedia.org/wiki/Formal_verification

From now on

[Aceticon]

In their infinite wisdom management has decided that, since programmers now know how to program safelly, programmers will have the responsability of avoiding security bugs while still having to deliver the application withing the same deadline.

some supplementary stuff, hope it helps :)

[Anonymous Coward]

I agree with you, but I've got a few more reasons why it's better to get other people in.
Reviewing your own work is very important, but the problem is justifying how long you 'hold off the submission' while you review your own work. How long do you review it for? This is the typical problem engineers feel that they have with management pushing them for rapid development.

If you add the step of getting others to review your work to the submission process then you can justify it in the following ways:

1. You can be reviewing other work or working on something else. This gives you a break from the code you've just written so you can see it with fresher eyes when you get to make the submission.

2. Other team members have a better view of what's happening within the code. This has the advantage that you can justify it to management as being able to cover for sickness, holiday, etc.

3. As you're working in a team, you'll probably be using each others code, so they'll be in a good position to suggest better ways of achieving things when using it.

4. You make the code easier to read, as others have to read it for the review. This helps everyone as someone will always have to come back to look at the code in the future. It might be next week, next month, next year or longer. If it's over a year, it might as well have been written by someone else.
This hits debugging also:
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -Brian Kernigan

5. Once it's submitted you won't get a chance to review it or clean it up. Justifying a rewrite is a very hard thing to do.

Automated methods of finding problems are valuable, but they should be seen as suplemental to the 'mark 1 eyeball' and not a replacement for them, and they can only do so much. For instance spell checker checks your spelling, a grammar checker will check your grammar, but neither will check if what you wrote makes sense.

Hopefully this helps
(no I've not reviewed this comment, so hopefully it makes some sense ;)

IBM Study - was:This just in:

[smalltalker]

I recall (but can't find a reference to) an IBM study on code reviews back in the 80's - the biggest bang for the buck was the second set of eyes - that was where you maximized bugs found per reviewer. Does this ring a bell with anyone?

Re:IBM Study - was:This just in:

[Bender0x7D1]

I believe it would have been part of a study conducted by Michael Fagan. He studied/conducted over 11,000 code inspections at IBM to find the most effective way to inspect/find bugs in code.

He found that the optimal number of people to have in the inspection process is 4. More people made the effectiveness go down. Each person also has a particular role, and the amount of time to prepare and perform the inspection were set. It took 2.5 hours to prepare and 2 hours to inspect 250 LOC. So 4.5 hours/person, or 18 staff hours, for 250 LOC. It also had to be specific people who took part - one was the author of the code, one was the designer, and one was the "consumer" (the one who was going to use your code). Everything also had to be tracable to some artifact/requirement, so everyone could examine it and decide if you had met the requirement/design.

Now, before anyone declares that it can be done in less time, or with fewer people, or that someone as good as you doesn't have to follow it, let me point something out...

There is solid data behind those numbers, (11,000 data points) and the inspections weren't done with a bunch of people who heard there was money to be made programming at some dot-com startup - they were software engineers at IBM. There is also information available from Motorola that after a group changed to the Fagan process they reduced development time by 50% and got 2x the features in and finished tested months early because most of the test cases were passed the first time. I forget how much money they saved, but it was enough to make Motorola declare it as their official methodology. (Then everyone thought they could "streamline" the process and went to what they thought would be faster, easier and better. IMHO - it wasn't.)

Finally, this process does not fit every coding situation. It would be good if it did, but if you have a customer who changes requirements every week it is impossible to reinspect everything. Of course, this is where I see the difference between programming and software engineering, but I won't ramble on about that today.

Bridging COM and Java

[tepples]

I wish Java did have more prorpietary hooks for [COM and the like].

It is possible to wrap a JavaBeans component in an ActiveX control, and Jcom goes the other way.

Coverity Press Release

[oldCoder]

This article is based on a Coverity press release. These are the same people who put out a somewhat misleading press release on the bugginess of Linux vs Windows.

They counted bugs per line instead of bugs per function. So for 2 modules that did the same function and and had the same number of bugs, the one with more bloat was counted as less buggy.

Not that there is necessarily anything wrong with Coverity tools -- I haven't used them. But their press releases have logic errors.

Today's press release says programmers are being managed to work better because they bought Coverity tools. Maybe, maybe not.