Categories
All Blog

Small clarification

I realize in reading some of Pierre Igot’s latest posts that the intent of the title of my last post on bugs was not very clear.  In the absense of some specific cultural knowledge of American popular music of the early 1980s, my title “Bugs stink! Yeah Yeah!” could very easily be interpreted as condescending or as a brush-off of user concerns.
That is not what I intended, however.  See, there’s a song called “Love Stinks” (from an album of the same name) that was performed by the J. Geils Band in 1979 or 1980 that was very popular on the radio when I was growing up.  The chorus of the song is roughly this:

(Love stinks)
Love stinks yeah yeah
(Love stinks)
Love stinks yeah yeah
(Love stinks)
Love stinks yeah yeah
(Love stinks)
Love stinks yeah yeah

where each of the “yeah yeah” bits is an affirmation of the sentiment that “love stinks.”
That’s the spirit in which I used the lyric as a title for my post — bugs do stink, and there is much agreement about that. If you look at my post titles, you’ll see that many of them are silly puns or simple plays on words. As I was writing my last post, “Love Stinks” was playing on the radio and I thought it might be a silly little pun to use.
So, if my post title sounded like a brush-off or a put-down, I’m sorry. I definately didn’t intend it to be one.

23 replies on “Small clarification”

I’ve read most of Pierre’s stuff on Office:Mac and on the Adobe CS suite. He is on the mark most of the time, and I think that his criticisms should be taken seriously.

There’s a difference between “taking bug reports seriously” and “puttting up with snide and uninformed comments about people’s motives and the jobs they do”. I’m very happy when companies do the former, because the software industry needs customers who will provide feedback and won’t passively accept what comes down the pike. Honest criticism is never unacceptable.
What’s not acceptable is assuming that engineers at large software companies operate in bad faith with their customers and are incompetent- which is what Pierre implies constantly. That’s what he’s done for years, and these exchanges are pointless. There are better things to do than defend yourself against ad hominem trolling. Pierre would be better not making the fundamental attribution errors he does and concentrate on the bugs.

Mr. Coward:
I think that one should be more concerned about whether the _managers_ for the engineers operate competently and in good faith to the users. Microsoft has justly earned its reputation of being more concerned with the profitability of its operations than on quality. Consider the concept of “opportunity cost” with respect to the advisability of fixing longstanding bugs. The end user, who has paid for each successive version of Office, as one example, in a repeated quest for a bug-free product, is often frustrated when profitability is the main concern.

Mr. Beck,
I’m afraid you really have no grasp of the concept of “opportunity cost,” which is about _time_, not _money_. It’s not about profitibility. It’s about figuring out how to maximize the overall usability of a product over the full spectrum of users given that you can’t possibly accomplish everything that every user wants you to do.

Perhaps the “overall usability of a product over the full spectrum of users” would be maximized by fixing all the bugs in the product? Just a suggestion. 🙂

In the time I have been reading this blog, I have created a very funny mental picture, of how thing must be when you think in parallel about the Win/Mac version of a product.
I think I should be like rich cousin v/s pour cousin kind of tale.
I picture a 100 persons sitting in a round table debating every little detail of the color of the little man it appears in Win Messenger:
-“It should be light green!!”
-“No, it should be dark green, that’s what people want”
Until some guy steps and say:
-“Lets hire an expert in green, and he should have the answer!”
And in the other room, is the mac:messenger team: Just 2 guys chatting…
-”I should be reviewing bugs in office…I think for now video chat in messenger is a no-go, it’s that or VirtualPC won ship this year”.

Warren,
The really funny part is that, yesterday, I’d mentioned to Schwieb that some of you will, from time to time, mock me for having brought up the concept of “opportunity cost.” You are, at least, predictable.
Third Coward,
I see the smiley, but your suggestion presumes both that it’s possible to fix all problems, and that fixing any given problem has zero risk of introducing new problems. Both of those assumptions are false.

Warren — you said “I think that one should be more concerned about whether the _managers_ for the engineers operate competently and in good faith to the users.”
I _am_ one of the managers (well, ok, technically my title is ‘lead’ not ‘manager’, but I do have people reporting directly to me). If I intentionally act in bad faith with respect to a user, I would be fired on the spot. If any of my direct employees were to do so, I would fire them on the spot as well. Although I suspect that your definition of bad faith may be a little broader than mine.
If I were an incompetent programmer, you wouldn’t have the Scrapbook in Office 2004, any graphics in Word X, or be able to load/save and edit the column properties of the List Object wizard in Excel 2001.
Do you mean to say that I, personally, am incompetent and that I act in bad faith? (If you honestly believe the answer is yes, by all means say so. I’m curious to know how far that statement extends.)

