I recently had a discussion with a developer friend of mine concerning building web applications to support Internet Explorer 6 that highlighted a recurring theme of technology people misunderstanding business and economic decision-making. In it I found myself trying to defend a deliberate decision in an application I develop not to support IE6. His take was that because so many internet users still use IE6, there's just no reason why we should not build our applications to support the browser.

Now there's no doubt that Internet Explorer 6 continues to have large penetration in the browser market. But this fact alone resulting in a categorical dismissal of the deliberately not supporting IE6 misses some key pieces of economic reasoning that must be considered.

Before outlining the reasoning, let's just accept the false assumption that browser usage numbers alone should dictate your decision regarding browser support. If this is the case, what's the breaking point? At what percentage use do you decide not to support - what's the magic number? Making decisions this way is rather naive - any choice here is mostly arbitrary and bears to relevance to the trade-off of costs and benefits or the other considerations I outline in the rest of this post. The core objective here is to balance the benefit of having more users access to your applications (or more correctly, the marginal revenue derived from the additional customers using only IE6, since it isn't safe to assume that browser and revenue-per-customer are uncorrelated) against the anticipated cost of making your application IE6-compatible. As such, the relevant decision should carefully consider this trade off. To help make this decision, there are considerations on both the cost and the benefit side:

Considerations on the Benefit Side

One thing that's commonly done is to cite browser numbers as of today as if that's the complete picture. As a case in point look at Google Chrome: numbers for this browser are quite low but many developers are rushing to provide support for it because of the future expectation of higher numbers. Basing your decision on current penetration numbers at a particular point in time would be like performing stock valuation with last fiscal years profit only. Many companies that aren't even profitable are worth magnitudes larger than established revenue-sustaining firms. Therefore, when considering browser penetration, we really should be thinking not only about today's numbers but also about anticipated numbers in the future, since presumably the application in development will last at least a year or two. Put simply, trends matter.Another important point to consider is your target audience.

It doesn't come as a surprise that browser choice does has some correlation with technical ability, so if your application targets hip, young internet users well-versed in other web 2.0 applications, you can bet that the percentage of that group using IE6 is significantly less than the percentage of older folks who barely check their e-mail and use an older machine.

Yet another important consideration, particularly if you are working on an internal project, is what degree of control you have over your users' web browser. For example, if you are working on an internal application used within your company, and the corporate standard is to use Firefox, then you aren't going ot have much of a problem with IE6. Even some applications, especially at first, are introduced to a smaller set of users with whom you may actually speak to in person and be able to influence the browser used with the application. This is the case in one of the applications I work on and hence we haven't found it worth it to support IE6 yet.

Considerations on the Cost Side

Implementing support for IE6 is not free. Every web developer on Earth has a profound hate for Internet Explorer 6 with all it's quirks, bugs, and non-compliance with established standards. Creating semantic HTML/CSS markup that works well in IE6 is hard enough, but writing working JavaScript is five times more difficult to create and twenty times more difficult to debug. Even when it's working, often times you'll have implemented hacks and other code smell that detracts from quality of the codebase. Doing all this of course costs money since ultimately you are paying developers to produce the code and debug it for IE6. In many cases this can be a significant additional expense.

Most importantly, the magnitude of this additional expense is extremely dependent on the specifics of the application. A basic brochure ware website with no JavaScript would cost significantly less to support than a rich, web 2.0 application with significant interactivity.

Although it's very difficult to quantify this cost (at least, more difficult than quantifying labor cost), there's also something to be said for reducing code quality and structure for the sake of supporting IE6. Extra DIVs, CSS hacks, less straightforward CSS due to lack of newer CSS selectors, and conditional statements in JavaScript all have a "cost" in a most abstract sense to the elegance of your codebase and may have additional maintenance costs in the future as you try to maintain a less clean codebase.

Another misunderstanding in general when thinking about costs and decision-making at the margin is that saving $1,000 in developer pay may not be the "real" economic cost here since keeping $1,000 cash may not be (and most certainly is not) your next best alternative, a concent economists call "opportunity cost", which is the real cost that you should consider when making decisions. Now in a more traditional setting your opportunity cost isn't much higher than your cash expenditure so substituting cash isn't a bad approach, but in a face-paced startup that's growing very quickly, often times your opportunity cost can be enormous as new features and development have tremendous value. Saving $1,000 in labor can be substantial if that $1,000 in capital could otherwise be used towards implementing new features that you value at much, much more than $1,000.

The point here is not whether or not it makes sense for my particular application to support IE6. Certainly it makes sense for many sites, usually content sites and those sites not targeted to a younger crowd, to support IE6 in full. My point here is that decisions like these should not be shallowly-reasoned or be subject to categorical dismissals. In decisions like this, it pays to approach a decision analytically like an economist would - think carefully about the costs and benefits. And choosing which browsers your application supports is pretty trivial compared to all the other kinds of decisions in developing software that would benefit greatly from an application of economic reasoning.