There are a number of terms thrown around in the world of app compat that are vaguely defined at best. Now, I’m not one to suggest that tedium is a good practice in general, but in some cases understanding the true technical definition of a term can lead to significant time savings when that definition is applied to a project.
Compatible is the most important one. What does it mean to call an application Compatible with Windows 7? (Some people refer to this as Windows 7 Compliant also.) I have found some significant variation in peoples’ understanding of this, and the wrong understanding can lead to you chasing unachievable goals.
At the most abstract, that means that it works with the target operating system. So, today you may know it is compatible with Windows XP, and you are questioning if it is compatible with Windows 7 as well. But all you’ve done here is shift the ambiguity from the word “compatible” to the word “works”, and then you think about defining what “works” means – interpreted by some, this could mean that it doesn’t have any bugs on that platform. But think about that for a second – do you really want to wait until an application has no bugs on a platform? Because, if so, you’ll be waiting a really long time – all software has bugs. So that clearly doesn’t work.
Some peoples’ perception is that there are a series of criteria to follow, and once you follow those, it’s “compatible” (and, therefore, bug free). Things like the Application Compatibility Cookbook, with its enumerated list, bolster that perception. But compatibility is not as simple as filling out a checklist. There are all kinds of things that could go wrong along the way that won’t wind up on a checklist. I have debugged an app that ended up in a race condition because of the assumption that a particular shell function would be executed on the same thread, and it no longer was (you won’t find that in the cookbook). Heck, even Solitaire had a really bizarre bug which was based entirely on computer speed (we didn’t used to have a timer on the “card cascade” if you won the game – we rendered those little cards just as fast as we could, which these days is pretty insanely fast, some would even say instantaneous). Those don’t show up on the list – and in fact there are a near infinite number of ways that an app can end up having a problem on your new target hardware and software platform.
So, my small, manageable checklist is helpful but incomplete, an infinitely long checklist is clearly no better, and bug free isn’t my goal – what are the standards that I usually apply as a matter of practical execution? I normally layer things into 3 groups:
Compatible with Windows 7: The application has no bugs which stop you from getting your work done. It may have bugs, but they don’t affect your business. In the end, this is all that matters to you! Note, however, that this also means that the only person who can verify this is you! An app may let somebody else get their work done (and, thus, to them is compatible) but the critical functionality you need might be the bit with the bug in it. The only way to tell is to try getting your work done using the application. (Incidentally, this is one of the shortcomings of static analysis – it finds bugs everywhere, and not just in the bits of the code that you use – but we’ll talk more about that in another post.) You should only invest time and money fixing the bugs that stop you from getting your work done.
Supported with Windows 7: The application is supported by the vendor on your platform. That’s fantastic, because it means that if there are any bugs which stop you from getting work done, the vendor promises to fix them. But a promise to fix them is not the equivalent of being compatible (using the definition given above) for, since all software has bugs it’s completely possible that some of those bugs will be in a place that is a problem for you. Yes, you have a path for getting them fixed, but your business is still disrupted, and that costs you money! So, I tend to view support as a great indicator (since the vendor wants to minimize their risk of high support costs), but I don’t take it as fully equivalent to my Compatible with Windows 7 definition when doing my risk / benefit computations. But, for many apps, this is a requirement right beside my compatibility requirement, depending on business criticality.
Logo Certified for Windows 7: The application is not only supported, but the vendor has passed a set of tests that ensure a high level of quality for the application. When I see a logo, I tend to see a vendor who really stands behind the product. Logo certified apps tend to crash less frequently (since logo certification necessitates tests which detect and require you to fix many causes of application crashes), and have higher quality across the bar. It’s certainly not exclusively true (you can build an extremely high quality app, and just not want to bother getting the certificate required to sign up for the partner program – the only cost you have for Windows 7), but it’s a good indicator. But logo certification tests do not prove an application bug free, so again, it’s not the functional equivalent of verifying compatibility for you, but it’s another good indicator of whether or not to fast-track an application.