The cost of a feature

Many engineers have a tendency to see their role in a team as being solely for the “how” — they take the “what” given to them from the business and design and implement a solution for it. They either view it as not being their place to question this or are just overly excited about the immediate opportunity of solving a complex problem and have never personally experienced the pain of maintaining troublesome features over a long period of time.

This cost of a feature list from John Cutler can help open your eyes to what you’re signing up for when you say “yes” to building a feature request:

1. Opportunity costs across all disciplines
2. Cost to implement feature (engineering, UX, product)
3. Cost to implement incremental improvements (engineering, UX, product)
4. Cost to deliver feature (processing, storage, monitoring)
5. Cost to train people internally to sell the feature
6. Cost to train people internally to support the feature
7. Cost to market the feature to existing customers
8. Cost to market the feature to new customers
9. Coordination costs across all teams
10. Cost to document and train users/customers on new feature
11. Cost to maintain that extra documentation
12. Cost to train engineers on more complex codebase
13. Cost of slower engineering, caused by increased system complexity and maintenance
14. Cost to hire more resources to account for slower engineering
15. Cost of reduced flexibility, caused by increased system complexity and maintenance
16. Cost of maintaining system usability as system broadens
17. … until the feature reaches end-of-life (unless you retire it)

As an engineer, many of these items may be outside of your control, but there are some questions you can ask before committing to a feature:

• What are all the edge cases and failure modes that we need to consider?
• How will we write automated tests for these?
• If this introduces a new service dependency or other significant architectural component, how does this affect deployability of the system to multiple environments? And system availability?

And even beyond these engineering concerns, product-minded software engineers will seek to understand the business needs and occasionally push back on these grounds also. In the past, I’ve been on teams where there was no cohesive product management capability and features were requested from the business seemingly on a whim. It was up to me as the architect/lead dev to (constructively) push back on these, irrespective of how easy/hard the implementation would be, as they often hadn’t been thought through. Hopefully you’re lucky enough to be working on a team with capable Product Owners. And if you’re a CTO or startup founder with full agency over feature decisions, the above lists will hopefully give you some pause before proceeding with a feature.

The “All code is a liability” mantra is well-worn in the serverless community, but the best way to avoid writing code is to cut off the need for it at source.