Ahem... Good analogy, bad conclusion...

A good analogy is if the UK government mandated that fleet vehicles have their design and manufacturing processes laid bare, or they wouldn't buy the vehicles. I really don't care about the processes documentation - buy the best car at the best price.

If the government did this, it would be in trouble as soon as the vehicle needs maintenance. Or if you wanted to modify the vehicle later. If you MUST go back to the vendor for this, you have just accepted the fate of a captive customer - good luck in the negotiations.

Impressive:

There is no indication that this was the result of an issue with our product.

Well... technically right, but the "product" people buy is not just the software: It is the whole package, which includes the on-going maintenance of whitelists, signing binaries and whatnot. And that appears to have been badly compromised.

We are continuing to monitor the situation.

Surely, if the product is that great, then you can relax, right? Isn't that what you're selling to your customers? "Security in a box?" (I know. Security is an on-going process, but not if you ask sales)

While our investigation shows our product was not compromised, we are finalizing a product patch that will automatically detect and stop the execution of any malware that illegitimately uses the certificate

Repetition Repetition... "product not compromised" ... except that it no longer provided any protection against those evil hackers?

I think I'm getting my head around doublespeak - will be useful when I respond to bugs...

Please... Don't comment it out. If people want to see what it was like before, that's what version control is for. If you delete code, you should actually delete it.

You should give the same courtesy to others as you expect from them: When reading code, you're interested in what it does, and how it does it. Not a history lesson.

In my experience, "messy code" is a good indicator of "messy development". I strongly believe that the structure and appearance of the code is a insight into the developer's brain. And messy code: Usually means trouble ahead.

And yes: IDEs can help with automatically formatting code: It's good since it allows developers to spot obvious mistakes, and it's bad because it allows bad developers to hide structural errors. But probably good overall.

There's more to coding style than simply indentation: The really most important concept is clarity.

If a developer cannot explain (in one sentence) what a given function does, what a given class does or what a application does: be worried. If the developers thinks they know and still cannot explain: Be very worried.

The religious zealots have no interest in getting the video blocked or removed: It helps drive people straight into their arms - and as a result we should expect more radicals and fodder for suicide bombings...

There are two problems with this:

• It may cause people to believe in homeopathy, since it will become the "official treatment": It gives undue credibility
• Studies have shown that when people are given expensive placebos (placeboes?), they report a bigger effect than for cheap placebos (even when told it is a placebo!) - I wish I had the link handy...

And imagine the lawsuit, media coverage and political mayhem if a patient was given a government-approved-known-to-be-placebo medicine and then died - it's bound to happen (law of large numbers and whatnot) - even if it is not causally related...

The article gets off to a bad start in the very first sentence:

In the 1930s, U.S. Navy researchers stumbled upon the concept of radar when...

Rubish. The US Navy did not invent radar as it implies. Nicola Tesla descibed the concept in 1917 and others were playing with similar ideas before then. Sorry. Im not going to bother reading the rest. Isnt there an actual paper on the subject we can read instead of this badly-informed junk?