Volume Number: 24 (2008)
Issue Number: 08
Column Tag: Industry

Major Releases, Benchmarks, and Feedback

Benchmarks and how the community contributes

By Neil Ticktin, Editor-in-Chief/Publisher

Software is a complex beast these days, and it has been for a while. Just take a look at the storage on your local machine, and you will likely see hundreds of thousands of files and folders, if not a million or more.

OS X, like other OSes, has many different configurations - more than is realistically possible for anyone to test on even for the biggest of companies. As a result, developers have gone into the mode of trying to write the best quality software that they can, do realistic testing, and then focus enormous efforts on listening for problems, and reacting to them. Both Microsoft and Apple are great examples of having done this on the Mac.

But with this approach comes a lot of responsibility on the community, especially those that are technical in the market. As a MacTech reader you are at the core of this market). Like it or not, this responsibility lands largely on your shoulders.

Leopard and Microsoft Office 2008 are both giving us good examples of what to look for, what to expect, and what our responsibilities are.

MacTech strives to give you quality benchmarks. We've done it for virtualization environments, Rosetta, hard drives, and Microsoft Office. In all of these cases, like anyone else that does high end testing, we do this in "virgin" or "clean" environments. It's the only way to do the testing, as you cannot penalize a product by putting it on a machine that needs to have a disk utility run on it, or has system problems, or a congested network.

Benchmarks are a great tool — they allow you to see, in an "apples to apples" comparison, how well a product performs. As the pros in the industry, you take those benchmarks and start to apply them to your real world setting, as only you know the setups you have. When major releases come out, the distance between a clean setup and yours may be that much more important, and here, your involvement grows.

Let's take Leopard and Microsoft Office 2008 as examples. Both of these are herculean efforts on behalf of their developers, and are massive releases. As anyone experienced will tell you, releases of this size are never perfect. There's no way for the developer to test all permutations of hardware, OS release and other software installed on the machine.

So, what's a geek to do? Well, that's a good question. When major new releases come out, you should get a copy in your hands as fast as possible, and start to use it yourself. What you should not to is put yourself in a situation where you are supporting others using it, and furthermore, you should not yourself be in a position where you are dependent on it working.

As you are able to experiment with these new versions, you want to understand what, if any, pitfalls you fall into. You should be looking for bugs, incompatibilities and more.

This is so much more important today than it was in the past. As the technical community, it's become our responsibility to report the problems so that they can be fixed. If we don't report them, they are not likely to be fixed. Griping about issues on public mailing lists and in blogs doesn't count. Even more important, the bug tracking and reporting tools have become sophisticated enough that they not only provide information on what you are experiencing, but give statistical information to help rank the importance of the problems within the community.

As many in the industry will tell you, Apple versions tend to stabilize on the .3 version. For example: Leopard will likely stabilize quite a bit on 10.5.3. It just takes that many interactions of versions and general usage to get the major kinks worked out. That's not to say that there won't be bugs with a .3 version; Historically, the .3 version is the one that generally runs well, and then has incremental improvements from there.

Every time you have an application that unexpectedly quits, a dialog appears asking for permission to send information to Apple. You should use this as much as you can, as it's not only fast, but it gives very specific machine generated information that is very helpful to Apple in understanding the situation that just happened.

In looking through Apple's online support, you'll see a way to give Apple feedback on whether an answer was helpful to you or not. Take the few seconds to let them know if it was helpful or not— over time, it makes a difference.

If you are looking for help on an issue, there are a couple of things that you can do. First, you can use MacTech's "Community Search Engine." Here, we've selected the best web sites in the community, including Apple's support sections, to be a part of the search. So, when you are looking for "rebuild degraded RAID," you'll get only those search results relevant to the Mac and OS X, and not the hundreds of thousands of answers you might see with a general Google search. See the left navigation bar on MacTech.com or http://www.mactech.com/advancedsearch.html — either way don't forget to press the "Mac Community" radio button for that type of search.

