| Date: | February 2, 2007 / year-entry #37 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070202-09/?p=28183 |
| Comments: | 42 |
| Summary: | The ironic thing about fixing a bug, or at least once I mention on this web site that I fixed a particular bug, is that people immediately complain that I didn't fix some other bug. One school of complaint believes that cosmetic bugs should be fixed first: "You suck. I mean, look at these egregious... |
The ironic thing about fixing a bug, or at least once I mention on this web site that I fixed a particular bug, is that people immediately complain that I didn't fix some other bug. One school of complaint believes that cosmetic bugs should be fixed first: "You suck. I mean, look at these egregious cosmetic bugs. If you can't get even those right, then obviously you can't get the other stuff right either." The opposite school believes that cosmetic bugs should be fixed last: "You suck. I mean, why are you fixing cosmetic bugs when there are these other bugs!" But at least both camps agree on one thing: I suck. I think I'd be better off if I said I didn't fix any bugs at all. |
Comments (42)
Comments are closed. |
Geez, why are you wasting time blogging when you could be fixing bugs?!
I wish I had time to comment on this but I have too many bugs to fix.
-Wang-Lo.
Well the problem is the lack of transparency with how Microsoft fixes bugs. There is no bug tracking database, no mailing lists to look at. And major releases of software can take up to 5 years to come out, so who knows how or when a bug will get fixed. People feel a lot better if they can keep an eye on bugs they care about.
Contrast this to Linux; recently I found a bug that only manifested on Sun niagara systems. I did some testing for the sparc architecture maintainer, he figured out the problem, posted the reason on his mailing list and blog, and within a week the fix is in the latest linux kernel release candidate (which I know because a detailed changelog is published with each release).
If there were some way to complain about Microsoft bugs that didn’t require a credit card number I am sure some people could find more productive things to do than whine about the bugs on developers’ blogs…
"Well the problem is the lack of transparency with how Microsoft fixes bugs."
If I were a cracker/hacker, I would love for MS to publish every little bug so that I could go expoit it on non-patched machines.
Also, bug fixes give general insight to proprietary information, "Oh, they fixed it like that, it must work like this…"
You suck, why are you fixing bugs when you could be blogging?
I am of the opinion that Microsoft bugs should be fixed first, and next to no time should be spent trying to keep 3rd party software running bug free – solely because they implemented it wrongly in the first place!
I am referring to an article that I read in TechNet about how a 3rd party application was looking for the map network drive item when right clicking my computer.
But anyway, enough from me, i should be fixing my own bugs…
"and next to no time should be spent trying to keep 3rd party software running bug free – solely because they implemented it wrongly in the first place!"
It’s not like they spend their time ensuring compatibility of 3rd party systems because they feel bad for them. If Microsoft wants people (or, more importantly, businesses) to adopt (i.e. buy) the latest version of windows, all of their old and mission critical software HAS TO WORK. No one is going to pay for an OS upgrade that breaks all of their stuff. This isn’t benevolence on Microsoft’s part, it’s common business sense.
"This isn’t benevolence on Microsoft’s part, it’s common business sense."
Unless you are Apple, in which case you force developers to fix their bugs. But its quite a different culture and situation.
…and then there are the people who liked the bug and are annoyed that you fixed it.
Mark: You might like to look back and see who wrote the article you mention :-)
Talking of cosmetic bugs, Microsoft Update produced a fairly amusing display yesterday (screenshot: http://deadnode.org/bug.png)
Chet: Keeping the bugs ‘secret’ works very well, which is why there are so many more exploits for Apache than for IIS … right…?
I’m with Vince on the transparency: I’d really like to get some sort of update on the issues I report when things make XP Bugcheck, and indeed the Windows Error Reporting stuff – the ‘subscription’ thing with Passport for Bugchecks is a step in the right direction, at least, but still pretty limited. A nice obvious route for reporting non-crash bugs without paying for the privilege would be nice; ISTR ntbug and iebug (both @microsoft.com) worked a while ago, but I can’t even remember where I saw them mentioned originally.
On the other hand, fixing whatever made the Vista installer hang on boot last weekend is probably more urgent :-/
"Well the problem is the lack of transparency with how Microsoft fixes bugs."
Nah, the real problem is that people only care about the bugs they’ve noticed or heard about. If you fix a bug that no one knew about, in their eyes you haven’t done anything. In fact, now that they know about the bug the product may look worse.
Those aren’t bugs, those are FEATURES.
You think that’s bad, try telling someone that you did something that they consider "a new feature" instead of a "bug fix". (Never mind that this "new feature" fixes 100 bug reports, it wasn’t their pet bug, therefore it’s bad).
Good job most cosmetic bugs are fixed in Vista and/or Office 2007.
It’s been done by making everything look/behave differently to everything else, so there is no such thing as a "cosmetic bug", since there is no longer a "cosmetic standard".
"Well the problem is the lack of transparency with how Microsoft fixes bugs."
Someone’s never heard of Connect yet… http://connect.microsoft.com (Look in the "feedback" link of each category.)
I was just about to mention Connect. People are quick to make judgements…
>If I were a cracker/hacker, I would
> love for MS to publish every little
> bug so that I could go expoit it on
> non-patched machines.
So what’s the alternative? They never publish bug-fixes? If I were a hacker/cracker I’d like that more. Instead of only the uninformed being vulnerable, *everbody* will be vulnerable.
Any hacker/cracker capable of writing an exploit can probably figure out what the "bug report" is by comparing the differences on a patched/unpatched system. Security by obscurity doesn’t really work well in this case.
Well, as long as the bugs you fixed
a) really were bugs
b) really were fixed.
c) didn’t break anything for someone else working on either a cosmetic of fundamental bug
d) wont get made into dead-code when someone fixes something else
Then you should be happy, stop moaning, and make up your mind about how to triage your bugs effectively and write a blog post with that advice so none of your readers have to suffer.
Goodness, what is the world coming to when Raymond compains he can’t prioritise his bugs to keep people happy (Is this an endemic Microsoft problem. hmmmmm…)
When you only have 1.7% market share, it’s easy to talk to all of your developers…
I don’t think that’s "irony" in the true sense…
Personally, I subscribe to the old adage that it’s not very useful to put lipstick on a pig. I’d rather have software that works right first, and deal with cosmetic issues later.
I once worked on a product where the lead designer decided that one dialog needed reworking so it would be more interesting. The problem was that the feature behind the dialog was badly broken. I argued that given our limited resources, it would be better to spend time fixing the feature and rework the UI later. I lost.
Whoever claims that Microsoft is keeping compatibility should wake up — Vista broke a bunch of applications including Microsoft’s own Visual Studio 2005. Yes, I heard about SP1 and Vista Beta update but you still can’t debug if you don’t run IDE as admin even if dreaded UAC is off.
By the way, installing VS2005 SP1 even with UAC off so it doesn’t check for digital signatures of each file takes enormous amount of time even on the high-end machine with total experience index of 5.0, RAM index 5.5 (2GB DDR2-800), and HDD index of 5.9 (10K RPM Raptor drive!). Most annoying part is “Time remaining 0 seconds” which stays on your screen for solid few minutes.
How incompetent one has to be to write an installer which can’t even judge the time needed to perform an operation, much less do it in reasonable amount of time even with plenty of system resources? What kind of bug fixes can you expect then?
"Note that predicting how long an operation will take is not easy."
Not easy, and more often not even possible. Instead, you should break the task down into X units of work and display a percentage complete.
This is hard as well. The thing with Windows Installer is that it actually CAN provide pretty good time estimates for standard, built-in stuff (like copying files, creating registry keys, etc).
It CAN’T provide a reasonable time estimate for custom actions, because (by definition) custom actions can do ANYTHING. So you change the problem from "how long will this custom action take?" to "how many ‘units of work’ should this custom action count as?" It’s basically the same question.
It’s unfortunate that a lot of the install process for Visual Studio is implemented in custom actions, but that’s kind of unavoidable until Windows Installer implements a lot of the .NET-specific functions into the core (like registering assemblies, installing into the GAC, etc). Even once it does that, you’d then need to re-write all of the custom actions to actually USE the core functionality, and often times, the required effort is probably not worth it. After all, if your custom actions were correctly authored to begin with, they’d already support rollback, the only thing you’d be affecting is the "time estimate" – a lot of work for a cosmetic change.
Not for us! We’d have to go somewhere else for Norman’s amusing and irreverent rants! Mind you, we probably don’t have to go FAR, but having them all collected in one place, here, is convenient :p~
> people immediately complain that I didn’t fix
> some other bug
Don’t worry about that, some of us complain about your ongoing lies.
If you would even read what you linked to, you’d see that I even cited your colleagues when I was talking about your colleagues. I did not blame you for Visual Studio.
Once upon a time you said you hoped that some of your colleagues, not just customers, would read your blog. Once upon a time, some of your customers expressed the same hope. But maybe Visual Studio isn’t an exception, you hope that the Visual Studio team will help keep your company[*] earning its reputation?
[* Notice: your company, not you. You’re personally earning the same reputation your company has for telling lies, not necessarily for making bugs.]
> But at least both camps agree on one thing: I suck.
When you tell lies I agree with those camps.
As an occasional blogger myself for another company, I say it’s time we turn the table on whiny users that fill the comment sections about bugs unrelated to our article or our responsibility, and begin to write about how we proactivly create new bugs. And since we’re un-firerable, and they need our product, there is nothing they can do about it.
@Dean Harding:
I only had complete MSDN and VS 2005 C++ part installed. It was the VS2005 SP1 installer which was horribly slow with completely unusable progress indication. Moreover, for whatever reason it was holding 450MB of RAM occupied by the main executable (which should have exited after extraction!) during whole update process.
Raymond said:
“Okay, so you vote for cosmetic fixes before core fixes.”
And you concluded that based on what?!?
Of course I don’t give the priority to cosmetic fixes, but time calculation (as opposed to the term “prediction” which you used) can be considered core operation of the installer which all of your products use, and not a cosmetic fix.
Funny how you ignored the part where I said that it would be even better if it could “do it in reasonable amount of time” given the plenty of system resources I have to throw at it. That seems to be the long lost and forgotten programming virtue nowadays.
Ulric: Waaay ahead of you; some former colleagues of mine uploaded a status update earlier today amounting to ‘we accidentally turned the SAN off early yesterday morning, thus disabling the mail servers, print servers, file servers… nearly everything seems to be back online today, though.’ Not even a ‘sorry we knocked out e-mail and file access to 25,000 users for a whole day’!
Getting a rough estimate of the time remaining shouldn’t be too hard: a simple time-stamped log of each operation would suffice. (Pseudo-code: we’re now at the point the developer was at 10 minutes into a total 20 minute process; it’s taken us 15 minutes, so we’ll have about another 15 minutes left. Minor tweak for optional sections/dependencies, and you’re all set!)
Right now, it’s other people who publish bugs in MS products, so you’ve got your wish. The reason they publish the bugs is that MS wouldn’t fix anything otherwise.
> “But maybe Visual Studio isn’t an
> exception…” You said it not me.
My fingers did say that, and I accept blame for the effects of my typo, even though I can’t figure out how I did it. I meant to type “But maybe Visual Studio is an exception…” and I hope that at least clarifies the intended meaning.
> If you’re going to accuse my of lying,
I didn’t accuse you of writing “But maybe Visual Studio isn’t an exception…”. I accuse you of asserting about my posting which you linked to: http://blogs.msdn.com/oldnewthing/archive/2006/09/19/762058.aspx#765775
was blaming you for “I didn’t fix some other bug” even though my posting said which category of your colleagues I was blaming.
"Whoever claims that Microsoft is keeping compatibility should wake up…"
I’d say you’re right about that. After reading on this blog about little shims that are in Windows to keep compatibility with now-obsolete programs, I’m unable to get my mind around the fact that changes were consciously made to DirectSound in Vista that will break every game out there that uses EAX and other such sound card hardware features.
Raymond said:
“Progress bars are cosmetic. The installer operates the same with or without it.”
Just for the sake of clarity — I wasn’t suggesting to fix the progress bar appearance but the time calculation.
Raymond said:
“And my response to “in a reasonable amount of time” was “the impossible takes an unreasonable amount of time.””
I would really like to know what exactly is so impossible in VS2005 SP1 installation?
My point is — progress bar which doesn’t show progress and time estimate which doesn’t show correct estimated time are completely useless features for the end user.
Someone in there got paid to develop, write and maintain those features. They enjoy themselves while you are fixing bugs and complaining about us complaining about you fixing the wrong ones.
I’d just like to say that I appreciate the hard work that Raymond does, both fixing bugs in the OSes I use, and writing this blog to let us know what it’s like to be an OS developer. It’s a shame that he then has to defend himself from personal attacks in his blog comments. Raymond, I hope you won’t let these indignant fools dissuade you from continuing to inform and entertain the rest of us.
Also Re: taking a "reasonable" amount of time.
Different parts of the installer will be limited by different things. Even limiting it to basic HD parameters e.g., transfer rate, buffering algorithms, cache size, seek time, etc., there can be more than an order of magnitude difference in the relative performance of these areas over a couple of HD generations.
Benchmarks that measure these things even somewhat accurately take longer to run than any installer I’ve ever run. Accurate system level benchmarks take even longer. And don’t forget that, at any time, another program, or even another user, can start using system resources in a way that will slow down some parts of the installer, but not others.
The thing I find most interesting about some bugs is that they are not always an improperly coded or designed feature but often a lack of knowledge about how that piece of software works. For instance many people don’t understand that the progress bar requires quite a bit more processing power than one would think and really serves no other function than to give the user a ruff idea of the time an action will take. But if the progress bar is off many people automatically assume that it is flawed when really it was not intended to give highly accurate information but just and estimate of time remaining. This is not to say that all bugs are a lack of understanding on the part of the user and that software can not be flawed in some way.
I just started reading your blog and look forward to every bug, your writing is entertaining and informative compared to the other gibberish i recently removed from my rss reader.
Raymond said:
"The time calculation is a cosmetic feature. The program operates the same regardless of whether the time calculation is accurate."
I must disagree on this view of yours. It is classic Schrödinger’s cat case.
You say that program operats the same, I say it doesn’t. Since there is no progress indicator neither of us can be sure if the program is operational or not. In other words — we don’t have visual feedback to confirm the state of the program.
If you were right, you could then claim that every program works the same with or without monitor.
Truth is that, to the end user, broken progress indicator can mean only one thing — program is broken, it sits in a loop, eats resources like a pig doing nothing because progress bar is not updating or the time estimate sits at 0 seconds remaining for (much, much) more than 0 seconds.
To everyone who said progress bar wasn’t intended for this or that, or to those who say it can’t be done — I am not asking for an accurate estimate.
I just want to know should I go grab a cup of coffee (5 min) or go for a walk with my dog (30 min) or take a two hour nap.
Or perhaps the installer has stopped responding and I should close it and try again? Or start troubleshooting things until I find why it is taking so long to install on a high-end machine costing $3,250?
You’re a dev… you don’t write *fixes*, you write *bugs*. Isn’t that how it works?
Have any of the people who come here to whine and moan actually ever written any software? Sometimes I have to wonder (ducks to avoid inevitable jet of flame).
Sunday, February 11, 2007 5:12 PM by David Pritchard
Some of which [software] might even get burned into ROM and therefore require some amount of bug-fixing before customers see it? Why, who would ever write such a thing?
Or some of whom [people] might even have got caught fixing bugs that were reported to them, instead of denying them? No sane person does such things.