2026-05-20
Just like we don't let debt accumulate on loans or credit cards, we don't let tech debt accumulate in codebases. You may call this a 'zero defects methodology' following Joel Spolsky, or a 'zero techical debt policy' following TigerBeetle, but the result is the same—at any moment, fixing bugs is a higher priority than writing new code.
The motivations for this policy are manifold. The cost of identifying and fixing a bug, in both time and money, increase exponentially the longer the fix is delayed. Leaving bugs, sharp edges, inconsistencies, and other tech-debt debris in a codebase slow down ongoing development and adds cognitive overhead that would be better spent on design.
We heavily prefer tools and languages that allow us to prove the soundness and correctness of programs at the type level. By putting some more thought and effort into the foundation of a program, this allows us to develop and refactor far with more confidence than even a large test suite would permit in a weakly-typed language.
When dealing with unstructured or unpredictable input, we prefer to parse, not validate. We transform less-structured input into more-structured output. All non-trivial processing should occur inside of our walled garden, where thorough parsing and comprehensive typing are the cost of entry.
For the same reasons, we prefer small scopes to large scopes, prefer immutability to mutability, and prefer pure functions to impure functions - always subject to performance needs.
panic!ing in ProductionBy default, hard crashes—such as by panic!()—are not acceptable in production software. All software should be written with safety and proper error handling in mind, and should attempt to recover from or communicate errors to the user rather than terminating. Some exceptions to this policy can be made in the following situations:
Though rare, there are cases in which it is preferable to immediately terminate a program rather than proceed. This occurs most prominently in the case of malformed internal state or a fundamental memory error at the OS level. We prefer the use of programs which are strongly type-safe and memory-safe by construction, which prevents most of these kinds of errors, but they can still occur in exotic circumstances. In such
For performance-critical software, error-handling can sometimes introduce substantial performance penalties. In such cases, we should prototype and benchmark an error-safe version and an unsafe version to measure the deviation, and decide on which to retain by client decision.