There are two curves drawn over the life of every server, and they do not agree.

Finance draws a straight line. The asset cost is divided across its depreciation schedule and written down a little each year until it hits zero. Clean, linear, predictable — and completely disconnected from whether the machine works.

Operations draws a bathtub. High failure risk early (infant mortality), a long flat valley of reliability, then a rising tail as parts wear out. Lumpy, probabilistic, and entirely about whether the machine works.

Most refresh arguments are really these two curves talking past each other. Finance says "it's fully depreciated, replace it." Ops says "it's running fine, why would we." Neither is wrong on its own terms. They're measuring different things with the same word: value.

Why the straight line is seductive

The depreciation line is attractive because it's certain. You know on day one exactly what the asset is "worth" every year of its life. You can budget around it. You can plan refresh capital years ahead. It makes the messy reality of hardware legible to a spreadsheet.

The cost of that certainty is that it's fiction about reliability. A fully-depreciated server is worth zero on the books and may be worth a great deal in practice — it's compute you own outright, with no further capital cost, often with years of healthy life left. Replacing it on schedule means spending real money to retire a working asset in order to start depreciating a new one.

Why the bathtub is right but hard to use

The failure curve is true. Hardware really does fail more at the start and end of its life than in the middle. But it's hard to act on because it's probabilistic. The curve tells you a population of drives will fail at a rising rate past year five. It does not tell you this drive will fail on this Tuesday. You can't budget a probability the way you can budget a line.

So ops tends to run gear until it actually fails, which is cheaper on average but occasionally very expensive on the day a critical box dies without warning.

Where the two curves should meet

The honest refresh decision lives at the intersection, and it requires both departments to give something up.

Finance has to accept that the depreciation schedule is an accounting artifact, not a retirement order. A written-down asset that still carries production load is a win, not a problem — it's capacity delivered at zero marginal capital cost. The schedule can keep doing its job (spreading cost, planning budgets) without dictating when the plug gets pulled.

Operations has to accept that "it still works" is not a strategy, because the bathtub tail is real and a surprise failure of the wrong box is expensive. Running gear past its reliable life without instrumentation is gambling. Running it with SMART data, ECC logs, and thermal trending is informed risk management.

The meeting point is a simple rule: the depreciation schedule plans the budget; the failure data makes the decision.

Making it operational

A few concrete practices turn this from philosophy into process:

  • Separate "book life" from "service life" explicitly. Track both. Book life is the depreciation window. Service life is the engineering estimate of reliable operation given the workload, environment, and wear data. They are different numbers and should never be conflated in a refresh conversation.
  • Give finance the failure data in money terms. "This box is three years past book but SMART is clean and parts are cheap — keeping it saves the refresh capital this year" is an argument finance understands. So is "this box is only two years old but it's logging rising ECC errors in a role we can't afford to lose — we're replacing it early." Translate the bathtub into dollars and risk.
  • **Budget a replacement reserve, not a replacement schedule.** Instead of "replace everything at year five," hold a pool of refresh capital and spend it where the failure data points. Some boxes get replaced at three, some at eight. The reserve smooths the budget; the data aims the spend.

The failure in the gap

The expensive mistakes almost always live in the gap between the two curves. Replace too early on the depreciation line and you burn capital retiring healthy gear. Run too long past the failure tail with no instrumentation and you take an outage you didn't see coming.

Bushido tracks the service-life side of this — lifecycle dates, failure outlook, and the wear context for a given model — precisely because the depreciation side is already well covered by every finance system on earth. The number that's usually missing from the refresh conversation isn't the book value. It's an honest read on how much reliable life the hardware actually has left. Bring both curves to the table, and the decision mostly makes itself.