The disappointment of people who need to have their hand held from beginning to end

Some customers already have the answer but need to have their hand held.

My customer wants to enforce a company-wide policy of disabling the "Keep the taskbar on top of other windows" feature. We have confirmed that there is no group policy setting for controlling this setting. Further research reveals the SHAppBarMessage function. The customer wants to know if there is any way he can write code that will use this function to modify the setting.

The customer found a map to a stream, saw that there were directions printed on it, and then asked, "Is there any way I can follow these directions and get some water?"

The product team dutifully wrote up the four-line function to do the work the customer requested—call SHAppBarMessage with ABM_GETSTATE to get the current state, turn off the ABM_ALWAYSONTOP flag, and then call it again with ABM_SETSTATE to apply the changes—but it still frustrates me that we had to deal with this question in the first place.

It's one thing to say, "I tried doing X and it didn't work. Here's the code I was using." It's another thing to say, "I discovered function X. Can you write code for me?"

Why would you expect a sysadmin (I think it is a fair assumption that the person involved was in that kind of role, given what s/he was trying to achieve) to know how to code? Just because you’ve been doing Windows development for umpteen years doesn’t mean everyone who uses Windows has.

I agree with “Still not a sheep farmer”. Raymond expects this guy, who probably hasn’t programmed anything more advanced than batch files or VBScripts to be able to write a Win32 application in C/C++.

That would mean he would have to:

1) Know that Visual Studio exists.

2) Get hold of it or download an express edition.

3) Learn the basics of C/C++ programming.

4) Learn the basics of Win32 programming.

5) Carefully examine the documentation of this function, remembering/researching all the unstated “rules” of Win32 programming, deciphering MSDN-speak, etc.

6) Write the program.

7) Test/debug the program.

8) Deploy the program.

9) Not give up and use his MS support contract during the process.

Assuming that just because somebody can find a function name on a Google search means that they know how to use it is a huge leap to make.

[True, but you’d think that somebody in the chain of communication between the person who has the problem and the product team would say, “Wait, this is a simple programming exercise. Let me get somebody who knows how to program.” It’s like calling Julia Child when you’re having trouble with your souffle. -Raymond]

Are you sure that it’s “I discovered function X. Can you write code for me?” and not something more along the lines of “I discovered function X, can you confirm for me that it’s acceptable to use it in this manner without suffering from various compatibility repercussions that we know exist, but only the people at Microsoft know the specifics of?”

While undoubtedly you’ve answered many questions for fools, I think it’s wrong to assume someone is foolish just because they ask something that seems like a no brainer.

Incidentally, regarding the ABM_* flags; ABM is the initals of Arturo Benedetti Michelageli, one of the greatest pianists of the 20th century.

[I concede that your interpretation would have made it a more legitimate question. Sadly it was not the case. Once I gave the customer the four-line function (with no discussion of guidance), they were happy. -Raymond]

Don’t forget the important issue here: Why in the world does the employer need to enforce the disabling of the "Keep the taskbar on top of other windows" feature in the first place? Let the users, that is, each employee, decide.

Does the employer also enforce whether the taskbar is one or two (or more) rows high? Its placement (bottom, top, left, right)? If an employee wanted the taskbar on the right side of the screen, would he or she get fired?

@David Walker: Sadly, there are still entire groups of people for whom what you describe would make them unable to work. They’d minimize a window and be wholly unable to get it back b/c the task bar is not visible, so open another instance of <X>, and so on, all day.

Likely the customer is question is working with a pool of such folks. From past experience I would not be surprised to find out that the CiQ is a government agency – under civil service rules, it’s almost impossible to get rid of incompetents and they tend to flock.

[I concede that your interpretation would have made it a more legitimate question. Sadly it was not the case. Once I gave the customer the four-line function (with no discussion of guidance), they were happy. -Raymond]

It may be possible that the customer considered this response to be an obvious statement from someone who had mistunderstood the (Admittedly imprecise) original question, and just dropped the topic.

My concern in general is that increasing tension infecting lines of communication is giving each side a view that the other sides are unbearably incompetant, and obviously nothing good can come of this!

The company probably has a single full screen application and they don’t want their employees to see or use the task bar. I’ve seen this before – the mentality comes from when they upgrade from dumb terminals.

