Forget Identity politics and embrace Community politics…

Worldwide, thousands of years ago, when family groups were in permanent competion with each other for food and resources, tribalism was, arguably, a way of ensuring the survival of our group; if necessary at the expense of others.

Today, the exercise of tribalism, where we seek to define ourselves by our differences from other groups – ancient and modern, political, social or religious – prevents us from developing a compassionate, equitable society.

Tribalism is pernicious because claiming our group is special is almost always coupled with rejecting those outside the group as deficient or defective, and treating them accordingly. This happens at all levels from the local to the international; it is ancient behaviour and probably in our DNA (which is no excuse.)

Before universal communications and when many societies had rigid internal and external social rules it was possible for groups to maintain their exclusivity against outsiders. In the modern, interconnected world, we are all neighbours; it is not now possible to be a citizen of the world while retaining social insularity – domestic or international.

The big problems of today are not between individuals but concern much larger issues: food, health, education, employment, housing etc. They require the consensus of world citizens to solve, not the continuing conflict of fractured groups.

Inward-looking identity politics come with a cost. That cost is the cohesion and inclusiveness of society which we are increasingly rejecting in favour of our personal agendas.

We need to start defining ourselves, not by our differences but by our similarities. We all eat, we all sleep, we all want to be treated equally, we all want to live a fulfilling and unstressed life. Whether we are part of a majority looking outwards or a minority looking inwards, we should start discussing how we can achieve the acceptance of all members of our society, however they voted, whatever they earn, whether or not they share our beliefs.

Digital Drivers – Accidents Programmed to Happen?

The recent accident caused by Google’s driverless car highlights several under-publicised but fundamental problems that must be solved before safe, autonomous cars become a reality. These are discussed below along with examples of the serious accidents software has caused in other areas of transport such as aviation. The question is asked whether the problems of mixed human and autonomous controlled vehicles can, in fact, be surmounted…[see full text: Digital Accidents ]

Virgin Galactic crash: feathering control deployed “without being commanded”

In the recent fatal crash of Virgin Galactic the feathering control, which is used to slow down the craft on re-entry was reported as deploying without being commanded. The pilot moved the enabling control and deployment was immediate instead of on receipt of a further command. It would be interesting to know what software interlocks and overrides there were in the system!

Don’t solve the problem – just suppress the effects!

The long running saga of overheating lithium ion batteries in the Boeing 787 Dreamliner continues. As I understand it, the root cause of the original battery fires was never determined; Boeing’s “solution” was to design a more robust container so that if and when a battery went up in the future, the resultant gases would be safely vented and any heat rise contained.

Why are the words, “Time” and “Bomb” floating ever closer in front of my eyes?

A quality system that allows this to occur must have serious deficiencies.

See: http://www.designnews.com/document.asp?doc_id=271116&cid=nl.dn14&dfpPParams=ind_184,industry_aero,aid_271116&dfpLayout=article

Embedded software bugs get serious

The recent judgement of an Oklahoma court against Toyota Motor Corp that found sudden, unintended acceleration as the cause of a passenger death in a Camry (http://www.eetimes.com/document.asp?doc_id=1319903 ) should mark the end of the complacency that is common in software design, where tolerance for loosely written and partially validated embedded software is commonplace.

This is the first time, I believe, that supposedly reliable software has been exposed to intense forensic scrutiny and has been found so lacking in quality. The expert testimony (partially redacted to meet Toyota’s confidentiality requirements) reports a litany of poor hardware and software architectures, lack of conformity with programming standards and lack of consistent validation.

It highlights in a dramatic way the inherent problems of writing reliable software where the paradigm is one of implementing many parallel, asynchronous tasks, each written from scratch in a weakly typed language (‘C’ or ‘C++’).

The wakeup call has two parts. The first is to do the best we can with existing design tools – to actually design, review and test software architectures before we write code; to get serious about validation and not just accept as good enough the fact that the product works when you switch it on (proof of final operation is never sufficient proof of fault-free design). The second is to push for low fault design tools that isolate the programmer from as much line by line coding as possible, and to seek inherent fault detection architectures in which a combination of hardware and software limits the damage that a rogue task can inflict on its peers.

It is still very early days for these latter solutions that incorporate, for example, hypervisor software layers and micro-coded memory access restrictions, and they are still not universally welcomed by designers. However, the writing is now on the wall: the acceptance that software by nature contains bugs and that the solution is a ‘reset’ will no longer be accepted by a judge, or by a coroner !