When good ideas look bad
Chris’s blog has been particularly good at making clear the process a product team will go through to try to ship a product that meets their users’ needs. Certainly on the product teams I worked on, we made decisions based on what would be best for our customers – or at least what we thought would be best for our customers. Sometimes we got it right, sometimes we were wrong and had to change direction, but it was always about the customers. I was often frustrated when the media would pick up on a bad decision that was made with the best of intents, and make it look like a deliberate choice to cause customer pain. Even more frustrating than that, however, is when we do this to ourselves without any help from the press at all ;)
Here’s an example that I stumbled onto last week when my wife forwarded me a mail from a professor. A product team made a good decision, but we managed to make it look like a bad one.
Here’s the story of the good decision they made (* gathered second hand, I wasn’t on the team involved): Since at least Office ’97, Microsoft has included in the Office Resource Kit a utility called the Converter Pack. It’s a bunch of file importers and exporters that allow Office apps to deal with file types beyond what we ship in the main Office package.
Because these converters are built to understand specific file formats, they never really need to change once they’ve been shipped. If you’ve got a piece of code that does a good job of importing files in WordPerfect 5.0 format, and that format is never ever going to change again, that code should be able to live in maintenance mode for quite some time. You could just keep shipping the same binary over and over again, unless there was some dramatic change in circumstances.
Well, between 1998 and 2002, there was indeed a pretty dramatic change in circumstances at Microsoft, in the form of the Trustworthy Computing initiative. A renewed focus on security-hardened products meant increasing the scrutiny of every line of code that Microsoft shipped, including even the little side projects like the Office Converter Pack.
But inspecting and updating the source to all of the converters turns out be trickier than one might think. In some instances, the key logic of the converter was something we licensed from a 3rd party, and all we ever got was a .DLL or .lib. In other cases, we had source-level licenses, but they didn’t include permissions to modify the code. And even if there was source code that we were able to change, it might well have last been built several years back, and to rebuild it now with a new version of the compiler, new shared libraries, etc, would mean introducing a lot of potential destabilization.
So you’re the Office team, you’ve got these converters with source that you can’t ensure is up to the quality required by the Trustworthy Computing initiative, and you’ve got customers who are clamoring for the next release of your product. What do you do? You take a good hard look at those converters, you analyze what your customers need, and you try to make the right decisions.
If a lot of customers are depending on a particular converter, you bite the bullet, re-write the thing, and code review and test to make sure it’s up to snuff. But you know you can’t re-write them all without slipping the schedule and irritating customers, so, on the other hand, if very few customers are using a converter, or there’s a good workaround, you decide to stop shipping it.
For example, if you’re looking at a hypothetical FooWriterPro exporter for Word that you licensed in 1996, but every version of FooWriterPro since 1998 has been able to import Word documents perfectly, you might well conclude that it’s better to drop the FooWriterPro exporter than deal with the stability and schedule risk of re-writing it to modern day standards.
Okay, that was a long set-up, but hopefully you’ll agree with me that faced with the choice of shipping a converter of unknown security standards, substantially re-writing a converter, or dropping a converter from the product, there are some circumstances when the right choice for customers is to drop the converter. In this particular case, the support team even went to the extra effort to keep the old converter around as an emergency backup – in the event that a customer called product support and absolutely, positively needed to use that converter, support could provide it to them (with appropriate warnings about the history and trustworthiness of the code.)
The last piece of the puzzle is that, as part of this security focus, we removed all of the older Converter Pack installs from ms.com. Instead, the Office 2003 Converter Pack, with it’s security-reviewed converters, was designed to install back onto older versions of Office as well, so that they too could have the new, strengthened converters.
To me, it sounds like a good decision.
But here’s how it looked to at least one of our customers using OfficeXP.
He discovered one of our KB articles, which said “The Office Converter Packs for Microsoft Office XP users, Microsoft Office 2000 users, and Microsoft Office 97 users have been retired and are no longer available for downloading.” First conclusion: damn, Microsoft is hosing older Office users, and forcing us to upgrade to Office 2003 if we want to use these converters.
Then he looked at a second KB which described what converters are available in the Office 2003 pack. The KB makes no mention of any older converters no longer being supported, but when he looked at the fine print of included converters, he noticed that an exporter he used is no longer there. Second conclusion: the sneaky bastards, they’re quietly removing exporters, so that I can only mail .DOC files to my co-workers.
Result: one unhappy customer.
He didn’t understand the trade-off the Office team made, because the KB articles didn’t explain it. He didn’t realize that the 2003 Converter Pack would work with Office XP, 2000 and ’97, because the KB articles didn’t explain that either. And he didn’t know that if it was a vital business need, our product support team would have been happy to send him the missing converter – again, because the KB articles didn’t explain it. In fact, we set ourselves up for failure, because the only way a customer will get the converter they need is to become angry enough to call product support and ask for it. So even if we provide it to them at that point, it’s only after they’ve gotten upset with us. All that pain could have been averted by adding just a few simple paragraphs to a KB article…
Postscript: as it turns out, the Office team has started hearing that, actually, there are some real needs for this particular converter, situations where there is no good workaround. And because the Office team tries to make the right decision based on user needs, they are out talking to customers now, re-evaluating whether they should do the work to revive this converter and bring it up to today’s standards for security and reliability.
Post-postcript: I’ve sent some mail to the Office and product support folks responsible for these KB articles, and they’re willing to discuss whether they should be revised to provide more detail.
