Skip to main content

Removing functionality from a stable API

Posted by kirillcool on June 1, 2007 at 8:51 PM PDT

For the past year, Substance has been a fairly popular and stable project, making the top ten lists in hits and accesses for most of the months (even given the presence of the such heavy hitters as JDK, Looking Glass and AppFuse). I get about 70 mails a month (most of them private, as people feel more comfortable without going through the hassle of public mailing lists and forums), and most of them are about bugs and problems. This is completely understandable - i almost never write a "thank you" mail when something works as advertised myself :)

And so, this steady stream of user feedback provides an interesting tool to measure the relative success of the features that i'm adding. Now, I have three main reasons to add a feature:

  • Explicit user request - about fifty percent
  • Interesting feature seen elsewhere (OS, browsers, other applications, other LAFs) - about forty five percent
  • Interesting feature that i thought about myself - about five percent (maybe even less)

As mentioned earlier, pretty much the only time that i have a feedback about some feature, it's either a bug or request for enhancement (which is, once again, totally acceptable). So, what happens when i don't hear anything (and i mean anything) about a feature. As far as i can tell, there are only two reasons:

  1. People want to use it, it works perfectly, with nothing to add and no bugs
  2. People don't need it

I'm way too old to believe in the first :) There are always bugs. In fact, as of today, the issue tracker has 221 reported issues, with many more reported privately via e-mail or found by myself and fixed without reporting them (i know, bad dog). And i do believe that if people want to use a feature and find a bug or a limitation, they'll at least shoot me an e-mail. So, this leaves the only option - people don't need the specific feature.

And so, the code lays around, gathering virtual dust, making the testing harder, complicating other code paths, requiring extra time to synchronize the documentation and adding to the total size of the runtime libraries. Which eventually has lead me to the decision of pruning the features that nobody commented upon since their inception (some more than a year ago).

Now, before you start accusing me of breaking the existing applications and alienating my users, i do have an explanation about the development process of Substance. Up until now, the release cycle was pretty tight, with releases every ten weeks. This doesn't leave too much time to polish and completely finish every new feature, so most new features mature during two or sometimes even three releases. During this time, i wait for the user feedback to see if the API is adequate, the feature itself is stable and, most important, the feature is used (if there is a bug report, it means that the feature is used or at least tested to see if it's useful). Some of the new features don't get that much attention if there is no feedback - i do tend to spend more time on user requests (since my time is limited).

So, there are some features that have been added experimentally (a request from a single user, a posting on a forum that has asked how to do something, or a stray thought during a boring movie). I know that they are not complete, and yet there hasn't been a single request for enhancement. I know that there are always bugs, and yet there hasn't been a single bug report. I feel that the time is right to start removing such features. Here is the list of first four features scheduled to be removed in the next major release of Substance (code-named Key Largo).

While some of these may sound an interesting problem to solve (all of them were such to me), i do have very good reasons to remove each one of them. If you use one of these and have a strong case against removing it, i'm open to talk (comments, project mailing lists, project forums or private e-mail).

Note that the usual release schedule has been relaxed from 10 weeks to about 20 weeks (due to the big change to the theming mechanism and the proposed removal of the features mentioned above), with the release scheduled late September. Hopefully this gives enough time for the discussion and will make the codebase a little cleaner and clearer.

Related Topics >>