Slashdot Mirror
Big Challenges for Vista Bug Hunters
The New York Times is reporting on the final rush to bug fix Windows Vista. Even with massive numbers of testers and five years of work behind them, the folks in Redmond are pushing it to the wire in order to make sure it releases soon. From the article: "Vista has also been tested extensively. More than half a million computer users have installed Vista test software, and 450,000 of the systems have sent crash data back to Microsoft. Such data supplements the company's own testing in a center for Office referred to as the Big Button Room, for the array of switches, lights and other apparatus that fill the space. (A similar Vista room has a less interesting name -- Windows Test Technologies.) This is where special software automatically exercises programs rapidly while looking for errors."
Further delay aint happening. Vista will be out the door, regardless of the remaining bugs. They still have 'patch tuesday' to make updates, and the installation sequence itself already includes an initial update phase. So any really big bugs that remain present in the RTM build can still be fixed later.
To Terminate, or not to Terminate, that's the question - SCSIROB
I know a guy who used to work on test suites at Microsoft who has since quit, given their awful attitude towards bugs in Vista, and got a Mac
You'll see this kind of attitude in every bigger software company. I've had personal experiences like this in Adobe and Macromedia with their flagship products. Features are dropped, specs constantly changing and inconsistent between teams.
In some cases, you can spot the same feature implemented twice in source, with different interfaces, in different locations, and code linking randomly to one or the other, or even both (imagine updating this).
The bugs to be fixed are selected first for how obvious they are (likely to occur) and not how critical they are. This is why it's common that bugs that can totally wreck operation and lead to data loss may be left, if the occurence is rare or unlikely.
Everybody is in stress and the main goal is that you get the reviewed bug off your shoulders: if it's mildly reminiscent to something else, it's marked duplicate. If you can't reproduce it quickly, it's marked as fixed or not reproducible. Tricky bugs are marked "fact of life" or "deffered".
Successful companies and their products grow, but the way the products and resources are managed does not scale. Instead, programmers are expected to churn a major release every X months, screw everything else, and keep the cash flowing, the investors happy.
With Windows, we have a successful product that supports a huge ecosystem of applications (including legacy support), localization, usage cases etc. It's natural that in time, updates will become more rare, and will be much slower and more expensive to produce.
The trend of software-as-a-service is not coincidental with this situation. In 5 to 10 years the base software we use might be so complex and tough to work on, that the only way it can be sustained is by small, regular payments, and the updates will be small, incremental, security/performance oriented. No more big releases, no more rushes to fix bugs in the last moment.
This is the way evolution works. The other route is, of course, revolution...