Few weeks ago, I was travelling to my hometown by a bus. I reached the pick-up point at scheduled time, but when I arrived, I found that the bus was late.
Finally after a wait of 2 hours, the bus arrived and the driver found himself in the middle of many angry passengers who were also waiting for the bus. After a while, I patiently asked the driver, “What was the problem?”. To which he replied, “The bus is having problems since last 4-5 days. I told the management that we need at-least 2-3 days to fix the bus, but they are not ready to listen. They are insisting to run the bus by doing a quick-fix for the time being.” I again asked him, ” Are you sure it won’t fail again?”. He replied, “We’re not sure, let’s pray that the bus does not fail.”
It was an overnight journey, I started thinking, why is the crew taking such a risk of using a bus they are not confident of. There were kids, old people on that bus. What-if it fails in middle of nowhere?
How many of us have encountered such a situation before in our own professional lives?
Have you ever been asked to ship a low quality quick fix, so that the software can be shipped into production quickly?
Have you ever been pressurized to develop a piece of code in short time, thereby giving you less time and opportunity to produce a good work?
I have been in such situations too and to be honest, I’ve even done that. I’ve succumbed to pressures. But is that the right thing to do?
People from these professions, such as doctors, construction engineers have an obligation towards the society and that obligation is to protect human lives first.
Software these days, is no different. Software is everywhere. It’s being used to suggest what medication a patient should get, it’s driving cars for you, it’s even bringing you from top floor to the ground floor of the building you live in. It’s omnipresent.
And the onus to ensure that it works as expected, is on us. People have lost lives, due to bugs in software, it’s as real as it gets. Developers these days, are now being held accountable for the work they produce.
So if you are not sure, if you’re code will as expected, if you are not sure, you’ve covered all edge cases, if you are not sure that the quality is up-to the mark, learn to say NO, take a stand. (But remember, when you do so, do it with a proper justification too.)
