One of the comments on the article points out a Romanian mathematician named Bernard Bereanu, who "figured out in the 70s that the cold war and the nuclear standoff is doomed sooner or later to produce such incidents, pretty much bringing inadvertently the two superpowers on the verge of extinction through a series of mistakes."

I suppose it would be appropriate to add nuclear mistake to the list of other other incidents, such as asteroid impact and volcanic eruption, which could potentially result in an extinction event on this planet. While the probability of a single incident resulting in a world-wide catastrophe may be small, over time the probability of such a catastrophe occurring approaches 1.

If you're really serious about tracking metadata, it may be worthwhile to take a look at some of the tools offered by caBIG:

https://cabig.nci.nih.gov/

The caBIG tools are geared toward using a model-driven approach to define precise metadata which promote semantic interoperability. Underlying the caBIG tools is a metadata repository called the caDSR, which follows the ISO/IEC 11179 Standard for Metadata Registries:

https://cabig.nci.nih.gov/concepts/caDSR/

The caBIG tools are all open-source, developed by the National Cancer Institute.

... but what ever happened to natural eyesight improvement?

http://www.iblindness.org/

Just not profitable enough I suppose.

Once upon a time, there was a project that had been underway for 19 months, but had not yet delivered anything to the users. Management was concerned, and was considering drastic measures such as pulling the plug and starting over with a new project team. At this point, management brought in a trusted developer I'll call DT to help analyze the project's status.

After a series of meetings with different project team members, DT gained an understanding that some software components had already been developed and tested, and it should be possible for the team to deliver a workable system within a few months. Seeing this, management relented and decided to give the project team a bit more time to deliver something.

A few weeks later, at a weekly meeting, one of the team members mentioned they were considering using message queues, but he was leaning against using them. In agreement, DT said that using message queues to handle communications between components of the app looked like overengineering. At this point, a developer sitting across the table went ballistic and started spouting semi-comprehensible technobabble about why message queues were needed and how, at a previous workplace, nobody ever would have said this was overengineering.

To be continued?

Perhaps DT's criticism of the message queue approach makes him a duct tape developer in this case.