Many casual users don’t realize that if you make the taskbar two rows high in XP, and if you don’t turn off "Show the Clock", you magically get the day of the week shown with the date and the time. I sometimes find it helpful to know whether it’s Wednesday or Thursday…

I sit next to support and they get this all the time. The customer either already has the solution but needs someone to make pleasant noises while they hack at it, or they expect to be spoonfed everything, even things that are not our product.

I sit next to support and they get this all the time. The customer either already has the solution but needs someone to make pleasant noises while they hack at it, or they expect to be spoonfed everything, even things that are not our product.

Raymond (and Microsoft) is quite rightly viewed as a font of useful information. And being truly helpful, as replying to these queries indicates, it’s a validated view.

I understand that it’s part of Raymond’s persona to be annoyed at being asked obvious questions. The real reason appears, contrary to the surface grumbling, directed at the intelligent followers rather than the ‘CiQ’.

In other words, when Raymond posts this, it is most effective as a "don’t let this be you" style of putdown rather than a swipe at the rudeness of the CiQ.

That said, this is a charitable view of Raymond (and Microsoft). Putdowns are still putdowns. Frustration and arrogance are also valid (and confirmed, and at times understandable) views.

This is the kind of problem where open source projects have an edge. They say "have you got an example" and we say "yes, it is in the file src/examples/ex1.c in subversion", or even better, "the junit test TestNetStats uses it".

So the incompetent are dismissed, and the compentent are pushed in the right direction to actually contribute. Of course, that’s because neither party are paying customers ; you dont want incompetents, but smart people, competent people, you want to recruit them to the team…

As far as Raymond griping about this, really it doesn’t matter. Actions are way more important than intentions; the important thing to remember here is that the product team dutifully helped the customer, and may have even gone an extra step in the process. Raymond apparently likes to post humorous rants on his blog for our entertainment — for which I’m grateful — and this minor incident made good material.

unfortunately I have very similar experiences with Microsoft Support. I call support with a problem. They spend two minutes telling me to write a small example that demontrates the problem. I spend a week boiling down the problem to a simple example. They take it and say: Thanks for doing the diagnostics for us. Since you boiled it down so nicely, it’s obviously a bug in our code. We file it under OfficeBug XYZ.

Work on my side: a week.

Cost on my side: a Microsoft Partnership license

Work on Microsoft’s side: wrote a few emails and a bug database entry.

Well, the function doesn’t really help to enforce the policy, does it? All it can do is to set the "always on top" setting, and if you want users to be unable to change it, you’ll have to make the program run all the time and periodically check the setting. Not too good.

@David Walker: Should we also ask MS to remove Group Policies, so that the domain administrator can’t restrict what users can and can’t do?

It makes perfectly good sense in some environments to enforce standard configurations, including things like taskbar position and size, or whether or not it autohides or is always on top. It depends on the users you’re dealing with in that location. For instance, where I work (I’m a developer, not the admin), the user is allowed to do anything with the configuration – in fact, every user runs as a Local Administrator on the machine, and every user has the same Windows login name with no password (although the network username is different and requires a password). I *wish* I could change that, because I spend a good portion of my time helping people who have screwed up their machines and the admin isn’t available to help them fix the problems.

Not every computer user is a computer expert; if you’re in the computer line of work, it would be a good idea for you to keep that in mind. :-)

"I call support with a problem. They spend two minutes telling me to write a small example that demontrates the problem. I spend a week boiling down the problem to a simple example."

If you don’t have a simple example to begin with, then you have no proof that the bug isn’t in your code. The only way you could possibly demonstrate a bug in this manner is to have supporting code that’s too simple to be erroneous.

"[True, but you’d think that somebody in the chain of communication between the person who has the problem and the product team would say, "Wait, this is a simple programming exercise. Let me get somebody who knows how to program." It’s like calling Julia Child when you’re having trouble with your souffle. -Raymond]"

If he’s got a big fat support contract from microsoft and can get someone there to do it for him, why should he look elsewhere? Especially he can get Julia Child to do his souffle :) **

I assume the support contracts either have limits on this kind of thing or charge money up the wazoo. Either way, it’s a support issue and you’re being paid for it.

says mike, who is in the exact same boat all the time and most days would be screaming too, but is temporarily in a good mood :)

**Offhand comment: I actually heard from a couple of people who knew her, that she was only a mediocre cook in real life. Enthusiastic, friendly, creative, but prone to disasters…..

