Miller got back today from the last of her solo escapades for a while (at least until Burning Man). She had just finished spending a week with her family back home, and the week before that had been grading Spanish AP exams down in San Antonio. Right before she had left, she had just gotten her iBook back from the Apple store geniuses for more out-of-warranty-yet-free repairs to the hinge. Unfortunately, once at home, her iBook shut down and then subsequently would not boot. She called me at work and asked me to take care of it while she was gone, and then made her way to the airport.
A week ago, I decided to take a peek. The iBook would boot for a ways and then blink the "I can't find a blessed drive" icon. I pulled out the trusty Tiger disc and tried to boot from that, and it gave me an icon I had never seen before: a circle with a slash through it. After some Googling, it seemed that somehow the boot sector of the DVD couldn't be found, which seemed unlikely. I booted it up in target disk mode and connected it to my TiBook and there was no hard drive even listed. It did, however, show the Tiger DVD. I hadn't seen that before — previous versions of this error were easily rectified by selecting the drive in Disk Utility and selecting Repair, but with no disk listed...
I let Miller know I was going to have to take it in again. The geniuses tried the same stuff I did, and then said that it would need to go through a Repeat Repair. I was happy to find that it, too, would cost nothing. (It's nice that these repairs are free, but we've had to repair this iBook four separate times, and my TiBook has never needed anything!) They gave the perfunctory "make sure your data is backed up" speech, and asked whether I wanted to get in-house backup for something over $100. Here was my logic: If Miller had already taken this in before, and she got the same speech, and thus she's done everything she wanted with regards to data backup. I actually made the further assumption that she had, finally, taken my advice that she should back up the stuff she could not afford to lose. As it turns out, I was batting zero for two, but the final one was the kicker: My last assumption was, even if the hard drive was the culprit (rather than a controller or loose wiring or etc.), then they'd ship the damaged hard drive back with the machine so that I'd have a shot at recovery on the off chance that she hadn't backed up everything she wanted.
You don't get any broken parts back from Apple when they're replaced during a repair. I guess this makes sense, I just hadn't thought it through.
Fast forward to today, and I pick up her machine from the Genius bar, after having received the call that it had been received. They politely tell me what they did to it, and mention that they replaced the hard drive, as it had failed. I ask where the old hard drive is, and they respond, "Defective hard drives get scrapped or sent back to the manufacturer for warranty replacement, depending on the drive. It used to be policy that they'd retain them for seven days before doing so, in case someone wanted the drive, but that's no longer the case." Erp. I asked whether it was possible to retrieve it and their response was, "Probably not, since they would have already scrapped it or shipped it about the same time the iBook was shipped back here, but I can call AppleCare and check with the service manager to see what the deal is." I called Miller's parents' house and left a voice message about her machine having a brand, spanking new OS on it and that her hard drive was somewhere AWOL.
Miller called later, frantic, and said that this was a tragedy, and that yes, if I could try to get the drive back, that would be great. Apparently she had not backed up her drive... anywhere. No CD-R, not on her UW account, not in Yahoo, nowhere. I went through the AppleCare menu system with the feeling that I was asking the governor for a stay of execution. The tech investigated the case for me, said that the drive had already been scrapped and that they wouldn't really know how to look for it to get it back. But, he also said, that the reason it had been scrapped was that there wasn't anything they could do to revive the drive, so there wouldn't have been anything I could have done had I the drive. (Well, nothing shy of pulling out the plates and putting it another mechanism, which is admittedly, beyond my ken.)
We're still not quite sure of the information-lossage. Most of the, ahem, legitimate music can just be re-ripped. However, several years worth of academic papers, some amount of academic research, archives of e-mail correspondence, and most of her photo collection from Egypt are all resigned to the big bit bucket in the sky.
If there's anything to take away from this cautionary tale, it's back up your *#%^@ data.
Tuesday, June 27, 2006
Monday, June 26, 2006
My love affair with Type Libraries
It's just the registration that's annoying.
OLE Automation is one of those pieces of Mac Office which probably isn't understood by most people, even people here in the company. Strictly speaking, it's not really part of Office per se — the Windows version of Office doesn't include it, as it is a part of the OS1. But what the heck does it do?
Mainly, it allows a programmer to do is to define an application's object model and make that model available to be coded against or scripted. The central mechanism for this is what is called the Type Library. A type library contains a list of classes and their properties and methods, along with some annotations2. It is roughly analogous to an AppleScript dictionary, though there are some marked differences3. Most often, a type library is stored in a file, but it can be implemented in code as well, which allows for some extra dynamism4. A scripting client of OLE Automation can use it to read type information out of the type library to determine what can be called. If you go into Visual Basic for Applications, and choose View/Object Browser, the contents of that browser are just a visual representation of the type library (excluding items that are marked as hidden or restricted). Then VBA knows that if you're working with an object that is the Excel Application object, that only so many properties or methods are allowed, and it can autocomplete your code as you're typing. When you run your code, VBA will call into OLE Automation, and OLE Automation will point it at the code in Excel that needs to run.
The type library provides several ways to be a client of the code which the type library describes. At the base level, you can either call into a method directly through an interface pointer's vtable, or you can call into a method by referring to it by name. This latter functionality is defined by the
For years, the eldest Office applications, Word, Excel, and PowerPoint, all had two different object models. One was the OLE Automation / VBA model, which was shared with our Windows counterparts. One was the AppleScript model. They may have had overlap, but they were created largely in parallel, and they did not have any kind of feature parity. As a result, whereas sometimes the OLE Automation model would get new methods, the AppleScript model might not get the same methods, and the disparity would increase. Eventually, we had the idea that we could try and unify these things.
I made our first attempt at it, and it didn't succeed. The OLE Automation to AppleScript mapping proved to be sufficiently inadequate for a simple translation layer. There were enough oddities in the way the applications' type libraries were created (and subsequently had scripts writing assuming those oddities would remain), that the AppleScript experience would have been awful.
For Office 2004, Jim Murphy took a slightly different approach; start with the mapping, and then write some custom code to handle the rough edges. As of this writing, there are still some rough edges left, but ultimately, both VisualBasic and AppleScript now code to a (largely) unified object model, and more importantly to a (largely) unified implementation. Less code and more functionality. What could be better?
Under the covers, OLE Automation looks at the type library and performs calculations to figure out how to form a call to the actual function. Implementing
But back to my initial caveat. While type libraries allow you to advertise arbitrary object models, one of the main issues has always been, "How do you create an instance of one of these objects?" On both Mac and Windows, the answer has always lived in the registry. When you register a type library, you place registry entries that list what version the type library is, where to find it on disk, and where to find the application or framework (er, DLL) code that implements the objects and methods. Then later, when asked to create a new object of a particular kind (e.g., when you Insert/Object "Microsoft Excel Worksheet" from within Microsoft Word), OLE can look it up in the registry and launch it (if it's an app) or load the shared library, and call the appropriate object creation code.
Now you get into two sets of annoying problems. (1) The files move. On Windows, if you move files from where they were installed, you'd better make sure to re-register the type libraries, or things will (possibly transparently) break. On the Mac, it's a little more resilient (we have aliases after all), but you can still make it break. (2) You have more than one version or more than one copy of the same version. If you register a type library, you're registering just it and just the application or shared library you pick. There can be only one. If you have two or more, you'll get rerouted to the one that was registered last. This is another form of DLL-hell, and whereas DLLs can be distributed with their applications (removing the sharing aspect of shared libraries) to avoid DLL-hell, type libraries can't be fixed the same way.
Ultimately, the problem is no different than the one that LaunchServices (or previously, the Desktop DB) solves. It keeps tracks of applications it's seen, and when asked for "com.microsoft.excel", it can launch it, and it has disambiguating rules it uses to pick the most appropriate "com.microsoft.excel" if there's more than one. As an aside, there's currently no way to leverage LaunchServices by having it cache additional data about files, so it could also track what info is currently in the registry.
My acquaintance with OLE Automation began when MacBU acquired the privilege of maintaining the Mac version of the OLE code base. I've seen its transition to CodeWarrior, through Carbonization, and now we're working on Xcode/Universalization. My best, and frankly irreplaceable, reference for all of this, beyond having access to the code itself, has been Inside OLE, Second Edition, by Kraig Brockschmidt, ISBN 1-55615-843-2, sadly out of print. It goes into much, much more technical detail about all of this and the rest of OLE, and explains it all very clearly.
--
1 Windows users will know it by a different name,
2 These annotations include such things as alignment and indications of where to find help on this type or method. There's also a mechanism to add custom annotations.
3 Most OLE Automation types have analogues in the AppleScript world, but one of the hard ones is how to deal with methods that return an interface. There's no idea of returning a pointer in the AppleScript world — you have to return an object reference instead. Unfortunately, in some cases, a given interface won't necessarily have a way to turn itself into an object reference. If you arbitrarily created a "temporary" object store just so an object reference would get returned, the script writer would have to clean up after themselves, making sure to delete that object reference when done. While this is certainly possible, it's goes against the general AppleScript paradigm.
4 A type library could be generated on-the-fly at runtime. Usually, this wouldn't be necessary. But it would allow the type library system to be used to interact with a completely different scripting system whose contents wouldn't be known until runtime (or at least might change between the compile time and runtime). For example, it would be theoretically possible to write code that returned an
5 Another such arcane place involves the code that allows an interface to be hosted in a process other than where the implementation code exists. In these cases, we have to intercept the calls, send them via interprocess communication to OLE Automation running in the other process, and it will perform the call on our behalf. (The reverse process occurs when the result is returned.)
OLE Automation is one of those pieces of Mac Office which probably isn't understood by most people, even people here in the company. Strictly speaking, it's not really part of Office per se — the Windows version of Office doesn't include it, as it is a part of the OS1. But what the heck does it do?
Mainly, it allows a programmer to do is to define an application's object model and make that model available to be coded against or scripted. The central mechanism for this is what is called the Type Library. A type library contains a list of classes and their properties and methods, along with some annotations2. It is roughly analogous to an AppleScript dictionary, though there are some marked differences3. Most often, a type library is stored in a file, but it can be implemented in code as well, which allows for some extra dynamism4. A scripting client of OLE Automation can use it to read type information out of the type library to determine what can be called. If you go into Visual Basic for Applications, and choose View/Object Browser, the contents of that browser are just a visual representation of the type library (excluding items that are marked as hidden or restricted). Then VBA knows that if you're working with an object that is the Excel Application object, that only so many properties or methods are allowed, and it can autocomplete your code as you're typing. When you run your code, VBA will call into OLE Automation, and OLE Automation will point it at the code in Excel that needs to run.
The type library provides several ways to be a client of the code which the type library describes. At the base level, you can either call into a method directly through an interface pointer's vtable, or you can call into a method by referring to it by name. This latter functionality is defined by the
IDispatch interface, specifically the Invoke method. A class can be set up to allow one or the other or both, and in the last case, it's called a dual interface. If you want to use an interface from C/C++ and it supports vtable-calling, then the mktyplib utility, which generates the type libraries, can also emit .h files for including into client projects. Otherwise, you can call IDispatch::Invoke and have it figure out how to call that function. If you don't know what methods you will need when you're compiling your code or script, it's still possible to perform late-time binding, and ask the type library what's available at runtime. This is what VBA does, and why it can handle scripting arbitrary OLE Automation objects, so long as they can be acquired from one of the Office applications' object models, or the object model of VBA itself.For years, the eldest Office applications, Word, Excel, and PowerPoint, all had two different object models. One was the OLE Automation / VBA model, which was shared with our Windows counterparts. One was the AppleScript model. They may have had overlap, but they were created largely in parallel, and they did not have any kind of feature parity. As a result, whereas sometimes the OLE Automation model would get new methods, the AppleScript model might not get the same methods, and the disparity would increase. Eventually, we had the idea that we could try and unify these things.
I made our first attempt at it, and it didn't succeed. The OLE Automation to AppleScript mapping proved to be sufficiently inadequate for a simple translation layer. There were enough oddities in the way the applications' type libraries were created (and subsequently had scripts writing assuming those oddities would remain), that the AppleScript experience would have been awful.
For Office 2004, Jim Murphy took a slightly different approach; start with the mapping, and then write some custom code to handle the rough edges. As of this writing, there are still some rough edges left, but ultimately, both VisualBasic and AppleScript now code to a (largely) unified object model, and more importantly to a (largely) unified implementation. Less code and more functionality. What could be better?
Under the covers, OLE Automation looks at the type library and performs calculations to figure out how to form a call to the actual function. Implementing
IDispatch::Invoke involves knowing how, for this architecture, ABI, and calling convention, to put arguments on the stack or in registers, call the method, and then retrieve the results of the operation. It's one of the few places in the Office products where hand-written assembly is actually necessary5.But back to my initial caveat. While type libraries allow you to advertise arbitrary object models, one of the main issues has always been, "How do you create an instance of one of these objects?" On both Mac and Windows, the answer has always lived in the registry. When you register a type library, you place registry entries that list what version the type library is, where to find it on disk, and where to find the application or framework (er, DLL) code that implements the objects and methods. Then later, when asked to create a new object of a particular kind (e.g., when you Insert/Object "Microsoft Excel Worksheet" from within Microsoft Word), OLE can look it up in the registry and launch it (if it's an app) or load the shared library, and call the appropriate object creation code.
Now you get into two sets of annoying problems. (1) The files move. On Windows, if you move files from where they were installed, you'd better make sure to re-register the type libraries, or things will (possibly transparently) break. On the Mac, it's a little more resilient (we have aliases after all), but you can still make it break. (2) You have more than one version or more than one copy of the same version. If you register a type library, you're registering just it and just the application or shared library you pick. There can be only one. If you have two or more, you'll get rerouted to the one that was registered last. This is another form of DLL-hell, and whereas DLLs can be distributed with their applications (removing the sharing aspect of shared libraries) to avoid DLL-hell, type libraries can't be fixed the same way.
Ultimately, the problem is no different than the one that LaunchServices (or previously, the Desktop DB) solves. It keeps tracks of applications it's seen, and when asked for "com.microsoft.excel", it can launch it, and it has disambiguating rules it uses to pick the most appropriate "com.microsoft.excel" if there's more than one. As an aside, there's currently no way to leverage LaunchServices by having it cache additional data about files, so it could also track what info is currently in the registry.
My acquaintance with OLE Automation began when MacBU acquired the privilege of maintaining the Mac version of the OLE code base. I've seen its transition to CodeWarrior, through Carbonization, and now we're working on Xcode/Universalization. My best, and frankly irreplaceable, reference for all of this, beyond having access to the code itself, has been Inside OLE, Second Edition, by Kraig Brockschmidt, ISBN 1-55615-843-2, sadly out of print. It goes into much, much more technical detail about all of this and the rest of OLE, and explains it all very clearly.
--
1 Windows users will know it by a different name,
oleaut32.dll. 2 These annotations include such things as alignment and indications of where to find help on this type or method. There's also a mechanism to add custom annotations.
3 Most OLE Automation types have analogues in the AppleScript world, but one of the hard ones is how to deal with methods that return an interface. There's no idea of returning a pointer in the AppleScript world — you have to return an object reference instead. Unfortunately, in some cases, a given interface won't necessarily have a way to turn itself into an object reference. If you arbitrarily created a "temporary" object store just so an object reference would get returned, the script writer would have to clean up after themselves, making sure to delete that object reference when done. While this is certainly possible, it's goes against the general AppleScript paradigm.
4 A type library could be generated on-the-fly at runtime. Usually, this wouldn't be necessary. But it would allow the type library system to be used to interact with a completely different scripting system whose contents wouldn't be known until runtime (or at least might change between the compile time and runtime). For example, it would be theoretically possible to write code that returned an
ITypeLibrary interface which represented the contents of an AppleScript dictionary, and have that code be able to translate between OLE Automation types and AppleScript types so that you could use VBA to script a "normal" Macintosh scriptable application.5 Another such arcane place involves the code that allows an interface to be hosted in a process other than where the implementation code exists. In these cases, we have to intercept the calls, send them via interprocess communication to OLE Automation running in the other process, and it will perform the call on our behalf. (The reverse process occurs when the result is returned.)
Machine speculation
It was the beginning of this year when the new Intel MacBook Pro made it into the Apple Store for pre-ordering that the Pavlovian drooling commenced. My wife, Miller, in her prudent fashion, suggested I wait six months before upgrading my 500 MHz TiBook. Partially, it's because she wants to make sure I'm not just infatuated with the new technogadget-of-the-month. I, on the other hand, was sufficiently sure that I've already purchased Parallels, but her logic also made sense otherwise. Whereas a new product line may have certain problems endemic to it, six months is probably a good length of time to see if they crop up. Also, I am wondering whether WWDC '06 will hold some more product releases in store. If they announce better MacBooks, it will have been worth the wait. If they announce other hardware, like a more standard desktop, it won't be that great for me personally, though I suppose it might be possible that it would drive the prices down on the MacBooks. Unlikely, but possible.
In any case, I'm still crankin' away on my TiBook. I miss the (relative) speediness of the CodeWarrior builds, where even on this old boy I could crank out a set of Mac Office builds overnight. Now it takes longer than that to crank out one flavor of one architecture. I no longer really use it for mainline development work for that reason. All that said, and though I'll be happy to finally purchase an Intel-based Mac and see some dramatic speed improvements, I'll be sort of sad to put this old workhorse to rest. The keyboard keys have all gotten shiny with extended use. The Moby sticker to the left of my touch pad has long outlived its earlier counterpart on my old Duo 280, and I'll have to seek out an appropriate replacement.
Speaking of my Duo 280, is there anything I could do to replace a cracked screen at this point, or should I relegate it to the junk heap? I've still got an old Duo Dock in my office, though at this point, all it's doing is supporting my Intel iMac so the screen height is more ergonomically correct. One of my non-tech-geek friends made the point over the weekend that all these old machines are just adding to the already considerable clutter in our house. We got into a spirited debate over whether to keep random extra, usually defunct or obsolete, tech gear around. At some point I used the word "shrine" and the discussion fizzled. Anyhow, I think having a working Duo 280 is worth keeping, but probably not a irreparable one. I'm afraid to pull my SE/30 out of the closet and see whether it'll still go. I don't want to have to turn it into a fish tank just to have a reason to save it.
In any case, I'm still crankin' away on my TiBook. I miss the (relative) speediness of the CodeWarrior builds, where even on this old boy I could crank out a set of Mac Office builds overnight. Now it takes longer than that to crank out one flavor of one architecture. I no longer really use it for mainline development work for that reason. All that said, and though I'll be happy to finally purchase an Intel-based Mac and see some dramatic speed improvements, I'll be sort of sad to put this old workhorse to rest. The keyboard keys have all gotten shiny with extended use. The Moby sticker to the left of my touch pad has long outlived its earlier counterpart on my old Duo 280, and I'll have to seek out an appropriate replacement.
Speaking of my Duo 280, is there anything I could do to replace a cracked screen at this point, or should I relegate it to the junk heap? I've still got an old Duo Dock in my office, though at this point, all it's doing is supporting my Intel iMac so the screen height is more ergonomically correct. One of my non-tech-geek friends made the point over the weekend that all these old machines are just adding to the already considerable clutter in our house. We got into a spirited debate over whether to keep random extra, usually defunct or obsolete, tech gear around. At some point I used the word "shrine" and the discussion fizzled. Anyhow, I think having a working Duo 280 is worth keeping, but probably not a irreparable one. I'm afraid to pull my SE/30 out of the closet and see whether it'll still go. I don't want to have to turn it into a fish tank just to have a reason to save it.
Saturday, June 17, 2006
Long overdue photo
I think I might burn out my blogging muscles for another nine months if I type up another long post, so I'll settle for putting up a photo that will go into my profile.
Piercing the veil
Corporations are rarely transparent in their operations, and Microsoft is no exception. It has historically difficult to understand exactly Microsoft was doing to address specific customer desires or complaints. Previously, the ways you might have been able to talk to Microsoft were:
Part of the problem was that the Microsoft culture was one of employees being publicly silent. If you're an employee, and you post on a public forum, and you screw up (anything from revealing confidential information or trade secrets, to implying there might be a next release of something not officially announced (much less whether a particular issue would get addressed in that release), to negatively representing Microsoft), you may find yourself without a job the next day. There was little incentive to talk to the public, and when talking to the public anyway (say you get cornered on an airplane and reveal you work for Microsoft), you'd have to play defense lawyer, and say, "I can't comment on that."
My personal opinion is that this lack of transparency and interaction has hurt Microsoft's public image.
The advent of public bug reporting mechanism such as Apple's BugReporter or SourceForge's bug tracker didn't seem to perturb the way Microsoft did business; semi-standard industry practices aren't necessarily readily picked up. Instead, the advent of blogging has started to crack the official barrier between customer and employee, circumvent the aforementioned "official" routes. All of sudden, you could read a blog and get instant insight to what a product team was doing, even what technical hurdles were having to be addressed. Futhermore, with comments, you could give direct feedback to that blogger.
Consequently, employee bloggers are interacting with the rest of the world in a much more public fashion. Non-public-relations people are regularly writing commuiqués, and the PR and legal departments are nervously fidgiting, waiting for a major gaffe. On the whole, it seems promising; technology evangelists are getting people excited about products, and there's a new transparency into some of the workings at Microsoft. It's unclear how many neophyte bloggers have had to "seek employment outside of Microsoft", but my impression is that it is negligible.
The developer devision seems to be leading this new wave. The MSDN blogs were among the first I had heard of at the company. Furthermore, they're the first group trying to "close the loop" with services like LadyBug. I'm not sure if "close the loop" is some official customer-representative jargon, but I'm using it to mean to be able to receive customer comments, report back what, if anything, we're doing with them and why, and then, once action has been taken, to follow up with the customer to make sure that the action satisfies their desires.
Again, historically, we were far from being able to close the loop. If a user complained about an problem, even if we knew it was an "official problem", i.e., there was a bug report and it was deemed a valid problem, we weren't allowed tell the user that.2 Even if we could have told them it was a valid problem, we couldn't tell them much about when we would address it (assuming we knew) except under very limited circumstances.3 At best, we could have kept their contact information around and at the point where we finally addressed their problem and the software that did so was on the shelves, to report back to them. (I think, that happened in very isolated cases.) That still didn't really address the customers whose problems we elected not to solve.
While the new blogger-era rules of interaction are not fully written, it still seems like the new feedback tools and (the promise of) looser restrictions on customer communication will make it easier for customers to tell us what we need to know to do our jobs better and for us to let customers know that we "get it". (Or at least how much we've "gotten it", so they can take appropriate action.)
--
1 For example, we might add new wizards to aid people who don't know how to use a feature; this reduces support calls, but doesn't make the product better for those who already knew how to use those features. It may not even mean that the product is better when you account for all users of the product. If only 10% of customers are calling about a feature and the rest understand it, the only portion that's costing us money that we can measure are the 10%.
2 Notwithstanding our various Licensing Terms, previously known as EULAs, which warrant nothing about the software, the implication that there was a "bug" in the program could be (and in some cases, rightly so) construed as a "flaw" rather than "design limitation". Nobody wants to be sued, and software companies with deep pockets live in some non-zero fear of being the target of a landmark class-action consumer rights lawsuit akin to those in the automobile industry that might require fixing, recalling, and/or punitive damages.
3 If it was going to get fixed in a release not yet announced, that was a no-go. If it was going to get fixed in a release announced, but not on the verge of being shipped, there was a risk that the fix might get accidentally undone by some other work during the course of the project, and saying that it was going to be fixed meant having to make extra double sure that none of them were broken (not so hard), but also fix them if they were (which can be quite expensive if it's at the very end and we're trying to get the product out the door).
- Writing to MSWish - despite being monitored, user rarely got any feedback as to whether their bug was to be fixed or their feature suggestion taken into account other than the boilerplate text. [NOTE: MSWish is no longer operational at this time.]
- Talking to PSS - complaints or feature requests get filtered through this organization, and instead of producing qualitative suggestions to the teams, more often they'd be quantitative suggestions (e.g., this feature area got a lot of calls). Talking to PSS costs both the user and Microsoft money. Users are disinclined to call unless they can't solve their problem in some other way, so we miss feedback. Microsoft is financially incented to reduce PSS calls; better products is just one possible side-effect.1 All told, a user won't know that their commentary is going to get used or not.
- Talking to TAMs - Technical Account Managers handle the big accounts at Microsoft, and as such you're already a special class of user. You have more pull, but you're paying for the privilege, and the prospect of future purchases keeps our attention.
- Writing to Newsgroups/Forums - There's a fair amount of people willing to aid those who use our products who write to newsgroups, but quite a few of them are not Microsoft employees. Some of them are MVPs, who are well informed and intelligently summarize major problems back to the product teams. Some Microsoftees monitor the lists, either as part of community outreach, or ad hoc, but engage individual users rarely.
Part of the problem was that the Microsoft culture was one of employees being publicly silent. If you're an employee, and you post on a public forum, and you screw up (anything from revealing confidential information or trade secrets, to implying there might be a next release of something not officially announced (much less whether a particular issue would get addressed in that release), to negatively representing Microsoft), you may find yourself without a job the next day. There was little incentive to talk to the public, and when talking to the public anyway (say you get cornered on an airplane and reveal you work for Microsoft), you'd have to play defense lawyer, and say, "I can't comment on that."
My personal opinion is that this lack of transparency and interaction has hurt Microsoft's public image.
The advent of public bug reporting mechanism such as Apple's BugReporter or SourceForge's bug tracker didn't seem to perturb the way Microsoft did business; semi-standard industry practices aren't necessarily readily picked up. Instead, the advent of blogging has started to crack the official barrier between customer and employee, circumvent the aforementioned "official" routes. All of sudden, you could read a blog and get instant insight to what a product team was doing, even what technical hurdles were having to be addressed. Futhermore, with comments, you could give direct feedback to that blogger.
Consequently, employee bloggers are interacting with the rest of the world in a much more public fashion. Non-public-relations people are regularly writing commuiqués, and the PR and legal departments are nervously fidgiting, waiting for a major gaffe. On the whole, it seems promising; technology evangelists are getting people excited about products, and there's a new transparency into some of the workings at Microsoft. It's unclear how many neophyte bloggers have had to "seek employment outside of Microsoft", but my impression is that it is negligible.
The developer devision seems to be leading this new wave. The MSDN blogs were among the first I had heard of at the company. Furthermore, they're the first group trying to "close the loop" with services like LadyBug. I'm not sure if "close the loop" is some official customer-representative jargon, but I'm using it to mean to be able to receive customer comments, report back what, if anything, we're doing with them and why, and then, once action has been taken, to follow up with the customer to make sure that the action satisfies their desires.
Again, historically, we were far from being able to close the loop. If a user complained about an problem, even if we knew it was an "official problem", i.e., there was a bug report and it was deemed a valid problem, we weren't allowed tell the user that.2 Even if we could have told them it was a valid problem, we couldn't tell them much about when we would address it (assuming we knew) except under very limited circumstances.3 At best, we could have kept their contact information around and at the point where we finally addressed their problem and the software that did so was on the shelves, to report back to them. (I think, that happened in very isolated cases.) That still didn't really address the customers whose problems we elected not to solve.
While the new blogger-era rules of interaction are not fully written, it still seems like the new feedback tools and (the promise of) looser restrictions on customer communication will make it easier for customers to tell us what we need to know to do our jobs better and for us to let customers know that we "get it". (Or at least how much we've "gotten it", so they can take appropriate action.)
--
1 For example, we might add new wizards to aid people who don't know how to use a feature; this reduces support calls, but doesn't make the product better for those who already knew how to use those features. It may not even mean that the product is better when you account for all users of the product. If only 10% of customers are calling about a feature and the rest understand it, the only portion that's costing us money that we can measure are the 10%.
2 Notwithstanding our various Licensing Terms, previously known as EULAs, which warrant nothing about the software, the implication that there was a "bug" in the program could be (and in some cases, rightly so) construed as a "flaw" rather than "design limitation". Nobody wants to be sued, and software companies with deep pockets live in some non-zero fear of being the target of a landmark class-action consumer rights lawsuit akin to those in the automobile industry that might require fixing, recalling, and/or punitive damages.
3 If it was going to get fixed in a release not yet announced, that was a no-go. If it was going to get fixed in a release announced, but not on the verge of being shipped, there was a risk that the fix might get accidentally undone by some other work during the course of the project, and saying that it was going to be fixed meant having to make extra double sure that none of them were broken (not so hard), but also fix them if they were (which can be quite expensive if it's at the very end and we're trying to get the product out the door).
Eleven years
This coming Monday, I will have been working for Microsoft for eleven years, migrating from my initial position in Excel development into the newly-formed MacBU (or Macintosh Product Unit, as it was called in those days). I took some time this past week to look through what all I had really managed to accomplish over that time frame, partially wondering whether I was living up to my (self-gauged) potential. It's hard to recall all the little things I did for the various projects; the ship list seems to be the remaining milestones. Fortunately for my memory, those are permanently affixed to the Ship-It awards (I ran out of space on my first one), and I have the Shelf-of-Ship, a display of promotional boxes from the various products shipped (including the somewhat-hard-to-come-by Office 98J CD).
MacBU seems to have progressed a bunch over the years too. I missed the 68k to PPC transition that had happened with Office 4.2, but between picking up Windows components that Windows Office doesn't have to maintain for themselves (OLE, OLE Automation, Visual Basic for Applications), having to switch from our no-longer-supported Macintosh cross-compiler in MSDev to Metrowerks CodeWarrior, and undergoing a major OS revision (OS 9 to OS 10), we've come a long way. Now we get to look at CFM vs. Mach-O, moving to Xcode/gcc and adding Intel to the platforms (and largely the former two because of the latter). Roz has made a public commitment to work on it, and Erik Schweibert, my current lead, has already posted on some of those trials.
At the same time, whereas we don't have to play porting games with Windows Office, as their source diverges from ours, and as we need to maintain file format compatibility (to at least roundtrip the things our code doesn't support), we have a delicate balance to maintain in terms of what needs to get brought over from Windows Office and how it gets brought over: Do we port it and try and keep our code in sync with theirs? Do we clean it up as a v. n+1 version of the same feature? Do we rewrite it in a MacOffice paradigm? Do we do nothing and suffer the consequences? Each of these options has its negatives: Porting/synching code has the problem of many more developers working for Windows Office producing much more code than we have time to carefully review and integrate, and even if we do so, we have to live with the drawbacks of their particular implementation; on the good side, it means that if we have to do more porting of code added in a different release, it'll be easier to do since there will be fewer differences between our code and theirs. Cleaning it up suffers from the same problem of quantity, and whereas the finished product might be better and/or more elegant from a pure code-maintenance perspective, we complicate the future porting strategy — will we still be able to add the new feature they added to our "cleaner" version of the code, or will we have to throw out what we did and go back to straight porting later. (To be fair, it's not strictly a one-way operation; sometimes Windows Office ports code from us, and they face most of the same issues, if not the quantity issue. However, I doubt most of the pure code-cleaning gets back-ported unless it adds significant features; from most people's perspective, all it does is add risk to shipping on time.) Writing a MacOffice-version of the same feature has similar consequences, and when file format is involved, not supporting it is just not an option. Rick Schaut has been posting on the most current incarnation of file format compatibility since mid-2005.
For better or worse, MacBU hasn't been the only Macintosh software developer at Microsoft over these years. During its inception, a bunch of teams offloaded the Mac versions of their code, some with a big sigh of not-having-to-maintain/support-Mac relief. There were (and are) still exceptions... The Outlook team continued to produce a Macintosh Outlook client up to the 2001 edition. Encarta still produced their Mac applications (even though they usually had two developers all told for both platforms). The Windows Media Player team produced their, ahem, client for the Macintosh, though that has been recently supplanted with the Flip4Mac version. (This, by the way, caused a minor debacle, since their PR dept released the information on the same day Roz made the five year commitment.) The hardware group still produced their own Macintosh drivers, and the Services for Macintosh team on Windows Server worked on the Microsoft UAM, which, by the way, seems to have been replaced by an Apple-provided version of the same thing by 10.4.6 that even works on Intel. Included among the new exceptions are the WPF/E project, as well as the cross-platform shared source initiatives. In all of this, these groups are acting as peers, without a specific Macintosh oversight group. The tradeoff is that there's freedom for these teams to do what they need to do for their product, at the cost of a lack of Mac-product uniformity in quality, best practices, access to Apple information (MacBU has the closest link to Apple), and so forth.
As much as the new Intel boxes are creating new work for and my team, they still give me the excitement that something new is always happening in the Macintosh world. I look forward to writing more "interoperable" software, and hope to see another decade of closer Apple/Microsoft integration and partnership.
MacBU seems to have progressed a bunch over the years too. I missed the 68k to PPC transition that had happened with Office 4.2, but between picking up Windows components that Windows Office doesn't have to maintain for themselves (OLE, OLE Automation, Visual Basic for Applications), having to switch from our no-longer-supported Macintosh cross-compiler in MSDev to Metrowerks CodeWarrior, and undergoing a major OS revision (OS 9 to OS 10), we've come a long way. Now we get to look at CFM vs. Mach-O, moving to Xcode/gcc and adding Intel to the platforms (and largely the former two because of the latter). Roz has made a public commitment to work on it, and Erik Schweibert, my current lead, has already posted on some of those trials.
At the same time, whereas we don't have to play porting games with Windows Office, as their source diverges from ours, and as we need to maintain file format compatibility (to at least roundtrip the things our code doesn't support), we have a delicate balance to maintain in terms of what needs to get brought over from Windows Office and how it gets brought over: Do we port it and try and keep our code in sync with theirs? Do we clean it up as a v. n+1 version of the same feature? Do we rewrite it in a MacOffice paradigm? Do we do nothing and suffer the consequences? Each of these options has its negatives: Porting/synching code has the problem of many more developers working for Windows Office producing much more code than we have time to carefully review and integrate, and even if we do so, we have to live with the drawbacks of their particular implementation; on the good side, it means that if we have to do more porting of code added in a different release, it'll be easier to do since there will be fewer differences between our code and theirs. Cleaning it up suffers from the same problem of quantity, and whereas the finished product might be better and/or more elegant from a pure code-maintenance perspective, we complicate the future porting strategy — will we still be able to add the new feature they added to our "cleaner" version of the code, or will we have to throw out what we did and go back to straight porting later. (To be fair, it's not strictly a one-way operation; sometimes Windows Office ports code from us, and they face most of the same issues, if not the quantity issue. However, I doubt most of the pure code-cleaning gets back-ported unless it adds significant features; from most people's perspective, all it does is add risk to shipping on time.) Writing a MacOffice-version of the same feature has similar consequences, and when file format is involved, not supporting it is just not an option. Rick Schaut has been posting on the most current incarnation of file format compatibility since mid-2005.
For better or worse, MacBU hasn't been the only Macintosh software developer at Microsoft over these years. During its inception, a bunch of teams offloaded the Mac versions of their code, some with a big sigh of not-having-to-maintain/support-Mac relief. There were (and are) still exceptions... The Outlook team continued to produce a Macintosh Outlook client up to the 2001 edition. Encarta still produced their Mac applications (even though they usually had two developers all told for both platforms). The Windows Media Player team produced their, ahem, client for the Macintosh, though that has been recently supplanted with the Flip4Mac version. (This, by the way, caused a minor debacle, since their PR dept released the information on the same day Roz made the five year commitment.) The hardware group still produced their own Macintosh drivers, and the Services for Macintosh team on Windows Server worked on the Microsoft UAM, which, by the way, seems to have been replaced by an Apple-provided version of the same thing by 10.4.6 that even works on Intel. Included among the new exceptions are the WPF/E project, as well as the cross-platform shared source initiatives. In all of this, these groups are acting as peers, without a specific Macintosh oversight group. The tradeoff is that there's freedom for these teams to do what they need to do for their product, at the cost of a lack of Mac-product uniformity in quality, best practices, access to Apple information (MacBU has the closest link to Apple), and so forth.
As much as the new Intel boxes are creating new work for and my team, they still give me the excitement that something new is always happening in the Macintosh world. I look forward to writing more "interoperable" software, and hope to see another decade of closer Apple/Microsoft integration and partnership.
Saturday, October 01, 2005
A public face
This past week brought quite a few MVPs by our offices. Per usual, it was nice to be able to show a very little of what we're doing. On the other hand, it introduces another level of information dispersal and access protection to think about. On the one hand, acknowledging a problem with the software or talking about a planned feature could be considered to be an implicit promise to fix or implement something. On the other hand, not talking about what we're doing means that we miss out on valuable feedback.
So what would have been future design feedback is now feedback on existing design, which is, well, not always pleasant. It is sometimes difficult to participate on public newsgroups or mailing lists. One doesn't read much positive feedback (but then again would you really join a newsgroup to laud the developers who wrote the feature that made your day?), and there's as much negative feedback as one might want. Some of it is completely appropriate, and takes you back several months to the point where there was an agonizing choice... either the PMs at an adds/cuts meeting, or at some late point when a problem was finally realized where all the principals weigh the cost of addressing it and making sure that it was really fixed without other repercussions. I wince once when a hard decision happens, and then again when that first person says, "What were you thinking when you wrote that?" or "Don't you do any testing?"
It's just not useful, for me at least, to try and address all the posts. Some are unrelated to the software at all, and have to get redirected to a more appropriate area. Others are FAQs, asked on the order of three to four times a week, and points to people's lack of willingness to search the archives. Some, though, are the good problems: the ones we don't see in-house, the environments we don't have in a test lab or on a dogfooder's or beta tester's computer. These are the ones where one tenacious and helpful user makes it so we can fix the problem for untold others who won't report the issue. The other good ones are when there is an obscure error message that doesn't have an obvious solution but that we can help diagnose what's going on and solve some settings issue or help out with some workaround. Being able to respond to those makes me feel good about my work.
Then there are the total flame bombs that get dropped by irate customers, or better yet, irate non-customers. I personally do not know how to respond in a positive fashion to these, especially the ones that have horribly flawed or missing logic. I really don't understand the sense of entitlement evidenced by some posts. That a piece of software might not do everything you want should be par for the course, but does it mean that you're somehow entitled to have it "fixed" to do what you want it to do? Is it merely a problem of that the public listing of features not being specific enough to let you know what will and will not work? Comparing one piece of software to another might be useful to pick which piece of software is appropriate to use, but if it compares unfavorably, does it really mean that you're due some kind of replacement version that addresses those problems?
Ultimately, I will go into work and write the best software I can.
So what would have been future design feedback is now feedback on existing design, which is, well, not always pleasant. It is sometimes difficult to participate on public newsgroups or mailing lists. One doesn't read much positive feedback (but then again would you really join a newsgroup to laud the developers who wrote the feature that made your day?), and there's as much negative feedback as one might want. Some of it is completely appropriate, and takes you back several months to the point where there was an agonizing choice... either the PMs at an adds/cuts meeting, or at some late point when a problem was finally realized where all the principals weigh the cost of addressing it and making sure that it was really fixed without other repercussions. I wince once when a hard decision happens, and then again when that first person says, "What were you thinking when you wrote that?" or "Don't you do any testing?"
It's just not useful, for me at least, to try and address all the posts. Some are unrelated to the software at all, and have to get redirected to a more appropriate area. Others are FAQs, asked on the order of three to four times a week, and points to people's lack of willingness to search the archives. Some, though, are the good problems: the ones we don't see in-house, the environments we don't have in a test lab or on a dogfooder's or beta tester's computer. These are the ones where one tenacious and helpful user makes it so we can fix the problem for untold others who won't report the issue. The other good ones are when there is an obscure error message that doesn't have an obvious solution but that we can help diagnose what's going on and solve some settings issue or help out with some workaround. Being able to respond to those makes me feel good about my work.
Then there are the total flame bombs that get dropped by irate customers, or better yet, irate non-customers. I personally do not know how to respond in a positive fashion to these, especially the ones that have horribly flawed or missing logic. I really don't understand the sense of entitlement evidenced by some posts. That a piece of software might not do everything you want should be par for the course, but does it mean that you're somehow entitled to have it "fixed" to do what you want it to do? Is it merely a problem of that the public listing of features not being specific enough to let you know what will and will not work? Comparing one piece of software to another might be useful to pick which piece of software is appropriate to use, but if it compares unfavorably, does it really mean that you're due some kind of replacement version that addresses those problems?
Ultimately, I will go into work and write the best software I can.
Subscribe to:
Posts (Atom)