Apple uses their "Bug Reporter" system at http://bugreporter.apple.com/ as the primary way to report bugs to Apple. ADC Membership (free registration) is required to use this tool. And, there's a great article on AFP548.com that talks about the best ways to use Apple's system — see http://www.afp548.com/article.php?story=20051102133234150

Microsoft also uses a variety of ways to have people report in information. In fact, they appear to have broader methods of interacting than Apple does.

Microsoft has a "Send Feedback" command in the Help menu that redirects users to a page on the Mactopia web site. This information is generally used to plan future products for Microsoft.

See http://www.microsoft.com/mac/suggestions.mspx

Like Apple, the online Help sections on the Microsoft web site also asks, "Was this helpful?" Clicking the "No" or "Somewhat" buttons prompts for slightly more detail. When the community tells them why a topic isn't helpful, they can use that feedback to change the topic online, without having to wait for the next major release for offline content updates. Microsoft calls this "continuous publishing."

If you are looking for help on any of the Microsoft Office products, you should look to the newsgroup forums. Here, there are MVPs (not Microsoft employees) that know the products in depth, and will give you very candid answers. They are particularly good at answering "how to" questions. In addition, Microsoft read the posts looking for problem reports, and if appropriate will compare them to reported issues, or create a new one. Here are the URLs for the web interface into the newsgroup forums:

http://www.officeformac.com/ProductForums/Word/

http://www.officeformac.com/ProductForums/Excel/

http://www.officeformac.com/ProductForums/PowerPoint/

http://www.officeformac.com/ProductForums/Entourage/

http://www.officeformac.com/ProductForums/MacMessenger/

When you first install Office, it asks if you want to be part of the Customer Experience Improvement Program (aka CEIP) which gives Office permission to periodically send statistical data back to Microsoft about how the products are used. No personal information is collected. This is very helpful to Microsoft, if you are game. (The default is off, so you would need to turn it on.)

Finally, Microsoft uses Microsoft Error Reporting (MERP on the Mac, and Watson for Windows), which is for real time error reporting. Like Apple's reporter for Mac OS X, this is an excellent way to quickly send information that is machine generated about the problem that you are experiencing.

What all the larger organizations have in their error reporting is the ability to gather significance statistically from the error reports. For example, there are patterns to problems, and the bug reports are done in a way that Microsoft (and presumably Apple), can compare two bug reports and see if they are the same issue or not. Once that happens, they can determine whether an issue has widespread impact, or is localized to just a few users. In other words, it helps them to prioritize which things need to be fixed first.

Another example is that they can see that certain problems may be on specific OS versions, categories of machines, or even specific models of machines. This not only helps in understanding how to fix the bug, but is also may give insight that it's not a vendors bug.

For example, in the next maintenance release of Leopard, Apple is rumored to be fixing a large number of items. Microsoft may be looking at bug reports for an issue, and may very well find that the problem in question is not one with Office, but with the Operating System instead. Of course, the same thing could happen in the opposite direction where Apple receives bug reports, and finds that it's a third party.

Leopard's next update will likely be the one that fixes so much stuff that those that have been waiting, should now move forward. Naturally, Microsoft is working on updates for Office 2008 as well, presumably called SP1 (Service Pack 1, if they hold true to naming conventions). These will likely to fix many issues that widespread distribution saw, but MacTech may not have with the benchmarks on clean machines.

Why is this expected? Because both these companies have mechanisms in place to listen to customer experiences, problems, and bugs, research them down through statistical and other comparisons, and rank their priority accordingly.

But, all of that doesn't work unless we, the technical community, make sure to use the reporting mechanisms as much as possible.

Neil is the Editor-in-Chief and Publisher of MacTech Magazine. Neil has been in the Mac industry since 1985, has developed software, written documentation, been heading up the magazine since 1992. When Neil writes a review, he likes to put solutions into a real-life scenario and then write about that experience from the user point of view. That said, Neil has a reputation around the office for pushing software to its limits and crashing software/finding bugs. Drop him a line at publisher@mactech.com