There's this phenomenon that sometimes surfaces when you get smart people who are extremely loyal to a particular piece of software or process, and then the software or process is criticized for lacking a feature or failing to address a concern. I call it You Don't Need That.

This mentality is sometimes displayed surrounding feature requests in my favorite editor, GNU Emacs. I love Emacs, but it's pretty pathetic that it doesn't have soft returns (sometimes called "word wrap") and it's on version 21.x as of this writing. Heck, Windows' notepad.exe has word wrap. This lack of functionality, by itself, is bad enough, but worse is when a newbie asks about the the feature, and partisans try to convince the newbie that they don't want the feature in the first place.

I wish I could find an example of this happening to link or reproduce here, either with Emacs, or with any other software. I remember reading threads like this when I last searched for information about word wrap in Emacs about 4 years ago but I can't find a good link now. Let me know if you have a link to a good example and I'll post it here.

The hallmark of You Don't Need That is a reasonable request rebuffed with lots of rationalization about why the software needs to be the way it is, often with a nice helping of condescension towards the requester thrown in for good measure.

The right thing is, of course, to listen to the feature request with an open mind, and if it's actually a reasonable request, and there's no actually equivalent functionality and no real workaround that satisfies the user's constraints, then just say so. "Yeah, we didn't have time to do that," "Some early decisions we made to support X make Y hard, sorry," or "Huh, never thought of that, it sounds useful," are all way better to hear than, "You don't really need Y, because if you have Y, then you'll get lazy and then we won't run on teletype over an acoustic coupled modem and we'll sacrifice the orthogonality of our architecture."

There are, of course, legitimate times when somebody asks for something and they really actually do want something else but they don't know it. The difference is, in these cases, the "something else" should provide some advantage over the thing they asked for, either for the provider or receiver. Part of the job of a programmer is to figure out what the right way to expose a feature is via an API, and part of this skill is knowing how to get to the heart of the requests coming in and provide the features that satisfy the most requests with the least work while simultaneously not designing yourself into a corner...to hit the knee of the cost/benefit curve.

I'm guilty of saying You Don't Need That on occasion myself—it's just so easy to rationalize away criticism of things in which you've invested heavily, and a feature request can easily be seen as criticism if you're in the wrong mindset. But, I really strive to take feedback with an open mind, and actively listen and make things better. I'm not sure how successful I'm being; my friend and colleague Tony Gialdini, awesome animator and user of some of my decidedly wacky code, posted this on the wall above my desk...  :)