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.

Comments (20)

  1. Shane King says:

    Why not just ship the code, with a warning it may be insecure, and they should only use it on documents from a trusted source? Lets face it, a converter from some obscure document format that most users have probably never heard of, let alone have the converter installed, isn’t really a very likely attack vector for a bad guy to choose.

  2. ed says:

    To the end user its all the same. Why should I trust Microsoft’s closed source converter instead of Foo Inc’s closed source converter? No really…

  3. Karen Mazner says:

    I think Jeremy’s analysis of this situation is brilliant and insightful.

  4. Marc Cohen says:

    Hi Jeremy, I’m the prof who started all this about converters. Your explanation about the code and security issues was very informative. And I think you are right that a few more informative sentences in the KB would have helped a lot. (I often have a lot of trouble with KB articles that are obscure even to reasonably smart people with a lot of experience as computer users but who are not techies.

    As for the WordPerfect converters, I can hardly believe that the MS view is that these are not really needed. A large percentage of the legal community still uses it. Last year I had some dealings with a lawyer in Chicago which involved sending documents back and forth with new edits. He sent me WP files, I worked on them in Word, and then routinely converted them back to WP to send to him. I suppose I could have left it up to him to read the Word files and convert them, but why should I have to have confidence in someone else’s software to do this?

    At any rate, I’m glad there’s someone at MS that takes these customer concerns seriously.


  5. Androidi says:

    Good "story", and there’s definetely a point to it:

    There is a lot of KB/MSDN documentation around that could benefit of having atleast a link to more indepth talk about why something is like it is or why some things should/shouldn’t be used in particular way(s).

    If it could be shortly explained it could be just included in the same page. A great feature, seen on php.net for example, is the ability for users/customers comment directly on documentation, in php.net, often the answer to particular problem is in the user comments, and if someone posts a bad example, there’s soon people pointing this out. If it works so well for others, why would it not work with MSDN (maybe even KB)? If (>x) people from different networks tag a particular comment as spam/bad, it could perhaps be auto-hidden. Self-managing comments? There’s a lot of algorithms to deal with spam etc, but looking at Outlook, it seems MS needs more people working on this department.

  6. Vijaya Kittu M says:

    I am into content design few years ago and this kinds of problem often come across in content when one web page gives an old info while a new one at a different location gives in the newer info.

    The best way is that the content team (or the KB team in this case) is to put a relevent searches / relevent pages that link to the pages that could probably give more newer info. This way, the reader can go through all the pages (old and new) and judge himself (without getting angry).

  7. Charles says:

    Wouldn’t have to make converters if the specs were made public for the ever changing DOC format…

  8. Brian says:

    Who are you trying to kid? Are you seriously trying to convince people that WordPerfect 6x converters aren’t needed, when there are 15,000,000 customers still using WordPerfect?

    Get real. How naïve do you think people are?

  9. Don says:

    I second Brian’s motion.

    Office 97 came out how many years ago? The WordPerfectWin file format has changed only slightly since 6.x. I happened to look at the WPWin SDK yesterday, which sets out the file format. Gobbledy-gook to me, since I’m not a programmer, but surely there’s enough programming talent at MSFT to take those specs and write the converter even if you can’t trust an outside source DLL.

    Isn’t everyone using Windows a customer of Microsoft? If you’re serving the "customers", why can’t/doesn’t the richest software company provide a conversion filter for another wordprocessing product used by those customers.

    MSFT has $51 billion in cash. What would writing those converters have cost (in development and maintenance time and presumedly lost Word sales) out of that cash? A million or two? My last machine came pre-loaded with Word; you have to go out of your way to avoid it.

    By not providing the converters, you pass on to your customers, who are said to be important to you, costs in excess of what MSFT would bear, with the back and forthing an earlier poster described.

  10. Jeremy says:

    we are listening to this feedback, and as I mentioned in the post, the Office team has already told me they are gathering customer feedback on whether they made the right decision.

    Don, I understand that from the outside it’s easy think that $51B buys a lot of converters 😉 But there are tradeoffs here, and not every engineering project can be made better by adding more people and money. A few of the considerations:

    Product bloat. There are some who complain that MS products are too big and filled with stuff that only a fraction of users care about. Every time we add a feature, we try to evaluate how broadly it will be used.

    Scheduling. Even if a feature makes sense, it has to fit in with the overall product schedule. You don’t want to be stuck holding up a Beta or RTM because one feature took two weeks longer to finish up.

    Testing. It might not take long to code up a converter, but the test burden is enormous. To hit the quality that users will expect, you’d have to test a huge variety of documents, each of which isolates a particular layout, formatting or language feature of the app, then export that file, open it in the other app, and visually compare the results. That’s a significant test burden which can’t be automated, and if you’ve got testers working on that, they can’t be spending their time elsewhere. Not only that, but the test matrix only increases as other new features are added to the project, so you end up with this exponential growth of test cases. As a general rule, any time someone responds to an engieering dilemna by saying "just add x more people to the team," it’s a sign you’re in trouble.

    Resources. That $51B is an asset that belongs to Microsoft shareholders, and management doesn’t hand it out without a solid business justification. You wouldn’t believe how hard it is to get an extra headcount added to a project here. It would take a very well thought out plan, showing the impact/tradeoffs on bloat, scheduling and testing, as well as customer demand, to get funding for a new project.

    So those are perhaps a few of the things the Office team has to take into consideration. Your feedback is part of the equation — I’d suggest sending feedback to Chris Pratley (http://blogs.msdn.com/chris_pratley) via his blog to let him know how much you value WordPerfect exporters.

  11. Brian says:

    Yeah, I can *clearly* see how creating WordPerfect converters isn’t in Microsoft’s shareholders’ interest.

    Product Bloat? Excuse me, but a user has to CHOOSE to install the WordPerfect converter. How is an optional converter Product Bloat?

  12. charles says:


    But keep this in mind: Your response on Product bloat… applies to many ISVs

    Scheduling… same

    Testing… same

    Resources… same (except for the $ amount available)

    The main difference I can see (having been on the inside and the ouside)… is choices: MS has the choice, Yes/No doesn’t really matter they dominate anyway…

    for the rest of the ISVs… choice is very limited: Yes, we have to do it as per MS or we die…

  13. Jeremy says:

    For some real background on how the Word team goes about doing feature design, from the guy who now leads that team, see http://blogs.msdn.com/chris_pratley/archive/2004/04/27/120944.aspx