When we write an application or a piece of software, at what point do we usually say "yes, it is completed and ready for release, let's ship it"? This question seems rather trivial in software engineering practices, but the answer matters a whole lot more in the real world.
Lessons from the past
The other day, I was browsing the net and stunned by number of catastrophic events caused by software failures. In 2006, a plane crashed in Amazon rain forest was caused by an error in air traffic control system. Apparently the two planes, with 155 passengers and crews on board, were instructed to fly on the same altitude and collided - none survived. Three years ago, another air traffic system malfunctioning in Southern California caused 800 flights to pile up in the sky. Many of them came close to colliding into one another.
Not to mention one of the largest software system on our planet, the ballistic missile defense system. Back in the '60, the system picked up signal of long range missiles were coming directly toward North America. The US Military went panic, let's not forget that this was in the middle of the Cold War period. It turned out that, the signals they picked up weren't rockets, it's signal reflecting from the moon. It was said that by the time the error was realized, the counter-attack missiles were about to launch. That's fortunate, otherwise, we'll be learning about World War III in social class.
What we have today
I'm in my last year study and specializing in Software Engineering. From what I see though, there have been many practices, methodologies, and processes we've invented and applied to Software Engineering. Yet it remains that software is released for use, not when it is known to be corrected, but when the rate of discovering new errors reduces to the one that developers/management considers acceptable. If this is the case, then isn't software development more skin to the process of trial and errors?
Software vs Hardware
Now some may wonder why despite the fact it seems more difficult to build, hard is less likely subject to argument of errors and malfunctioning, at least when it's still under warranty period.
In comparison to software, hardware development takes another perspective and has different environmental factors. Off the top of my head, hardware often develops under a smaller scope and fewer number of states, while software often deals with a whole systems. Most hardware devices function in a finite sets of state. In each state, system behaviors can be defined in mathematical continuous equation. Therefore, errors are predictable and can be eliminated by exhaustive testing.
Modern software system grows significantly in terms of complexity and often involve connecting multiple disparate systems together. Practices like modularization, software architecture, or unit testing can help reducing number of defects significantly. However, where there are thousands of different units tied together, one simple error can accumulate and stem into an error of totally different magnitude.
Let's also consider that, unlike hardware, software operates under unknown sets of inputs and resources availability. It depends largely on user input. Where there are nearly indefinite sets of possible states, exhaustive testing is not possible.
Today's practice
Most of software vendors have come to acknowledge that they are not likely to survive if they ship their products when it's ready. That's why we see a lot of software patches, alphas, betas, and release candidates, all of which have become an acceptable practice. Users will have to learn to accept that fact and how to sidestep those bugs and errors.
Some critical system, like air traffic control, banking, or health care system, we can't really put these systems out in beta. We certainly can neither tell them that the errors they run into will be fixed in the next patch nor version upgrade. I would not want to be traveling on a plane with software flying it is in any stages but 'done'.
