TL;DR: the true cost of a software feature includes a long tail of operational and maintenance cost that should be taken into consideration when first implementing the feature. The continuance or deprecation of features should be evaluated periodically, based on the actual usage and true value of the feature – compared to the cost of continuing it or killing it off.
What is the cost of having a child? This is a weird, perhaps impertinent of even unethical question. The comparison I want to make is that the cost of the initial conception or even the medical costs surrounding the birth of a baby and the first decoration of the baby room is but a fraction of the aggregated cost over the entire youth of any child (over $250K in the US). This includes schooling, food, clothes, housing and much more. By only looking at the initial costs, one would get a very wrong impression. Not having children is sometimes somewhat cynically but not altogether incorrectly referred to as “the Porsche option”.
When discussing new features in software, we too should be aware of the fact that the cost over the lifetime of a feature is much higher than we may believe at first.
Ask a software developer for the cost of new feature and she is likely to only consider the initial programming effort to just make the functionality work.
Consult a Scrum Master and she will probably include the effort to bring that working code to a professional level that adheres to software engineering standards – including testing, documentation, operability. This typically does not over the longer term costs of a feature, nor does it always include the costs for implementation of the feature in the business and end user community
A product owner should take a broader stance and include the long term into account. As time progresses, the feature causes additional costs: usage of infrastructure resources, additional effort in monitoring and other operational tasks. In subsequent releases, the feature needs to be regression tested. Maintenance effort is bound to be required to keep the feature working through all technical upgrades and as a result of changes to other features. Additionally, the requirements for the feature itself may change, leading to functional maintenance.
Having the feature increase the code base and increases the complexity of the application. This should be regarded as a cost as well – because simply put it makes life a little harder for everyone involved with the application – designers, tester, developers and anyone involved in operations.
Does this mean that these costs are unjustified and that no feature should ever be added? No, of course not. Many features offer such business value [over time] as to more than off set the costs [over time[ and have a positive business case. It is important when considering new features, however, to consider the business case in its entirety – looking not just at costs of the initial implementation of a feature but also at the longer term costs incurred by the feature.
This evaluation should not only be made once when the feature is first introduced. There should be a periodic reassessment of features. To continue with a feature is to take on additional costs. These additional costs should be justified by the value the feature can still deliver. Whether in happy end users, more sales, more efficient operations, lower risks – the feature must provide benefits in order to be continued. In order to be able to make this evaluation, you need metrics regarding the current usage of a feature (and the business value that usage results in). It is important therefore to embed in your software a mechanism for measuring who is when making use of features and recording this information to support fact based decisions.
Unlike with children that you take care of whatever it takes, features can be darlings to kill. If a feature is no longer justifiable – get rid of it! (note however that deprecating a feature in itself introduces costs – for changing the code base, changing and removing tests, changing documentation, changing operational procedures, informing end users)
