Ask HN: How should the cost of maintaining new software features be forecast? | Hacker News Reader

Ask HN: How should the cost of maintaining new software features be forecast?

12 pointscwkoss4 comments

I PM for a software engineering team. Estimating the cost of implementing a new feature is a fairly squishy process, but our team has gotten reasonably good about it. i.e. How many engineer weeks will it take to go from specification to released to customers?

However, I think it's an even-harder problem to try to estimate what the ongoing maintenance costs of supporting that new feature will be.

- There will inevitably be some amount of bugs and/or UX issues that need to be resolved soonish after release.

- Adding a new feature increases the cost of making future changes to the overall system (ex. changing a db object that is queried by 4 different endpoints will be harder than one that is only queried by 3 endpoints, also dependency management with microservices)

- Having more code doing more things means that engineer spin-up and switching costs increase.

We currently just budget a proportion of each quarter to address technical debt and unexpected bug reports, but are finding this proportion is getting increasingly taxed by the growing feature set, and it can be a bit hard to justify to the suits. Our a priori expectations of what the 'system complexity' costs of different features still feels quite coarse. There are some features that we maybe would have not prioritized as highly if we had been able to anticipate the downstream challenges that resulted from it.

Does anyone have good techniques that you use for comparatively forecasting how much the ongoing maintenance costs of a potential new feature will be? Our process currently feels too squishy and subjective, and I suspect someone here has found a better way. Or is this just an inherent challenge of software development planning that doesn't have an easy solution?

I dont know any concrete techniques. My applied rule of thumb is that 15-25% of total effort is/should be spent on maintenance and operations. Commonly called “keep the lights on” (ktlo) where Im at. Trending higher than that is a warning sign and probably unsustainable.

Additionally immediate “post launch” support/additions/refinement can easily be an additional 50% of the original effort needed to make the “launch” goal.

In both cases try and sort out the work that is directly associated with delivering the feature vs incidental/adhoc/subsequent improvements. You can use that course estimate for general budgeting. Finding commonalities across features/components will get you closer to your matrix or checklist to apriori plan the true cost per feature.

PS it occurred to me that “operational readiness reviews” might help you discover or evaluate some of these unplanned costs.

I take data from previous feature requests that were completed and number of bugs reported/refactoring etc. to create a rough cost estimate for maintenance in terms of man hours with the understanding that this is not perfect and there could be +-10% variation and this is only an estimate for planning. It worked well for me, other org's were not able to argue with me as i just showed them the data. Estimates were surprisingly accurate(its anecdotal) but i did not saw estimates overshooting/undershooting the +-10% variation. Later on this was adopted by the whole organization. I left but my guess is they are still using the same methodology

You’re already doing what is probably the overwhelmingly most common practice (that is among teams who even think about the topic):

> just budget a proportion of each quarter to address technical debt and unexpected bug reports, but are finding this proportion is getting increasingly taxed by the growing feature set

For any given feature, it’s a matter of judgment how to build it, but I suspect that most companies would way rather live with “we make reasonable calls as we go” with regards to maintaining software than to have any false precision around exactly how much this new thing will cost if built as A, built as B, or not built. The error bars are just too large I think.

Modeling increasing overall absolute maintenance costs as your codebase and tech footprint expand is fairly easy and gets you pretty close for the next 12 months.

I'm thinking maybe we should make a checklist/rubric listing the different potential complexity factors, and as we have engineers help with sizing we could have the engineer consider whether each of those factors applies/what the magnitude would be? Would this process yield valuable enough insight to justify the cost?

Reply on news.ycombinator.com