To Triangle: Let’s give an example: When attaching an IAdviseSink via IDataObject::DAdvise to an Excel 2007 range with BIFF8 as format, all data changes should trigger an IAdviseSink::OnDataChange event. They do in Excel 2003 and earlier. But in Excel 2007, when changing the cell format (e. g., to format 1234 as 1234.00), such an event is not triggered. It is an Excel 2007 bug.

Do I need to write code to prove that? In my customer account at Microsoft, MS can easily see that I already reported a dozen other bugs that all turned out to be true. So is it really to much to ask for that Microsoft Support tries it out?

Arno

[Yes, you need to write code to prove that, because there might be a bug in the way you attached the IAdviseSink that happened to work by accident in Excel 2003 but which doesn’t work in Excel 2007. -Raymond]

KenW: Don’t be ridiculous; I never implied that all of Group Policy was useless. Many of the things in Group Policy that administrators can control, are important things. Many of them relate to the security of the overall network or domain.

The behavior of the taskbar on one person’s computer is not at the same level of importance.

@Raymond: I agree that someone needs to write code. But does it always have to be me?

I paid several thousand dollars per year for a Microsoft Partner license. I never use up any of my support requests included in this license, because every single support request so far resulted in a Microsoft Bug Database entry and was thus free. And this already happened a dozen times. Is the burden of proof still on me? Am I working for free, that is, actually paying for finding Microsoft’s bugs, the vast majority of which are still there after years?

No, open source doesn’t have examples for anything. But we can point people at the (public) unit tests. Because those are the only bits of the API that are likely to have any testing.

What OSS can do by pointing at the code is get rid of people asking useless questions. That said, pointing people at the code is often the wrong solution to people asking basic questions like "what does this do": the availability of source should not be taken as an excuse to avoid documentation.

@David Walker: You’re wrong. The behavior of the taskbar, on *some* people’s computers, can have the same level of importance.

I can tally the hours (yes, plural) I spend every month walking from my office to our Fiscal Unit, and fixing the position of the taskbar from one of the sides or the top of the monitor, because the woman at that desk somehow managed to drag it there (but doesn’t know how – "It just showed up there!") and can’t figure out how to either put it back or work with it there. So her day is stopped until either our Admin or I can get to her desk.

Multiply those hours by an hour of my salary and benefits, add in the hours of the Admin’s salary (worth more than mine, because he’s management and I’m not), and it adds up to a lot of money over the course of a year. It’s been going on ever since I started here over 4 years ago too, so it *really* adds up.

Can you see where the ability to administratively lock down the position and behavior of the taskbar might make sense? In our case, it would be important.

Your insisting that every single user should have the ability to configure their system is what’s ridiculous; you keep thinking that everyone is as knowledgeable about computers as you are, and one day it’ll bite you in the backside.

@David Walker: Subsequent investigation into Group Policy settings after the previous message led me to discover that, on a per-user basis, I *can* configure a policy that locks the taskbar (preventing the user from moving or resizing it). Yay! An educational day at Raymond’s blog yet again!

However, this setting allows me to autohide and set always on top. Why? Why are those less important than being able to move or resize?

See – things that you don’t think are important are still in Group Policies. Just because you think they’re silly doesn’t make them so.

If it is anything like *our* bug database then the initial report is followed by detailed analysis from someone who knows the ins and outs of the implementation. Publishing your bug database then starts to look like publishing your source code. Closed source projects might have a problem with that.

Consider, for example, an SMB bug, the analysis for which discusses the actual protocol being implemented. The Samba project have no interest in copying Microsoft’s *code*, but every interest in implementing the protocol. The bug report might actually be *worse* than publishing the code, since it highlights an area where you need to be particularly careful.

@Bryan: I don’t get your argument. I do make mistakes. And I do make sure that the mistakes I report to Microsoft are carefully researched. That’s why the bugs I report to Microsoft regularly turn out to be Microsoft’s bugs, not mine. There are not one or two, but about a dozen Microsoft bug database entries I helped create, and there is not a single issue that turned out to be our bug after I reported it as a Microsoft bug.

Why do we bother reporting them? Because these Microsoft bugs affect our software, and if we cannot find a work-around (which we try very hard), we at least need a good explanation for our customers why our software does not work. An admission by Microsoft that it is their bug, in form of a bug database entry number, at least deflects the blame.

