I parked my car in my usual Park-Ride facility and was walking to catch my light rail to my office. I had to enter the parking lot # to buy my tickets. I remembered it, but I was reluctant to take a chance. My train had arrived, but I was prepared to miss it and go back and check my lot#. I walked back to the lot and verified it. My memory was right.
When I reflected back on that incident, I thought it was too risky to rely on my memory and the cost of default was not proportionate to the risk that I take (The cost of towing and the frustration that accompanies with it was just too much to take). The imbalance made me to go and verify it.
Why don't we do it for our own projects? Before we release a piece of code, do we think if it is worth releasing a buggy piece of software? Do we weigh the cost of default to the urgency? Probably, if we start to, it might help us to avoid a lot of unnecessary chaos that we are causing to the IT services industry,
Dude.. I think it is the theory of relativity...
ReplyDeleteIn case if you had a very important task to attend and that you had to be on time, you would not risk missing the train, in-fact you will not even think twice about your parking lot number .
Likewise if time outweighs quality no one thinks of quality typically seen in IT services.
Are you saying that IT SERVICES are intentionally releasing software even while knowing that there are bugs?
No. My point of argument - How many of us really know the cost of a bug? We know we have tested it enough, but we are not 100% sure. But we still release it. Because we don't associate a BUG-COST to it. Lets assume somebody analyzes and puts a cost to every bug and then tells the developers about that cost, before they start development, I am pretty sure the quality of the solution will dramatically improve.
ReplyDeleteIt is good to cross check before we go ahead. I appreciate youe view point
ReplyDelete