When deciding on a feature, what do you do?

Question

Do you primarily think of reasons TO implement it, or reasons NOT TO implement it? What are the advantages of each?

Answer 1

I think first about the stakeholder (the client).
Will that feature help him ? Is it indeed a functional feature that brings value?

Then I think about technical implications and the resulting complexity, in order to evaluate the trade off between implementation cost vs. not having that feature.

Based on those two first elements of reflexions, I can begin to know if I must implement it or not.

I guess there is no clear cut between reasons to or not not implement it.

Answer 2

I usually do a cost benefit analysis. How much is this going to cost to implement (in money or time) and how much is the benefit worth (again money or time).

If the benefits outweigh the costs by enough of a margin, it gets done.

The measure is usually money for paid work, time for personal stuff although there's sometimes a crossover. I won't sacrifice too much quality time with the kids no matter how much money's on the table.

Answer 3

The customer gets to decide on features. If I think of something I run it by the customer. Together we figure out how to get the customer's most important features implemented soonest.

Answer 4

I think that it is important to consider both pros and cons, with the end result being a cost benefit analysis.

The landscape of that analysis can shift a lot depending on the sort of product the new feature is proposed for. A lot of my work is on big complicated applications that have evolved over time and are core to the business of my customers.

Consequently a lot of analysis of a new feature focuses on why not to implement a feature; I will largely concentrate on risk:

• How well architected is the area where the new feature is to be introduced?
• What is the level of unit testing already implemented?
• Is the new feature being implemented right at the heart of the application?
• What happens if we miss something and a bug gets out into the wild, could it bring the system down (either literally or by effectively making the system unfit for its purpose)

At the end of the day, it is the customer's decision on whether or not a new feature is devloped. As professional software developers it is our responsibility to inform them of possible costs that may not be visible to them beyond the bare dollars and time.

The happy flip side is that we also have the responsibility to propose new features that they may not have thought even possible!

Answer 5

Fantasy decision-making question: Does feature improve product's ability to do what it is particularly suited to do? If yes, implement feature, else don't.

Reality decision-making question: Do we have enough money to justify implementing feature? No? Crap.

Answer 6

A lot of the time we're asked to put in a certain feature. Part of my job is being able to interpret this in the context of users who think they know what to include all the time. Sure, they know what they want, but you can bet someone else wants something slightly different. Its important in my world that we can think one step ahead and deliver more. We're paid to think how the business works and provide for them.

Thus, i come up with the strategy of adding something a bit more powerful, and then also delivering what the user wants as well. Thus, when someone else asks for something, its already there. This can save a lot on costly delivery cycles.

Unfortunately, this is not always available or practical, but if possible, i like to do it. I like to run with the motto that coding should be proactive rather than reactive.

Answer 7

It should be the client/customer/stakeholder/consumer that should drive what feature needs to be there. The client can be a real world user (single company or individual you are delivering) or not (a market you are making a product for). But either way, it has to come from an end-user.

We call all our new features "user stories".

What you certainly need to do is to understand why the user wants that feature - what is the problem that the user is trying to solve or advantage it wants to gain. You need to get the 'why' part from the user before you get to 'how'.

Answer 8

This fine Joel Spolsky post basically says:

1. Make a list of possible features.
2. Vote to filter out the worst features.
3. Assign a cost for each feature.
4. Allot a limited feature budget to each participant.
5. Find out which features are popular when allocating the budgets.

Answer 9

Implement a feature if it will help the user complete a certain quicker or complete it with more knowledge. If it will help the user, implement it, if it makes your app look better but doesn't really help the user around the application (just looks good) then don't implement it.