Comment The Truth of Software Development (Score 1) 529
Articles like this one are very ignorant of reality.
First, comparing software development and applications to bridges and cars is ridiculous. If cars broke apart if any part in them was misinstalled by so much as a tenth of a millimeter (the equivalent of a line of code), we'd see a LOT more problems with cars. In truth, a car is a hell of a lot more fault-tolerant than software. The same with bridges. One misplaces screw won't bring down a bridge, but one miswritten line of software will bring down the application.
Second, as for some of the other facts in the article, here's the ugly truth: software quality has to be weighed against the cost of producing that quality. When a company puts out a software product, it has to weigh the quality of the product (the more bugs in the product, to lower the reputation of the company) against cost (in this case, time-to-market: if you are late, it doesn't sell). What would have happened if id software just NOW put out Doom, totally bug-free? Could it compete against the more-buggy but nicer looking games like Half-life? Not a chance.
Also, as a user, do you want to wait an extra 5 years for a product? If you have a million lines of code, it could easily take that long to fully test it. And remember, any fix put in for a found bug can easily create more bugs (as a developer, I certainly know this is true).
It all comes down to this: it is impossible to write bug-free code (of any realistic complexity, at least). It is not cost-effective to test code until it is (visibly) bug-free. The best a company can do it make a product bug-free enough to have users want their product.
One more thing: cars have bugs in them all the time. That's why you need a warranty. It's the car-equivalent of sending out patches after the car is shipped (and if the bug is bad enough, a recall).
First, comparing software development and applications to bridges and cars is ridiculous. If cars broke apart if any part in them was misinstalled by so much as a tenth of a millimeter (the equivalent of a line of code), we'd see a LOT more problems with cars. In truth, a car is a hell of a lot more fault-tolerant than software. The same with bridges. One misplaces screw won't bring down a bridge, but one miswritten line of software will bring down the application.
Second, as for some of the other facts in the article, here's the ugly truth: software quality has to be weighed against the cost of producing that quality. When a company puts out a software product, it has to weigh the quality of the product (the more bugs in the product, to lower the reputation of the company) against cost (in this case, time-to-market: if you are late, it doesn't sell). What would have happened if id software just NOW put out Doom, totally bug-free? Could it compete against the more-buggy but nicer looking games like Half-life? Not a chance.
Also, as a user, do you want to wait an extra 5 years for a product? If you have a million lines of code, it could easily take that long to fully test it. And remember, any fix put in for a found bug can easily create more bugs (as a developer, I certainly know this is true).
It all comes down to this: it is impossible to write bug-free code (of any realistic complexity, at least). It is not cost-effective to test code until it is (visibly) bug-free. The best a company can do it make a product bug-free enough to have users want their product.
One more thing: cars have bugs in them all the time. That's why you need a warranty. It's the car-equivalent of sending out patches after the car is shipped (and if the bug is bad enough, a recall).
