Originally published on decentphp.dev — part of the Writing decent PHP course. View this lesson on the original site.

"It depends" is often the right answer

In engineering, "it depends" is not a dodge.
It is usually the most honest answer when you are balancing readability, maintainability, performance, and delivery pressure.

What it depends on

When deciding how much detail or optimisation to add, check context first:

  • Change frequency: will this code change often, or is it mostly stable?
  • Execution cost: is this path genuinely hot, or called occasionally?
  • Failure impact: if this breaks, is it annoying or business-critical?
  • Team context: will most developers understand the trade-off next month?
  • Delivery pressure: are you under incident pressure or normal roadmap pace?

Common mistake: optimising the wrong thing

Teams often add complexity "for performance" before measuring anything.
That usually increases maintenance cost immediately while delivering little or no user impact.

A better sequence is:

  1. make the intent readable
  2. measure real bottlenecks
  3. optimise the proven hotspot
  4. document why the complexity is justified

Fast heuristics for decisions

  • Prefer the simplest readable version by default.
  • Add complexity only when you can point to evidence.
  • Optimise hot paths, not hypothetical paths.
  • If two approaches perform similarly, pick the easier one to maintain.
  • Revisit past choices when context changes.

Two valid decisions in different contexts

Context A: internal admin report, runs once daily

Readable and straightforward code is usually the right choice.
A tiny performance gain is rarely worth harder maintenance.

Context B: checkout pricing, called thousands of times per minute

Extra optimisation may be justified, but only after profiling and tests prove the need.
Even then, keep the optimisation local and explain it clearly.

Why this matters for decent PHP

Good engineers do not chase one rule forever.
They choose the right trade-off for the current context, and they leave enough clarity for the next person.

From Writing decent PHP — What decent PHP looks like