Most feature requests arrive from a user telling you how they think you should solve some other problem. If you can figure out the real problem and solve it better, that will be an improvement over delivering the exact request as given. (If you can't solve the real problem, though, or you misunderstand it, that's worse.)
For example at one company I was asked to speed up a report. The problem was that it was running too slowly and was timing out in the browser. Instead of tackling that fun optimization challenge, I built a feature that would cause any report that took more than a minute to run to be emailed to the current user. My manager said that he received more thank yous for that feature than for everything else the team had done in the previous 6 months.
At another company I received a request to add a feature that would prioritize pushing specific pieces of data to the website. (We'd had some stability problems, and they had no visibility into what was happening.) I knew that adding this prioritization feature would further destabilize the data transfer logic that I was trying to make more robust, talked to my manager, and refused the request. The senior executive requesting the feature tried to get another co-worker to do it instead, that one asked me innocently how to go about it, I got him to push back. Several months later I got enough of a break from other projects to consider the prioritization feature and asked the executive whether he still needed it. His response? "It has been months since data took more than 5 minutes to get to the website, I'm fine."
Also it can help to generalize your solution. At a third company I built a reporting system where instead of just plugging inputs, every form field could template the SQL that was being used. So a report could also generate drilldowns of itself, and you could combine these in a very flexible way. After a while over 2/3 of the special report requests that I got could be immediately resolved by showing that it was available if you combined two features that had been added for other users doing something else. (My turnaround time for other requests tended to be under 2 hours - and the features, documented, were available for anyone who needed them.)
Programmers do not provide value by writing code. We provide value by solving problems more quickly and cheaply than the alternative. The better you solve problems, the more value you provide.
That’s why it was left to wizards, who knew how to handle it safely. Not doing any magic at all was the chief task of wizards—not “not doing magic” because they couldn’t do magic, but not doing magic when they could do and didn’t. Any ignorant fool can fail to turn someone else into a frog. You have to be clever to refrain from doing it when you knew how easy it was. There were places in the world commemorating those times when wizards hadn’t been quite as clever as that, and on many of them the grass would never grow again.
Along those lines... I was once asked to essentially "speed up a report" but after asking a few questions discovered that the user of the report actually needed only about two values out of dozens of pages of detail and summarized totals on the report. Everything else on the report had been thrown on in the initial design as "someone might need that" requirements.
We created a new report that delivered what the user actually needed, and it ran in a fraction of the time. The speed difference was so great the users in fact doubted that the report could be correct, until they verified it against the old one.
And that's something that frequently ends up being overlooked in discussions like this. Software development isn't special because you need to state it in terms of goals. Yet you don't see people telling surgeons "you should avoid operating on people" or architects "you should avoid putting unnecessary stuff in and on your buildings".
What makes software development special is the perceived comparative ease of doing the work: you just sit down and code. There's no risk someone's blood will get septic just because you sat down to code. One of the consequences of this is that eager, novice coders will churn out code they could avoid, because it's cool.
Cautioning coders to avoid unnecessary coding is good, as long as you don't start forgetting that there's necessary coding, too and that writing that code does, indeed, add value.
There is a lot of effort expended to find non-surgical alternatives to many health conditions. Insurance companies in effect tell surgeons "you should avoid operating on people for this condition unless these other approaches have been tried first" in their reimbursement guidelines.
And the architect Mies van Der Rohe is famous for his precept that "less is more."
There is a lot of effort expended to find non-surgical alternatives to many health conditions. Insurance companies in effect tell surgeons "you should avoid operating on people for this condition unless these other approaches have been tried first" in their reimbursement guidelines.
As for insurance companies, they have some interesting perverse incentives going forward. Obama's health care plan says that they have to spend most of the money they bring in on medical care. This is intended to keep them from causing too much overhead. However the flip side is that the potential profit the company and top executives make is directly tied to how much medical care they get people to have, with the costs passed on to companies and consumers who are now legally required to buy insurance.
They will be very interested in making sure that the cost of medical care grows at a known rate. The growth being so that they can make more money. The known rate being so that they actually can make money. They will give public lip service to cost saving measures. But privately that isn't their incentive, and they are smart enough to know it.
Most feature requests arrive from a user telling you how they think you should solve some other problem. If you can figure out the real problem and solve it better, that will be an improvement over delivering the exact request as given. (If you can't solve the real problem, though, or you misunderstand it, that's worse.)
For example at one company I was asked to speed up a report. The problem was that it was running too slowly and was timing out in the browser. Instead of tackling that fun optimization challenge, I built a feature that would cause any report that took more than a minute to run to be emailed to the current user. My manager said that he received more thank yous for that feature than for everything else the team had done in the previous 6 months.
At another company I received a request to add a feature that would prioritize pushing specific pieces of data to the website. (We'd had some stability problems, and they had no visibility into what was happening.) I knew that adding this prioritization feature would further destabilize the data transfer logic that I was trying to make more robust, talked to my manager, and refused the request. The senior executive requesting the feature tried to get another co-worker to do it instead, that one asked me innocently how to go about it, I got him to push back. Several months later I got enough of a break from other projects to consider the prioritization feature and asked the executive whether he still needed it. His response? "It has been months since data took more than 5 minutes to get to the website, I'm fine."
Also it can help to generalize your solution. At a third company I built a reporting system where instead of just plugging inputs, every form field could template the SQL that was being used. So a report could also generate drilldowns of itself, and you could combine these in a very flexible way. After a while over 2/3 of the special report requests that I got could be immediately resolved by showing that it was available if you combined two features that had been added for other users doing something else. (My turnaround time for other requests tended to be under 2 hours - and the features, documented, were available for anyone who needed them.)
Programmers do not provide value by writing code. We provide value by solving problems more quickly and cheaply than the alternative. The better you solve problems, the more value you provide.