I don’t know how many of you receive the SQLskills Insider email (sign up here), but if you know me, you know I’m a fan of SQLskills so of course I’m on the distribution list. Anyway, in Monday’s email Paul Randal talked about application vendors and how he frequently hears about incorrect configuration recommendations made by vendors that utilizes SQL Server as their RDBMS. One example that Paul gave is the recommendation to shrink the database on a regular basis. Since I work for a vendor, the topic hit close to home, and my immediate thought was, “Is there anything we’re recommending that is incorrect?” I don’t think so. And I say that because I have written a majority of our database documentation and have personally reviewed some of those recommendations with experts within the community. I do believe we do a good job of not only providing recommendations, but including explanations as to why we have certain recommendations.
However, I am not infallible and if I had recommended something that was not in line with a Microsoft best practice or other well-known recommendation, I would want to know. And this was Paul’s call to action in the email:
Next time you come across some guidance from a vendor that is clearly wrong or misleading, call them on it! Education is the key to getting things like this fixed.
I completely agree. If I am wrong, I want to know. And if I am wrong and spreading misinformation to thousands of customers, I absolutely must know about it. But I do have one request: be nice about it. I have no problem admitting when I’m wrong. I won’t be happy with myself, but I will admit it and will be appreciative, even if someone is very smug or condescending. But it doesn’t have to be that way. There is a civil way to point out when someone is wrong – this is true in life, not just vendor recommendations. As a DBA, you wouldn’t like me too much if I pointed out that your backups were going to the same set of disks as your database and then said, “What were you thinking?”
So when you do find an error, get your data, present your case, and view the discussion as a partnership. You’re trying to help the vendor, and hopefully they will recognize that and realize the value in you as a DBA and customer. I truly enjoy some of the relationships I have developed with customer DBAs on both a personal and professional level. And on a professional level, that relationship can benefit both parties. They have a direct line to me and can email questions, I have a direct line to them and can ask them to check something in their database, or try something in their environment if they’re willing. Is that relationship atypical? Yes. Is it possible? Absolutely.
Excellent post and I wish all vendors took that attitude. I hope my employer does.
Unfortunately, the DBAs (or others) might not ever get the customer feedback in some orgs. Releases might be to far between, and scope so tightly controlled that documentation fixes like these stagnate in bug system.
I’ve worked in places where the company was small enough that I could just be the change I wanted to see in the world. Worse case I would have to stay late and fix things after 5pm. I’ve worked in one place where I had to kick and scream to get permissions to fix my self reported bugs, but that was mostly because the person deciding what got fixed was non-technical so I had to make a “customer facing” argument for my changes. In that case we were an ASP, so customers would never do DB maintenance, so it was a slightly scenario.
My current company has elongated their already long development cycles. I’m in a customer facing role, and not a development role. I’ve files several bugs in the bug tracker, including several documentation bugs. There not going to get fixed because of resource issues. I’m not allowed to make the changes myself. This will be the status quo for at least 2 years while we rewrite our main product.
So my question Erin, is what do you do when you can’t fix your documentation, even when you know its wrong?
I don’t think that I’ve encountered an instance where I couldn’t fix the documentation if I knew it was wrong. I’m trying to think of a time when that would have occurred, or could occur, and I’m struggling. Do you have an example?
For me, not changing incorrect documentation is not an option…it has to be fixed.
Erin
The reasons cited are as followed:
1) The documentation changes have to be QAed (there is a lot of red tape to get a change out the door here so there is a legitimate cost to company resources that I can’t internalize by staying after work)
2) The product is being completely rewritten, and therefore its irrelevant.
3) Most of the time we install the product, not the client, thererfore the person reading the documentation usually has the tribal knowledge.
I agree with you 100% that not fixing the broken is not an option, especially when its documentation. However, I am powerless here because of my current job role.