Writing code feels productive. Verification — proving that code actually does what it should — is where the real difficulty lives. This asymmetry catches developers, teams, and entire organisations off guard.
Creation has a clear target; verification does not
When writing a function, you work toward a defined goal. Verification works in reverse: you must exhaustively consider every way the code could fail, including edge cases you never imagined when writing it. The problem space expands dramatically. A function with three boolean parameters has eight possible input combinations; real systems have millions.
The cognitive gap between author and auditor
The developer who wrote the code carries implicit assumptions about how it behaves. Those assumptions are invisible to the verifier — and often invisible to the author too. Code review studies consistently show that authors miss their own bugs at far higher rates than independent reviewers do. Familiarity is a liability during verification.
Testing covers behaviour, not correctness
Unit tests confirm that code behaves a certain way under chosen inputs. They do not prove the code is correct — only that it passed the tests you thought to write. Formal verification methods (model checking, theorem proving) can approach true correctness guarantees, but they require significant expertise and time investment that most commercial projects do not budget for.
Verification scales poorly
Adding a new feature takes roughly linear effort. Verifying the interaction between that feature and existing systems can grow combinatorially. Integration points, shared state, async behaviour, and third-party dependencies each multiply the verification surface. Automated pipelines help, but CI/CD catches only what your test suite already covers.
The economic pressure makes it worse
Shipping code is visible and rewarded. Thorough verification is invisible until something breaks. This creates systematic under-investment in verification practices — code review time gets cut, test coverage targets get lowered, and QA cycles get compressed. The cost appears later, usually in production.
Advertisement
What actually helps
- Independent review: Someone other than the author must verify the code.
- Property-based testing: Tools like QuickCheck or Hypothesis generate inputs you would not think to test manually.
- Static analysis: Linters and type checkers catch whole classes of errors before runtime.
- Mutation testing: Confirms your test suite would actually catch bugs, not just run without errors.
- Formal methods where stakes are high: Safety-critical and security-critical code warrants the overhead.
Verification is not a phase that follows development. Treated that way, it will always be under-resourced and incomplete. It is a discipline that has to be designed into the process from the start.