I think my point of “these exchanges are pointless” is being demonstrated- you can’t really argue with someone in love with their fundamental attribution error. Essentially, the sky in their world is a different color than the one in yours. The existence of bugs in MBU products has convinced people that the correct explanation is a dispositional explanation of “those engineers and/or managers are lazy or incompetent”, as opposed to a situational explanation (“it’s a complex code base and problem set, with a lot of work to do, and bugs will be a product of that”)… and blog posts from the engineers in question apparently won’t shake people from that belief.

Erik:
I’m sorry if you took my reply above as a criticism of you at all. As I said in response to your last post, I really appreciate your efforts and those of your colleagues. I also really appreciate that you are writing this blog and relating some of the issues that come up in your work. I think that the work you are doing is really important and that it will have a wide impact on the quality of work that people like me do all day and every day.
My point is really about communication (and this relates to the “opportunitiy cost” comment). The end users suffer daily with a few small problems, some of which cause continuous stress when working on documents under time pressure. They have really _no idea_ about the origin of the problem, and when the problem persists after many cycles of updates, they wonder if the problem will ever get addressed. The comments from the various MacBU bloggers help to relate the complexity of the work on the Office:Mac apps, but they do not address the lack of transparency that I mentioned after your previous comment about what has been fixed in the various updates and what will or will not be fixed. I realize that you guys may not be free to publish detailed release notes, but they would be appreciated.
Rick, I’m sorry if you were offended by my reference to your term “opportunity cost,” and it is clear that I do _not_ understand what it means. My take, rightly or wrongly, is that there are limited resources available to address requests for new features and or fixes to existing problems, and that you folks have to weigh all the possibilities. The “cost” part of the term, rightly or wrongly, implies that there are real issues related to money and/or time here; of course, time = money, at least in the old saying.
To conclude this response, I’m sorry if you guys were offended. You should know that although I have tried perhaps every app out there to do long technical writing projects, that I think Mac Word 2004 is the best available tool. I’m rather happy with it, especially considering the available add-ons (MathType and Endnote) that accellerate the production of math- and citation-intensive documents. (I wish that Word had some FrameMaker-like book construction tools and FrameMaker-like autonumbered styles, but those feature appeal perhaps only to technical document writers like me. ) Having apologized for your taking my comments too personally, I’d appreciate your giving your end-users some slack; try to understand our (my) occassional frustration with long-standing issues and the lack of transparency about the direction of the development of the apps.

Thanks to Warren for helping to explain user frustration, which is something that apparently is simply not taken seriously enough. Microsoft engineers and leads and managers might be trying to do their jobs to the best of their abilities, but so are we. However, unlike them, we’re not getting paid for identifying bugs and developing ways to work around them. So yes, we do get frustrated, and harsh words come out. Name one person who’s never cursed their computer. That person would have to be a Zen master. Part of the problem, I think, is that Mac users are, on average, a more demanding bunch. Windows users are so used to bad UI design, bugs, inconsistent behaviours, etc. that they have probably used up all the energy that they had to try and fight the situation. So they come up with “opportunity cost” and “fundamental attribution” and other determinist excuses for lack of progress and improvement. Mac users, on the other hand, still have this idea of what a perfect computer environment could and should be like. When the actual product is and remains so far from this ideal, it’s inevitable that this product and the company that puts its name on it are and continue to be roundly criticized.
Thanks to Erik and Rick for at least trying to understand this and not giving up on us. But as Warren said, there is still a long way to go before decent lines of communication are opened and some of that user frustration can be alleviated by providing serious users with the opportunity to really help improve the product, with bug reports that are taken seriously and software updates that do address those bugs. Blogs and that stuff are all very good, but until Microsoft puts in place a decent Mac-only bug reporting facility with some modicum of communication between users and developers, no significant change will take place. Users experiencing bugs on a daily basis will still be unable to provide really constructive feedback and the frustration will continue to build up.
And no thanks to the anonymous cowards (their own words, not mine) for not even having the guts to put a name on their lame attempts to put down users with legitimate concerns and frustrations. Last time I checked, the “situation” that Microsoft’s own employees are in was still very much Microsoft’s own doing. This means that the “situation” cannot be used as an excuse for inertia / lack of action and lack of progress. And last time I checked, my own frustration will still very much a product of my own “situation” as well. The difference is that I still have to make a living and I don’t have billions of dollars sitting in the bank or fattening the pockets of my executives.
If Microsoft really wanted to improve the situation, they could do it. You buy yourself a monopoly and then you sit on it? It’s YOUR situation, not anybody else’s. (The status quo only remains the status quo if you personally choose not to really try and do anything about it.)

