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.

Join daily email list

I publish short emails like this on building software with serverless on a daily-ish basis. They’re casual, easy to digest, and sometimes thought-provoking. If daily is too much, you can also join my less frequent newsletter to get updates on new longer-form articles.

    View Emails Archive

    🩺
    Architecture & Process Review

    Built a serverless app on AWS, but struggling with performance, maintainability, scalability or DevOps practices?

    I can help by reviewing your codebase, architecture and delivery processes to identify risk areas and their causes. I will then recommend solutions and help you with their implementation.

    Learn more >>

    🪲 Testing Audit

    Are bugs in production slowing you down and killing confidence in your product?

    Get a tailored plan of action for overhauling your AWS serverless app’s tests and empower your team to ship faster with confidence.

    Learn more >>