Software

Small tools, clear boundaries

A tool does not have to do very much. It does have to make its promises clear.

A small tool is easiest to trust when its input, output, and side effects are easy to describe. That description is often more valuable than a long feature list. It tells the next person where the tool belongs and where it does not.

Good boundaries make failure easier to understand. A conversion command should not silently replace its source. A report should distinguish missing information from a zero. A background process should have a visible owner and a predictable way to stop.

This is not an argument against automation. It is an argument for automation that leaves evidence. Record the version, keep the original when a transformation is risky, and make verification a separate step from execution.

The smallest useful interface is not always the shortest one. A little explicit structure can save a great deal of interpretation later.

Part of Field Notes, a journal about software, systems, and observations.