Using code coverage to decide what to deprecate

A recent post on building a slimmer jQuery got me thinking about the process of deciding what to cut.

From a code perspective, it’s easier to add new features than remove old ones.

From a user perspective, it’s much, much easier to add new features than remove old ones.

Nobody knows about your new feature, but there are at least three people who love that button you added to the toolbar two years ago. Even if no one else cares, they’ll make sure to post angry requests on your forums asking why you got rid of it. If you’re not careful, they’ll accuse your company of “not caring about its users,” or they might even say you “used to be great, but ever since they got successful they’ve started to go downhill”…ever hear that before? [1]

At the same time, it’s important to cut features, or you end up sliding down this curve:

So how do you decide what to cut?

Why Not Just Count?

One of the great things about analytics is getting real data about who’s using what. Every month, Google Analytics sends me an email that tells me exactly what people are reading on this blog. (Hint: It’s not the minesweeper articles)

That gave me an idea: Why not generate similar analytics for a library like jQuery?

There’s a nice list of sites using jQuery available here:

Let’s take a site and see what it’s actually using:

(Speaking of wanting to stick to old things, uses jQuery 1.2…)’s landing page is simple enough that we can do an actual list of what calls they make to jQuery, which I’ve uploaded here.

From this, we can tell that the standard selector function $() gets used a lot, as does readCookie and addClass. From there, the next step is to figure out what they’re actually calling.

In the case of jQuery, this is not too hard in principle. Get a version of jQuery, add a line that increments a counter every time a function is used, and inject it into your favorite website. It’s a little too involved for this post, but perhaps in the future (earlier if someone decides to jump in and do it!)



[1] Back in the 90s, Microsoft obsessed about making sure everything from the past worked, even if it mean keeping broken things from earlier versions of Windows:

The Windows testing team is huge and one of their most important responsibilities is guaranteeing that everyone can safely upgrade their operating system, no matter what applications they have installed, and those applications will continue to run, even if those applications do bad things or use undocumented functions or rely on buggy behavior that happens to be buggy in Windows n but is no longer buggy in Windows n+1. In fact if you poke around in the AppCompatibility section of your registry you’ll see a whole list of applications that Windows treats specially, emulating various old bugs and quirky behaviors so they’ll continue to work.

1 comment

Leave a Reply

Your email address will not be published. Required fields are marked *