Slashdot Mirror
Anatomy Of A Bug In Microsoft Office
bender writes "An insightful look at what it is like to track down and fix a bug in Microsoft Office is available from Microsoft's Blog site."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Actually, I have to be honest and admit that Microsoft Office is a good product. Its stable, has alot of nice features and is intuitive to use.
I am not _at all_ a fan of M$, but we should be fair about this. Office is pretty solid.
Describes a huge chunk of my life in Software QA. It's an example of what is great about MS software and what is awful:
Great: dedicated test resources to chase down corner cases/non-obvious scenarios, accountability for broken scenarios, etc
Awful: Iterations of releases built on legacy code means no one (or two, or three) people can understand the problem or scope the fix.
For all the complaints here about MS code I wonder that no one has noticed the Windows weakness that is not getting exploited..? If MS software is really as bad as everyone here makes out then why doesn't someone do it better? Blah blah Linux blah blah... Build software for Windows that people can use without rebuilding their systems. If you do it well enough tell them it's even better on Platform X.
I'm sure Word has a milti-million line codebase. But so does AIX. It's split into different components, and there's quite a few bugs where I know roughly which code must have been running. So stare at the code for a few hours envisioning different inputs/control flows, and eventually a case that's not accounted for properly will show itself.
Bah. Amateurs.
Cheers, Matt
Terrorist, bomb, al Qaeda, nuclear, yellowcake, kill, assassinate. Carnivore is dead... long live Echelon.
have you ever actually released software into the wild?
I came across a bug in one of my active enterprise systems today that I had never seen before, and none of my 1500 users had reported it. It would have never been found had i not been just screwing around with random things.
Give the MS guys some credit here, they have a lot of things to go over with constantly looming deadlines. You can't test EVERYTHING.
?SYNTAX ERROR IN LINE 42
You can blab and whine all you want about complexity. Then you gotta explain why, since Word 95, there's been an issue with Section Breaks spontaneously changing type, and causing page numbering problems.
Still exists in Word 2003.
Countless usenet posts exist describing the anguish of VBA programmers when they encounter this bug, classify the behavior, report it to Microsoft, find out it's been a known issue for over 9 years, with no plan to fix it.
That's not caused by complexity. That's caused by bad management. Folks with no conscience. No pride in their work.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Once you tie Word down, hold a knife to its throat and say "No. Really. I know what I'm doing -- back off," it's really quite good.
It's not an issue of bugs, it's an issue of features turned on by default. Unfortunately (as I said above), you need to call off the dogs in about 100 different places before Word becomes really good.
Cretin - a powerful and flexible CD reencoder
This should be marked +1, Insightful. You only think you're being funny. But when a bug affects every one of your installed customers -- such as a security bug or a major feature change -- you had better be damned sure that you fix it completely and that the fix does not break behavior that third parties have come to expect.
Take this Active X thing. Do you realize how many essential web components, many of them from companies that are now out of business, would stop working if ActiveX were turned off altogether? Many, many websites would stop working, and you can bet the people running them would blame Microsoft. Poor security doesn't cost you anywhere NEAR as much as losing ISVs would. So you spend a lot of time planning, reviewing and executing the patch, and equal time testing it.
But bugs in trivial features? Shit nobody uses or really cares about? You can fix that really quickly, because if the fix is still broken, it won't make much of a difference. You don't need a tiger team or testers working late hours. You can put a single intern on it and get it "done" in an hour.
It's a matter of caution, not priority. When the potential fix affects the core of your business, you move slower fixing it. You release work arounds while you're planning and testing. And you slowly roll out the repairs.
Hey freaks: now you're ju