Ben Kamens

When working on FogBugz and Kiln, a common frustration cropped up whenever we realized that the self-installed, run-at-home versions of our software would need a lot of extra work to support the same exact features that we could get running on our On Demand version in just a day or two. Even making a performance improvement like using a special subdomain to deliver static content was complicated by the technology’s need to run on a fairly low common denominator: every OS/database configuration supported for at-home installations.

Of course, for Fog Creek this isn’t a terrible problem. Tons of customers installing FogBugz and Kiln inside their own networks = tons of money, and the time spent turning off the special static content subdomain option for installations inside restrictive firewalls is well worth such a large set of paying customers.

However, it took the team (and me) a while to learn not to shortchange our best offering, the On Demand version, due to the limitations of our lowest common technical denominator.

Graceful degradation is old hat in the browser world – if you’re not willing to use rounded corners because they’re not supported in IE6 you’re crazy. The exact same arguments apply any time you find yourself avoiding an important feature or fix because it won’t work on one of your supported configurations. Accepting the limitation as a fact without considering graceful degradation for some subset of your users is a mistake.

There was an internal debate recently over whether or not we could consider using Google Maps as a major part of Khan Academy’s exercise dashboard, because Google Maps won’t work for our offline users who run the software in remote, connection-less areas. By making the tough decision and denying offline users the knowledge map (they have a straightforward but simple list of exercises), we were able to focus on providing the best possible experience for our largest set of users.