Creating features nobody wants

You hear all the time that your code (not just Microsoft's; everybody in a software development firm hears this) has features in it that "nobody wants".  But is this true?
Well, sometimes it is.

But sometimes there are solid business (not necessarily technical) reasons that a feature is included in your software. You might have legal reasons to include it. Your marketing team might assure you that they have tons of data to support people really do want the feature. But there's another interesting side-reason that you may have some features lying around that "no-one" seems to use. It's backward's compatibility.

At Microsoft we face this more often than some firms do. After all, even SQL Server has been around for a really long time. If we come up with a better way to do something, changing the current product feature set comes with a howl of protest. so we find where the pain points are, and trim off what we can.

But the longer the product is actively used in the market, the longer we have to keep those features. Take Data Transformation Services (DTS), for example. The new SQL Server Integrated Services represents an entirely new model for handling workflow-based tasks. But we had to include at least a subset of the DTS functionality since people had coded so many DTS packages that they became dependent on. Sure, we could have just extended DTS, but at some point you have to rip the bandage off and do the right thing. But that's a lot of pain for a lot of people, so you have to think about the older feature when you put in the new one. And it's hard to get it right.

If you're in software development, how do you think about customers and backward's compatibility, especially in your longer-lived software?

Skip to main content