Comparison
Defensive programmingvsHappy path thinking
Defensive programming
you added a null check for a case the caller promised could never happen, and it happened.
Writing code that survives inputs and states it believes to be impossible. It is right at trust boundaries, where the caller cannot be trusted, and it is expensive everywhere else: checks in the interior hide bugs, complicate reading and multiply the paths under test. The senior version of this argument is about where the boundary is, not about whether to check.
Full entry →Happy path thinking
the design covered what happens when it works and the review found nothing about what happens when the vendor is down.
Designing, estimating and demoing only the case where everything succeeds. It is the default mode of thought and it is where most of the missing work in an estimate hides, since error handling, retries, partial failure and reconciliation are usually the larger half. The reliable prompt in a review is to ask what happens when each external thing is slow, absent or wrong.
Full entry →