I’ve been re-reading Getting real, which recommends:

“Each time you say yes to a feature, you’re adopting a child.”

It got me thinking about what’s involved in adding a feature to software, beyond initially coding it…

It’s not at all uncommon that features get added to software applications without really thinking through the consequences. I’ve seen this happen because a high-profile customer makes some noise about it, or because it seems like a cool idea … or sometimes just because developers have some time on their hands and have written the code.

This approach treats software features as something where the only effort involved is development – or perhaps development plus testing … which is not usually realistic. The true cost of a software feature needs a more long-term view: development plus testing plus design plus documentation plus internal training plus changes to marketing materials plus dealing with support calls plus bug fixing plus updates to all the above plus additional complexity across all areas next time you add a feature … and so on.

To switch analogies on you:

Like cute, fluffy puppies, software features are for life – not just for Christmas

A very cute puppy running

Doing the sums

The real cost of a software feature is going to vary wildly depending on the feature, the product, the team and so on … but I had a go at an estimate.

Example estimate of the total cost of adding a feature, over the lifetime of 3 versions

example cost of developing a feature

So, in this totally hypothetical (but based on software teams I’ve worked with), initial development is 27% of the total cost of the feature over 3 versions. And that’s without the inevitable feature redesign and its ensuing impact on testing, user documentation, internal training, marketing materials …

What do you think? Wildly over-estimated? Under-estimated? About right?

Maybe the numbers here are way off, but it does seem like it might be worth software companies having more of an idea of how the real cost of adding a new software feature adds up in the long term – and I very rarely come across anyone in software teams who does.

If you are looking for more advice on the topic of the cost of software features, Liz Keogh has written an article The real cost of change, which focuses on keeping the cost of change low when adding a software feature.

P.S. If you’re trying to keep your documentation up to date with an evolving product, you might be interested in this article by my colleague, George Lewis, about the continuous deployment of user documentation.

Originally published 27.01.12