This year marks the 22nd anniversary of the world’s most catastrophic industrial disaster at the Union Carbide plant in the Indian city of Bhopal. On the morning of December the 3rd, 1984, 40 tonnes of Toxic heavier-than-air Methyl-Isocyanate (MIC) gas were accidentally released to spread across the surrounding roads and streets in Bhopal in the Indian state of Madhya Pradesh.
Thousands of people’s lives were abruptly terminated. The entire city’s transportation system was brought to a standstill, worsening the situation further, as many people were trampled while trying to flee.
People woke up to find their bodies burning, their family suffocating, and ran out to the streets to escape, only to find that those before them who had been blinded by the gasses and were aimlessly rushing in unknown directions eventually collapsed to the asphyxiation of the mortifying gasses and died, lining the streets in piles.
The effect of the gasses rolling out of the holding tank eventually injured from 150,000 to more than half a million people, and the death toll reached 15,000 people. Many sources confirm that contamination is still present in the region.
The damage from the gasses ranged from respiratory diseases, blindness and skin diseases, to reproductive problems.
- “There were thousands of bodies. There were bodies everywhere. And people were dying all round.”
- Mohammad Owais, a volunteer at Hamidia Hospital, Bhopal, India
The Causes of the World’s Greatest Industrial Disaster
In the investigations that followed this disaster, the catastrophe was attributed to many factors, tragically, all of which did not have to happen, and were completely preventable. These included:
- Lack of preparation for this sort of problem. No action plans were available for emergencies, and no contingency plans available to mitigate risks.
- Reports issued months before the disaster predicting something of this magnitude would happen, and they were summarily ignored and never presented to senior management.
- An Audible External alarm that was sounded to warn residents in the early morning hours, was quickly silenced – to avoid causing panic to residents.
- The gas burning exhaust tower that allows gases to burn off before escaping into the air was inoperational, waiting to be serviced.
- Doctors and Hospitals were not informed of the risks of MIC inhalation, and of its treatment methods – so they simply administered cough medicine and eyedrops to their patients.
- “We have to travel at least two kilometres to get clean water… My health is so bad that it prevents me from carrying the water I need from there.”
- Hasina Bi of Atal Ayub Nagar, a neighbourhood in Bhopal near the plant
How is this related to what I do?
You might think that this is very remote from your daily line of work. This is a problem in a different industry, a chemical plant, so far away from me, in an Indian city whose name I can’t pronounce, by a company I’ve never heard of before.
That’s the problem. The entire statement above is false. The difference in industry is immaterial, Union Carbide’s now infamous name has become immortalized down the industrial hall of shame. There are people who rally against Union Carbide, and its new owner Dow Chemical every year on this anniversary, all over the world. India in this case represents exactly what Egypt does in terms of attractive labour-cost and more fundamentally, lack of attention to audits, risk awareness, reviews and safety measures.
- One reason, according to the Canadian Law Professor Jamie Cassels, who has written a book on Bhopal, is “the unwillingness of the industrialised countries to forego the competitive advantages offered by the less developed world.”
Unlike a Natural Disaster (like an earthquake, volcano, tsunami or the like), Industrial Disasters are caused by mankind. The fateful truth is that more often than not, they are caused by varying degrees of negligence and ignorance.
Let’s look at some of the root causes of this calamity listed above, and examine them with an eye critical of behavioural traits in our human culture. In our society there is a tendency to ignore “safety nets”, measures taken to ensure completely smooth delivery are often thought of as being a luxury – if you can just barely get it through the deadline, then you’re a genius. Remember what happened a few weeks ago when the fire alarm sounded 10 times in the company? How did we react? Do we know why it did that?
There is an obvious trade-off between risks-assumed versus quality-expected in every human endeavour. If you are driving a donkey-cart on a side road, some may say its okay not to have to tightly pack your payload on to the donkey cart. What’s the worst thing that could happen if you drop something? You go back and get it!
If you are on the ring road, and the car in front of you all of a sudden drops a traveling suit case in the middle of your lane, you probably won’t live long enough to explain to the other car’s driver how dangerous it is to travel without securing your payload first.
The reality is, if the project fails, the client will never appreciate the shortcuts you took to save them the extra mile at their expense when in reality the client’s safety is being jeopardized. Sometimes people think that developing software in a Professional Services firm such as ITWorx is a relatively safe enterprise – and that no bug (or fault) can hurt anyone. On the contrary, we are conditioned to think that avoiding “extra” safety procedures pays off.
Here’s what you could typically hear the root causes to the disaster being dismissed:
- Lack of preparation for this sort of problem: “Yaa Raagel, this thing happened only once in India, Kabar Dimaghak!”
- Reports issued months before the disaster predicting something of this magnitude would happen: “Maho this is the way we’ve always done business, would you just shut up and go on with your work?”
- An Audible External alarm that was sounded to warn residents in the early morning hours, was quickly silenced – to avoid causing panic to residents: “Why make such a big fuss about something? How bad could it be anyway? What does an early warning mean by the way?”
- The gas burning exhaust tower that allows gases to burn off before escaping into the air was inoperational, waiting to be serviced: “It’s okay, maho nothing usually happens anyway – we rarely use it!”
- Doctors and Hospitals were not informed of the risks of MIC inhalation: “Da Kalam? You want me to go around scaring the Doctors about something they don’t need to know about? Even if I tell them, they won’t understand. Just shut up.”
Software faults can actually be fatal. Software Bugs can kill you, they can squander all your money – wasting millions and millions of it – they can put you at great disadvantages in the institutions that rely on systems full of them, they can waster your time, or merely inconvenience you.
The point is, the larger the project you are undertaking, the higher the risks. Sometimes taking shortcuts is not an option.
Big Boxout: Am I a Catastrophic Developer?
- This section asks several thought provoking questions about the way we conduct business in the computer science arena and how that will influence our delivery standards. Take a moment to think of each of these questions carefully.
- Do you manage transparently?
Do you Version your deliverables?
- If I asked you which version of your software was installed at the client’s location, would you be able to give me an exact number? Would you be able to reproduce that numbered version from your source repository to match the version at the client’s byte for byte? Would you be able to guarantee that for every version “number” there would be one and only one actual version associated with it? Can you tell the difference between each minor feature adjustment or bug-fix? Are your release documents updated to reflect changes?
Do you conduct full traceability on all dimensions of your project?
- Do you think they are a waste of time? Do you know that they are the only way to scientifically prove the completeness of your deliverable? Do you know that without traceability you have no way to securely guarantee scope completion?
Do you Unit Test your work?
- Do you use a good unit-testing check-list? Do you know that ITWorx has a recommended unit-testing check-list? Do you know that the developer is the one who is supposed to run these tests before submitting their work for testing? Do you just deploy your code to the testing server the minute you think its finished and leave it those testers to find out if it works or not – because that’s what they’re job is anyway?
Do you conduct proper, full audits?
- Do you intentionally mislead auditors or give them half-truths? Do you conduct Mechanical-Audits? Just asking questions without searching for hidden truths? Do you understand why the auditor visits you? Or do you hate their guts? If the auditor asks you a seemingly useless question do you pray that they disappear or do you raise your concern with them?
Do you communicate properly within your team?
- Do you pause after you make changes and ask yourself “which stakeholders does this change impact?” and then notify them? Or do you often wait until one day a group of team mates starts screaming and yelling about fundamental changes that have been done behind their back?
Do you give your Risk Management plan due dilligence? Do you keep it updated?
- Is your risk management plan just composed of “Volcanos cannot be mitigated”? Do you periodically re-visit your Risk Management Plan to make sure that nothing new has surfaced? To make sure that you are increasingly ready for risks coming up on your radar?
Do you re-invent or re-use the wheel?
Do you review your work?
- Do you peer-review your designs? Do you check that your packages actually install? Are spelling mistakes important to you?
Have you considered emergency procedures?
- Do you have plans to support your clients with high severity issues? Do you not think about this because it is not mandated explicitly by anyone?
Boxout: We’re Doomed – I can’t do anything about these problems!
- If you’ve read some of the questions in the “Am I a Catastrophic Developer” panel, you probably guessed what the right answer we are hinting at was. How can I avoid disastrous development given cost-constraints?
- Here is a simple recipe to managing risks in a way that safe-guards you against catastrophic development:
- Take a minute to think of this – and make your own decision. Ask yourself: “Do I want to be part of a project that will produce a potentially catastrophic development?”. Set your own standards.
- When you make your decision – make a point of taking time out every day – give yourself a minute to think of any major risks you may have glossed over today. Is there any one that your work today may impact negatively, either today or in the future?
- Make sure you are always current – new risks and new solutions are identified every day in our dynamic industry. It is your prerogative to make sure you are always current with technology.
- Learn how to make balanced decisions to deliver efficient risk management, and if you don’t know how to handle a specific situation, don’t just leave it – share the risk transparently with those responsible in your team and take educated decisions, even if you need to consult the client. Your experience will only grow by observing and asking mentors to give you their experience too.
- Finally if you are asked to blindly work on Impossible Situations where catastrophes are imminent without transparently communicating links to all stakeholders (including the end client), then make your own judgment call – are you going to be a part of the catastrophe, or the mitigation?
The Obligation to Fight Catastrophic Development is everyone’s responsibility. If you don’t, you bear on your shoulders the responsibility of potentially bringing harm on to others, perhaps very grave harm. The irony is that you can be a very hard worker, and yet by ignoring certain precautions, you can still be a catastrophic developer. One can only hope that we are always alert and aware of this fact. Our only defense against this is to continue to seek to be armed with knowledge, alertness and integrity.
For further information, please browse these links out. Please note that the content in these pages can be deeply disturbing.
Software Related Disasters:
This post was originally published in ITWorx Insite (April 2007).