Rainier LabField notes
Notes for software that lasts.
A few practical principles from building and maintaining small systems.
Define the boundaries
A small tool can be reliable when its responsibility is clear. Describe its input, output, and failure behavior before adding features. Distinguish data the tool owns from information it only reads, and avoid making a convenience feature responsible for unrelated operations.
The same principle helps documentation. Current instructions should describe the supported path. Experiments and abandoned approaches belong in dated records, where their context can be preserved without confusing a new reader.
Observe the result
A successful command is one piece of evidence. The next question is what changed for the person using the system. Check the visible result, read back saved state, and verify the path that matters in regular use.
When a check has limited coverage, say so. A local test, a remote service check, and a client import answer different questions. Keeping those distinctions explicit makes a report useful when something later fails.
Plan for recovery
A useful backup has a known owner, a protected location, and a tested way back. Keep the restoration procedure close to the deployment procedure, and preserve enough information to know which version is active.
After a failed change, first restore the supported behavior. Investigate from a stable baseline, then make the next change small enough that its consequences can be understood.