If someone thinks ‘There’s a difference between “taking bug reports seriously” and “puttting up with snide and uninformed comments about people’s motives and the jobs they do”. I’m very happy when companies do the former, because the software industry needs customers who will provide feedback and won’t passively accept what comes down the pike. Honest criticism is never unacceptable.’ is a “lame attempt(s) to put down users with legitimate concerns and frustration”… once again, the skies are different colors on our respective planets.
“The difference is that I still have to make a living and I don’t have billions of dollars sitting in the bank or fattening the pockets of my executives.
If Microsoft really wanted to improve the situation, they could do it. ”
Man, Rick had you totally pegged in his blog, Pierre.
http://blogs.msdn.com/rick_schaut/archive/2006/06/22/643635.aspx
” Better yet, rather than explaining to these guys why I might be inclined to fix someone else’s problems before I get around to fixing theirs, I can spend that time actually fixing bugs.
Now, I’ll bet that at least one of these guys will offer a comment complaining about how we place profits over fixing bugs, thereby demonstrating that they really don’t get it.”

Warren,
I’m more amused than offended. You see the word “cost,” and you immediately translate that into _my_ costs. Why? I’ve never articulated the issue in those terms. Is there any reason I can’t measure “cost” in terms of maximizing user benefits across a user base that is not homogeneous?
Pierre,
Statements like, “If Microsoft really wanted to improve the situation, they could do it,” are a large part of why we aren’t communicating. How do you propose we improve the situation? Do you think money is the only resource limitation we face?

No, money is not the only limitation (although I am sure it would help, and maybe you should spend more time negotiating for more). Attitude is obviously a big problem too. But if you get off on maintaining the status quo, what can lowly me do about it…
Two years to having to live with an obvious bug because someone forgot to leave a Postit note on someone’s else desk? Give me a break.
Methinks Apple’s attitude (no blogs by developers, real bug fixing process that actually works) is looking better by the day. But of course you would never admit that Apple can actually do things better than you, and that they might be a model to emulate. That would probably be a bit too humiliating for your big egos.

Pierre,
I’ll admit, right here and now, that Apple might well have some processes worth emulating. As a matter of fact, we’re working on emulating some of their processes as I write this. My ego is not the problem, Pierre.
This is your tactic. You make outrageous statements about matters of which you have absolutely no knowledge. Someone calls you on the statements, and then you accuse them of arguing in favor of the “status quo.” When will you assume responsibility for your attitude and the extent to which your attitude leads to a breakdown in communication?
The two years that you’ve had to live with non-breaking space issue involves way more than a missing post-it note. During those two years, our French subsidiary has _not_ asked us to back-port the fix from Office 12 to Office 2004. There’s a French-Canadian sitting in the office next to mine. He hasn’t said that we need to fix this. We have a number of French-speaking testers, MVPs and members of our customer council. They haven’t said that we need to backport our fix for this issue. Why do you suppose that’s the case?

Post-it note?
Someone seriously thinks a software development team keeps track of bugs in a productivity suite with several fairly complex apps using post-it notes?
This would be LOL funny were it not for the fact that Pierre has got to know better than that, what with being an Apple beta tester and all; certainly he knows RADAR, so he must realize any software company doing serious work (outside of small-scale developers) uses something similar. So we’re left with either “does not really know anything about software development processes” or “being dishonest in rhetoric” (or, Chinese menu style, one from Column A, one from Column B).
That being said… yeah, transparency in bug reporting would be good (Nathan’s points about transparencty here are well-taken). I do also think detailing what gets fixed in each dot release ala Adobe products might not be a bad idea, either.
Anywhoo, let’s review this very blog for a counterexample to “Gee, Apple always fixes THEIR reported bugs and improves their software the way I like it, why can’t Microsoft?”
Here’s an example of an engineering decision. If you boot Mac RDC on a PowerBook and connect to a Windows server, try turning on Num Lock (the keyboard light should be on). Type something on the number pad in Excel. You get numbers, right? Good. Now, Cmd-tab back to the Finder and turn off num-lock. Cmd-Tab back to RDC. Type something on the number pad again. What, you still get numbers? Yes indeed you do. Geez, the MacBU really should have fixed that bug, right? We’d love to have fixed it, except that the bug is actually in the OS. The Carbon Event manager does not give you accurate information about the Num Lock state when you query for modifier key state after app activation and deactivation. I filed that bug with Apple in May 2002 against OS X 10.1.4, and they still haven’t fixed it. I wish they had, but I’m sure there is some reason (hardware? software complexity? who knows…) that the change is more expensive for them to make than to allow the bug to continue to exist. That decision is completely up to them, and I respect that.
While we’re at it, let’s read what this guy has to say about Pages, Apple’s word processing app:
Sadly, I have to report that, as a word processor, Pages 2 features almost no improvements of interest to me, and that most of the issues that I had with Pages 1 remain.
I think my work here is done.

