The hidden cost of software features

The goal of every software development project is to deliver features for an application.

At the beginning of every project, key stake-holders get together and decide which features should be built, and debate on what are the relative priorities of each feature. Features may be cut due to low priority or high cost of development.

During this process, issues that add to the "hidden" costs of features are often overlooked. Of course, these issues must be taken into consideration to assess the true cost of developing a feature:

1. Does the target user of the application care about this feature?

They may say they want the feature, but want is quite different from will use. In my experience, users always want as many features as possible but actually wind up using the most minimalist feature set that still allows them to accomplish their task.

2. Will this feature negatively affect the user experience?

Adding features to an application is not for free. Every extra UI widget adds clutter and reduces usability. (Skeptical? Which interface is more pleasant to use, Yahoo or Google?) Every option forces a decision that users do not want to make or even expend any intellectual energy on.

Often trade-offs in user experience have to be made to accommodate this feature. For example, the user may have really wanted a spell checker, but not enough to have to wait an extra 90 seconds on every "Save".

It's amazing how often new features added to an application break the clean user experience or quick response time that attracted users to this application in the first place.

3. How long will the feature need to be QA'd and UAT'd?

Just because something takes 1 hour to implement, it doesn't mean that it will take 1 hour to test.

4. Does this feature compromise our architecture?

Every new line of code adds potential complexity to your code base. It creates a new point of failure. There is no way to prevent this, but there are ways to mitigate it. Developers need to be cautious about adding unnecessary (or harmful) layers, classes, properties, methods, parameters, etc. They need to think about how this new thing they're adding will affect the stability of the architecture. For example, it would be really easy to expose the database ID of this object as a public property to solve the problem of finding the object again, but suppose you switched databases, or decided to go with XML as your backend, and now all of those modules that depend on that ID will be broken.

There will always be a way to implement the feature in an architecturally-sound way, but it the cost may be higher than originally thought.