The Easy Button Tax

1. The claim

Every convenience layer makes a trade with a specific shape: it converts a large number of small, predictable, design-time costs into a small number of large, unpredictable, incident-time costs. The trade is often correct. It is almost never priced, because the two sides of it are paid in different currencies by different people at different times.

The word “tax” is chosen carefully. A tax is not a scam. It is a known charge on a transaction, and the failure here is not that the charge exists but that it is undisclosed at the point of sale.

2. The three transfers

The third transfer is the one that compounds. Learning a constraint by hitting it during authoring produces knowledge that transfers to the next system. Learning it by reading a stack trace through four layers of framework at 03:00 produces knowledge about that framework’s internals, which is worth very little the moment the framework is replaced.

  cost
   ^
   |  ..... friction paid at design time
   |  .   .   .   .   .   .   .   .   .
   |  --------------------------------- calm
   |
   |                                  ##
   |                                  ##  incident
   |  ................................##
   +------------------------------------> time
      abstraction adopted           first
                                    real failure

3. Diagnosing an easy button

The useful question is not “is this abstraction good” but “what did it decide on my behalf, and can I see the decision”. Three tests, in increasing order of how much they tell you.

3.1. The naming test. Can you name the thing it hides? If the answer is a vague category (“it handles the networking”) rather than a specific mechanism (“it retries idempotent requests three times with deterministic backoff and no budget”), you do not know what you bought. See 5.6 for what that particular blank cheque costs.

3.2. The escape hatch test. Is there a documented way to drop below the abstraction for one call, and is that path exercised in the library’s own tests? An escape hatch that exists in the documentation and not in the test suite is a plan, not a mechanism. This is the single strongest predictor I have found of whether an abstraction will be survivable in year three.

3.3. The incident test. Read one public postmortem from a team that hit this abstraction’s failure mode. If none exists, either the abstraction is new or its failures are being resolved by vendor support tickets, which means the diagnostic knowledge is not in the commons and you will be rebuilding it yourself.

Figure 2. The bars rank how much each test tells you against how often it can be satisfied. Ranked, not measured.

4. The outcome this argues for

Not “avoid convenience”. The outcome is a disclosure practice, and it is small enough to adopt this week.

• Write the transfer down at adoption time. One line in the design document: what this removes, what it hides, and who pays when it fails. It takes ten minutes and it is the artefact the operator will want in three years.
• Require the escape hatch before adoption, not after. If dropping one call below the abstraction requires forking the library, the abstraction is not a layer, it is a ceiling.
• Exercise the hatch once, in CI. A single test that goes around the convenience path keeps it alive. Escape hatches rot silently otherwise.
• Treat the first incident as the invoice arriving. Record the price in the postmortem so the next team can compare it against the convenience it bought. See 5.11.

5. The strongest objection

6. What this paper does not claim

The tax is usually worth paying, and nothing here argues for shallow abstractions or for building it yourself. The authors of convenience layers are not the target either. In the cases that cost the most, the author was unusually careful, which is exactly why the abstraction was adopted widely enough to cost anything. The claim is about disclosure, and about who receives the bill.