eponymous coward: Obviously you didn’t get the fact that my “Post-it note” reference was meant in jest. Of course I didn’t mean to suggest that Microsoft don’t have an actual process for bug fixing, and was using Post-it notes instead.
I was simply referring to the fact that Schwieb himself has acknowledged that the reason why the bug with Postscript fonts and the non-breaking space still has not been fixed in Word 2004 was because a single individual at Microsoft left the organization:
===
The tester for that area of Word (who found and opened the bug) left MacBU to go back to graduate school during that summer, and I think we probably just missed this one in the transition.
===
My view is that a software company as large as Microsoft should have a bug fixing process that ensures that fixing bugs is not dependent on the presence of any single individual. There should be no room for such “simple human mistakes” in a professional organization, especially when these mistakes can have such a huge impact on the daily computing experience of thousands of users.
I also never meant to imply that Apple’s bug fixing process is perfect, far from it. If you read my blog carefully (do your work indeed), you’ll see that I frequently chide Apple for their failure to fix obvious bugs too. But at least Apple does have a proper facility for filing bug reports (Bug Reporter) and does respond to the bug reports sent through this facility—regardless of how “offended” they might be by the harsh words used by the person who files the bug reports.
And the overall track record of the two companies speaks for itself. No, Apple is not perfect, and Pages 2 is a disappointing update indeed. But overall Apple’s track record with bugs is still much better than Microsoft’s. And I suspect it has more than a little to do with the fact that they have a proper facility for submitting bug reports.

Having a public bug reporting system doesn’t make it any easier or harder for a bug to get lost accidentally. Any bug that I submit to Radar is locked down (from my perspective) as soon as it gets assigned to an Apple engineer, and i have no way to see its progress while it is still active. Even when it gets closed as fixed, I don’t have any way to see whether the fix is going into a Software Update (like 10.4.6) or into the next major OS release (like Leopard) unless I specifically pester the Apple developer to get that information.
One more point on that specific bug, and then I’m going to move on to other topics: we didn’t totally lose the bug — we did fix it for a future release of Office. What we did do is fail to note the significance of the bug to Office 2004 and thus we failed to bring it back to the current fix cycle. We do have a robust bug tracking mechanism in house, but it is only as good as the people running it. Yep, we made a mistake. I hope we can do better next time.
That said, I do think that having some form of public bug reporting system is a good idea. I’ve already had some hallway conversations with the right people in MacBU and they’ve been receptive to the idea. If we do it, there’s a lot of planning that has to happen to make sure that a) we don’t drown in bad or useless report and that b) we have a system in place to communicate bug results back to users in a professional and constructive manner.
This won’t happen overnight, and may never happen at all. But, people have made some good points on this blog and I appreciate them.

Thanks for your comments, Erik. I certainly don’t mean to imply that Apple’s bug reporting system and communication practices are perfect, far from it. I too have bugs that I submitted long ago and are still not fixed—although none as destructive/intrusive as the ones in Word that I am complaining about here. But getting an e-mail asking for more details, and then another e-mail saying, “We are aware of the issue, and are working on a solution” is much better than dead silence. At least it gives you some hope. It’s quite obvious to me that their public system is better than no system at all.
I am also fully aware that you said that the bug with Postscript fonts and the non-breaking space is fixed for the next version of Office. I just don’t think it’s reasonable to expect French-speaking Word users to endure the bug for several years in the current version. (And I certainly don’t think that claiming that “most French users don’t use non-breaking spaces,” like Rick just did, is helping in any way. It’s just utterly silly to say such a thing, in light of all the facts, including the fact that Word itself uses them when the user types in French.)
There are several things you could do to make sure you don’t drown in useless bug reports. You could, for example, ask people to register with a valid e-mail address and with their own Office serial number. I don’t have any problems with providing this type of registration information if it helps avoid “anonymous” submissions of no real value.

Leave a Reply to eponymous coward Cancel reply

Your email address will not be published. Required fields are marked *