The question that decides what to optimize next is simple: is this worth doing before everything else? Vlad Z’s DEV Community article on the topic argues that optimization work never runs out, so the real skill is ranking the next item. Its ranking uses two estimates for each candidate: how much the change saves, and how hard it is to fix.
Why the list never ends
Any system, codebase, cloud account or internal process can be made faster, cheaper or leaner. There is always another query to tune, another dependency to trim, another job to schedule differently. Because the supply of possible improvements is effectively unlimited, the practical problem is not finding work. It is choosing which piece of work comes first when time is limited.
As an Amazon Associate I earn from qualifying purchases.
The article’s framing moves attention away from completeness. Asking “have we optimized everything?” has no useful answer. Asking “is the next thing worth doing before everything else?” does.
The two questions
For each candidate change, the framework asks two things:
#1 Best Overall
- How much does this save? Estimate the benefit in whatever unit matters to your team: money, latency, engineer hours, error rate, or capacity.
- How hard is it to fix? Estimate the effort to implement and verify the change.
The author says no spreadsheet or formal model is required. A rough estimate on each axis is enough to sort a list into rough priority bands.
The four combinations
Placing each candidate on a two-by-two grid produces four categories. The author’s recommended handling for each is shown below.
| Category | Savings / effort | Author’s guidance |
|---|---|---|
| High savings, low effort | Meaningful impact, little work | Start here. |
| High savings, high effort | Large payoff, large cost | Possibly worthwhile, including architectural or replacement work. Plan and test it after the easier wins. |
| Low savings, low effort | Small payoff, cheap to do | Cleanup that can wait until the team has spare capacity. |
| Low savings, high effort | Small payoff, expensive to do | The article’s trap. Technical interest or elegance does not justify it. |
The low-savings, high-effort box deserves the most suspicion, because engineers are often most drawn to it. A rewrite that is intellectually satisfying but returns little is still a poor use of the next week.
Scoring a real backlog
The framework is easiest to apply as a short, repeatable pass over a list. The steps below are one way to run it; the example figures are hypothetical and are included only to show the method.
- List candidates in one place. Write each proposed change as a single line with a concrete target, such as “cache the product-catalog query” rather than “improve performance.”
- Pick one savings unit for the whole list. Mixing dollars with milliseconds makes comparison meaningless. If the costs are cloud bills, use monthly dollars; if the problem is user wait time, use seconds per request multiplied by request volume.
- Estimate savings roughly. Use a band such as high, medium or low, or a rough number with a stated basis. For example: “saves about 40 compute-hours a month, based on last month’s job logs.”
- Estimate effort roughly. Count the engineering days needed to build, test and roll out the change, including review and monitoring.
- Place each item in a quadrant. Use a threshold your team agrees on before scoring, so that items are not moved around to fit a preferred outcome.
- Work top-down. Start with high-savings, low-effort items, then reassess the high-savings, high-effort group, and treat the rest as optional.
- Re-score after each change. Finishing one item often changes the savings of others, so the ranking is a living list rather than a one-time decision.
Where the framework stops
The article deliberately keeps the model to two axes. Real decisions often need more, and the framework does not account for them on its own. Three factors commonly matter in practice:
- Risk. A change that saves a lot but could cause an outage may need extra testing or a staged rollout, which raises its effective effort.
- Dependencies. A cheap fix may be blocked by a team or system that must change first.
- Strategic value. Work that unlocks future features or reduces a long-term maintenance burden may justify more effort than its immediate savings suggest.
These belong in the discussion around the grid rather than in the grid itself. If a team adds them, it should say so explicitly, because the original two-question test does not include them.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What the author’s example does and does not show
The article’s only quantitative detail is an anecdote: the author has seen engineers spend three weeks on an optimization that saves $200 a month. This is a personal observation, not a measured study, and it does not establish how common such mismatches are. Its value is as an illustration of the low-savings, high-effort trap. Teams should test the same logic against their own figures rather than treat the example as a typical result.
The framework is also not a guarantee. Sorting work by savings and effort improves the odds of spending time well, but it cannot promise that any particular item will deliver the savings estimated.
Quick Recap
“
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