But it is extra work to write a small code sample over merely giving a description of the steps required. I don’t see why I have to do this extra work if the bug is Microsoft’s. It comes down to what Raymond wrote above. If someone has a problem (or a bug), and you give them a clear description of what to do to solve it (or to reproduce it), I expect them to go and do it. Our customers can expect the same from us.

Providing good support is difficult, and a matter of company culture. We have 50,000+ users but still try to fix every single bug, providing a fixed version often within hours. Granted, our company is small, but I am convinced that our commitment to fixing bugs makes our support costs lower rather than higher, because the number of support cases is kept low. That is, the old mantra of "a company who wants to make money must not fix bugs" is wrong. In my experience, you make more money if you fix bugs.

So instead of trying to fend off bug reports, we embrace them. And the type of technical description I would give to Microsoft is already a dream of a bug report. If you make it too hard to provide bug reports, you won’t get them anymore, and your software is going to be worse for it.

As far as the 5% go, this would be solvable by statistics. I am willing to jump through hoops the first three times I call, but after having shown a dozen times that we don’t talk BS, it would be great to be seriously.

I am reminded of a episode of House here. Auditors were complaining to Cuddy (I think) about Dr. House’s unusual diagnosis methodology. The basic argument went like this:

Auditor: "The rules are there because 95% of the time, for 95% of people, it’s the right thing to do."

Cuddy: "What about the other 5%?"

Auditor: "They have to follow the same rules because everybody thinks they’re in that 5%."

I think the same thing applies here: you may very well be in that 5% of people who never report a bug to Microsoft that doesn’t turn out to be your own mistake. But you’ve got to follow the same rules as everybody else because the *other* 95% of people who often reports bugs that turn out to be their own mistakes will assume they’re also in the same 5% as you.

Unfortunately, I don’t think I could explain in a comment how unrealistic your perspective is. While your opinion is that your technical description is a dream, it might not actually be that helpful. Or perhaps the engineer already knew that. What if your providing a sample allows them to find 2 – 3 times the information you could provide via text in half the time?

Resolving bugs lowers support costs. Filing bugs increases support costs. You have to find the mix.

"As far as the 5% go, this would be solvable by statistics. I am willing to jump through hoops the first three times I call, but after having shown a dozen times that we don’t talk BS, it would be great to be seriously."

To me, the ultimate point is complexity. When a ‘people’ product becomes so complex that most ‘people’ cannot use/change/diagnose it, then they need to be told that fact up front. Microsoft has spent millions emphasizing how ‘easy’ it all is. Perhaps they should spend those millions emphasizing that it is easy to use – not easy to change. The public has little expectation of fixing their car, refrigerator, etc. Those manufacturers do not tell you constantly how easy it is to use. Reducing expectations (therefore frustration) will at least result in some additional respect for the tech. (Yes, we are the plumblers of the ‘net so watch the cracks!) I am constantly telling my customers – no this isn’t easy and that’s why I am going to charge you.

Next thing Microsoft will ask people like Arno to also fix the bugs they find.

Actually, I would love to do that. Finding a work-around is frequently harder than fixing the bug. In fact, although we prefer work-arounds, some bugs we actually fixed in binary. And I believe some of these fixes are probably fixed correctly, meaning that with our patch the code is now the way it was meant to be, and the equivalent source change could be incorporated into the source tree.

I think large corporations could benefit from working closer with 3rd party developers. Let them see the source code and submit patches. Review the patches, take the good ones and reject the bad ones. Instead of having them write samples let them write the actual fix.

Bug fixing aims to get the "best bang for the buck". The "bang", the benefit of a fix, is fairly easy to estimate. But estimating the "buck", the time it would take to fix, is often already quite an effort in itself, so it is never done. So I bet there are many low-hanging fruits lingering in these bug databases, which 3rd party developers would be happy to pluck if it solves their particular problem. It is just a matter of finding an interface that lets them do that.

"So I bet there are many low-hanging fruits lingering in these bug databases"

Unless their Developers are masochistic I seriously doubt it.

The other issue is that Bug Fixes can’t be sold on a product page very well. You have to be very careful how you approach it from a Marketing perspective (or at least that’s what seems to be the big concern).