More on Multi-Platform Support - Balancing Application Provider and Customer Needs

Many bloggers, including myself, had some fun on April Fool's Day coming up with the most preposterous stories imaginable. However, the preposterousness of some of the stories didn't make sense unless you knew the players involved. For example, you had to have hung around the AppsLab for a while to understand Rich Manalang's entry into the April Fool's fray, which was entitled "I’m switching back to IE6 and why you should too." Here's a sample of Manalang's argument:

So, today, I’m switching back to the browser who made the internet what it is today… Internet “f***ing” Explorer 6.0 SP1, baby!

But after Rich's statement, and some light-hearted comments, the conversation suddenly turned serious. G commented, in part:

[G]iven that the majority of web surfing is done with IE, isn't [IE 6's display failures] a failure of the designers. If the remit is 'publish this information to the world at large', excluding the majority of the target audience is a bit like having universal sufferage...except for women, blacks and poor people.

Yes, it was an outrageous statement, but it actually fit in to the tenor of the conversation (for example, I was advocating that the Oracle database itself revert to dBASE compatibility). In a later comment, G stated his/her concerns precisely. Here's just a part of his comment:

"So, you're arguing that we should cater to IE (specifically 6, but 7 too) simply b/c it just so happens to be the browser that most people use?" Yes, if you are interested in interacting with that audience. If you don't care about them, then feel free to alienate them. Don't expect them to change their browser to one you happen to prefer. A lot, in corporate environments, won't have a choice in the matter.

Eventually, Jake Kuramoto chose to post a serious follow-up that explored the IE6 issues in more detail, from his perspective. While Jake spent some time discussing issues specific to IE6, one sentence of his discussion was applicable to anyone who must choose which platform or platforms to support:

I have to balance investment in new features and bug fixing, just like any product manager.

Now I realize that browser wars can be nasty religious wars that get people really, really upset, so I'm going to choose an example that doesn't have to do with browsers. Let's talk about operating system choices. Even if you (for the moment) ignore any operating system fully or partially derived from Unix, and even if you (for the moment) ignore server-level operating systems, you are still faced with some nasty choices. Specifically, if your desktop application supports "Windows," what flavors of Windows will you be supporting toward the end of this year? Will you have launched your support of Windows 7? Will you continue to support Windows Vista? Do you have customers that continue to need support on Windows XP?

In Jake's post, and in one of my comments to Rich's post, two of the issues with supporting multiple platforms were discussed - development time and test time. But in reality, there are more than two time-suckers that get involved when you support multiple platforms. Here are all of them that I could think of:

• Planning time. Before anyone writes a line of code, you have to figure out what you want to do. This planning often takes place both at the marketing level (where I operate) and at a more technical level (systems engineering and/or design). How many of our existing and potential new customers require XP, Vista, and 7 support? If your application requires the use of the Windows Sidebar, what are you going to do for Windows XP users? These and other issues need to be addressed before you write a single line of code - and the more platforms you support, the more issues you have to resolve in the planning stage.


• Coding time. This is so obvious that even I get it. If you want your application to function in multiple platforms, then you need to take the time to fine-tune the application for each separate platform. Whether you're dealing with multiple browsers, multiple operating systems, or multiple internal tools (e.g. an application that works with Oracle Database and SQL Server and mySQL), the development resources and/or time increases based upon the platforms that require support.


• Testing time. Do you think that Jake and Rich throw their applications over the wall once coding is complete? Of course not. I don't know the specifics of the AppsLab, but in larger organizations you have have multiple groups performing testing on coded products. The group or groups that perform testing need to come up with a testing strategy, and even two variables in the supported platforms can lead to a variety of testing options. Let's say, for example, that you plan to support your application on 5 different operating systems, with an average of 3 web browsers per operating system, using an average of 3 database packages per operating system. That's roughly 45 possible testing configurations right there. Even if you choose not to test every single combination (and run the risk that the failure to test will bite you in the future), it's obvious that the more platform combinations that you test, more resources and/or time will be required for your test cycle.


• Implementation time. Some applications are ready to use right out of the box - most people don't need an integrator to set up Twitter for them - but other applications require some level of configuration before they can be passed to the customer. This necessitates the creation of installation instructions that cover all of the supported platforms, integrator training that covers all of the supported platforms, and various other tasks which are, as noted above, multiplied depending upon the number of platforms that are supported. And what do you do if your Red Hat expert is on vacation and a Windows expert has to configure a Linux implementation?


• Sales, marketing, and proposal time. Now that you have your application ready in 31 or 45 different flavors, you have to sell the thing. And you have to make sure that your proposal writers have the proper text and training to make sure that they don't mention a root login in a Windows XP proposal.

These are just some examples, and you could probably think of a ton of others, but the point remains that the more platforms you support, the more resources and time you potentially have to consume to get your application to your customers.

This, incidentally, is why there are some companies, even today, that only approve the use of Internet Explorer 6 for enterprise applications. The thing that causes a headache to application developers is actually a godsend to an in-house IT administrator, since it reduces his/her support time and allows the company to use proven tools. Well, it reduces time and hassle until the "proven tool" starts breaking with new applications.

And, like it or not, everyone has an in-house standard. Even Jake acknowledged as much:

For example, our internal IT deploys Firefox on new machines....

Now while employees at Jake's company (Oracle) may have the freedom to install other browsers on their Oracle-issued computers, the fact remains that they'll probably get more support if they call in with a Firefox issue than they'd get if they called in with an issue in Oracle PowerBrowser 1.5. (But hey, it's really fast!)

So any application developer has to balance the need for rapid response to customers (i.e. fewer platforms) with the need to support as many customers as possible (i.e. more platforms). It's a tough balancing act, and someone's bound to be upset in the end.