The same thing happens with the hope for the "next generation" product solving all the ills of the current generation. Or the assumption that the code you have inherited was created by fools a number of years back.

The reality is that software has a set of maturity related bugs and a set of structural, intractable issues that are related to the design and architecture of the system. Each piece of software has it's unique set of intractable issues.

Software that has been in production has typically reduced it's maturity related bugs. The software built on top or that integrates with it is built around those intractable issues. When you move to a new piece of software - either a new architecture or the "groundbreaking ng version of XYZ", you end up with swapping a set of *known* intractable issues, for a set of *unknown* intractable issues plus a set of maturity related bugs.

Similar to TFA, the risks of old+known vs new+immaturity+unknown needs to have another factor similar to "value-add". If the value-add *really* adds a lot of stare the risks in the eye and march forward. If the value add is marginal, make sure the meta-benefits (performance, maintainability, etc) are clear and understood, otherwise you may be facing a train wreck of an upgrade.

Seen it many times, always wary of the ngXYZ project...

Remember that Apple got sued by a Swiss Rail company because of the similarity to the classically swiss clock.

This is just Apple being punitive against the Swiss in general...

'We will crush them..'

Please ignore, accidentally posted as AC. They may have got rid of beta, but now have a small login expiry, and the site looks the same logged in or not...

Reposting as a non AC.

There are some reasons for the unrealistic job descriptions, they are a lure, and are generally loosely associated with the role (ie: 80%). We're hoping for a purple unicorn, but know that they don't exist. But would settle for a winged horse, a unicorn, a purple horse or more realistically a good horse. But occasionally one of the unrealistic mix of experience does come through.

It has been almost a decade since I last went through an applicant list for a particular role.

What happens most times now is an application is added to an applicant tracking system. This parses the resume (from word, pdf or text) and creates a database of candidates matching keywords. This meatgrinder approach means that when I am looking to fill a position, I don't actually look for applications - I might - or the HR might quickly review the actual applications. What I do is search and screen. Search for a set of keywords, and from that list look for obvious issues (applicants to every job, rejected candidates, age of resume, etc). And then the HR recruiter will screen down from there.

I'll typically get 20 or so resumes to review. The recruiter may review 100 to 200 resumes. There pool of candidates may be 2000 to 3000 of which only a small portion are for my position.

This is part of the reason that resumes have gone from minimalistic to more fully descriptive with keywords sprinkled throughout them.

I've been to Foxconn factories in Shenzen, and there are clearly opportunities for deeper automation. However, this will only be possible when the underlying hardware design has been designed for automation.

At the PCB level, pick and place achieves amazing automation and performance with smaller than rice-grain size components used in modern electronics. That is a given.

At the assembly level it isn't so easy to automate with a lot of the designs. There are flex cables, adhesive, torque sensitive screws that all rely on a human to be able to manipulate and then quickly respond to misalignment. To automate this, the design constraints placed on the Industrial Designs need to change. For low and mid-range products where form is not at the level of Apple integration, this will probably increase the automation. For the high end where every mm counts it's unlikely that there will be a high level of assembly automation.

I'm not anywhere near knowledgable about medicine, but if the brain is larger, does the cranial cavity grow increase to the same level?

I wonder if there a round hole, square peg kind (big brain, small cranial cavity) of issue coming. The brains might be smarter, but they may suffer from decreased mental abilities from intracranial pressure.

Title aside, the ability to code is a workplace requirement, and if you are not looking at traveling/work internationally, you aren't going to get very far without a degree.

Some of the "college drop out" success stories are no longer just coders. They are now C-Level executives, different rules apply. If you don't have a degree then in general you won't be eligible to get Visas to work in other countries.

Independent about how good you are, without a degree you are restricted to your local geography (country, etc).

I would agree with this too. For that telescopish feel, you can get tripod mount attachments for most binoculars. Allows the adult to point the binoculars, swap to the kid without too much trouble.

Define actions (instant, daily, weekly alerts) for ranges of CVSS scores http://nvd.nist.gov/cvss.cfm?c...

Track incoming CVEs (http://nvd.nist.gov/download.cfm) , assign CVSS scores specific to your organization. Also have a organization specific remediation approach.

As you find out who is using what software, and use the CVE CPE (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2168) information to target more specific users.

In the blast emails, you could potentially harvest who thinks they may be affected to gather CPE information.

It's going to be a thankless, painful job, so you may as well automate as much as possible.

There will probably be a market for this in the tech enthusiast. But it will be highly unlikely to go mainstream. Mainstream (iphone 5s) is 7.6mm thick and weighs. According to http://motorolaara.com/2013/10... it is probably about 9.3mm - effectively as chunky as a 2 year old device.

What may evolve from this is specialist hardware and specialist configurations.

Some interesting spin-off technologies might be high speed bus interconnects (thunderbolt 2), modular and novel hardware configs (3d scanning - project tango, yotaphone - e-ink backside). Ultimately, enabling technology advances is what google spends it money on these days...

The report doesn't really go into an important measure.

What is the defect density of the new code that is being added to these projects?

Large projects and old projects in particular will demonstrate good scores in polishing - cleaning out old defects that are present. The new code that is being injected into the project is really where we should be looking... Coverity has the capability to do this, but it doesn't seem to be reported.

Next year it would be very interesting to see the "New code defect density" as a separate metric - currently it is "all code defect density" which may not reflect if Open Source is *producing* better code. The report shows that the collection of *existing* code is getting better each year.

That is different. My read of the GINA is that your health insurance provider is not allowed to use genetic screening to make coverage RISK decisions. As in, they can't force or require you to screen for cancer and then decide that you aren't coverable because of BRCA. Apparently life insurance is not covered by GINA, so that is another issue.

Also note that GINA is an American law. Not global.

The comment I made was about tuning treatment based on genetic information - which is very different. Rather than a cocktail of drugs to suppress and support different side effects and responses - you can more targeted doses to resolve your direct issue. Warfarin is a good example, too much doesn't help, too little doesn't help. Your genes help identify what your correct dose is.