Skip to main content

Why do you want that feature?

37signals have got their heads screwed on the right way. Over on their Signal vs. Noise blog Jason has posted about why they have many 'features' missing. His response: "It just doesn't matter".

Their latest product is "easy group chat for business" called Campfire. It's a web-based IRC-type service which allows you to chat, share files and pictures. They have left a large number of so called 'features' out and many people have been asking why on their forum.

They take the view that if it's not essential for the service to operate correctly then you have to make the hard decision of whether to include it or not. Any feature no matter how small costs, whether in time, complexity of the resulting code or in the usability of the final product.

When you are designing software for someone other than yourself how do you take the same approach? If they are paying the wages then surely what they want wins? My thoughts at the moment revolve around splitting out the 'non-essential' requirements into separate stories and estimating those individually. Then you can explain the cost of that requirement to the customer to see if they still really want it now that there is a concrete cost associated.

Anyone else got any other ideas?

Technorati Tags: , , ,


Rob Baillie said…
We do exaclty the same thing here, even though the customers are internal. Whenever we look at a story we try to split the essential from the non-essential; The must have from the nice to have; then we cost the two (or more) components seperately.

The point is that the cost stays the same if it's 10 stories or 1. But splitting the work into smaller components allows the customer to be more flexible in their choices.
Anonymous said…
I'm a modularity fetishist, so I tend to work around this problem by designing my software to have an underlying structure that can encompass the core features as well as all the bizarre feature requests I have or can imagine. Then I write the code, pass it over for approval, and get started on those bizarre feature request modules. That way, the client gets to see them as separately costable items - and my lovely software architecture isn't muddied by them; when, six years down the line, they're still not being used by anybody, those modules can be quietly retired and leave nothing more than a stratum in the CVS/SVN fossil record...