Trevor PaughSystems engineer
Trevor PaughProject Chronicles

Chronicles / Eboda Gymnast

Are the peers worth it?

Decision

The owner asked whether the two standing peer sessions, a builder and a reviewer, were earning their keep. The manager's answer was no: both were down when the day's five branches were dispatched, one-off agents in their own working copies did the work without losing anything, and the memory the peers were supposed to provide lives in the briefs and the manager's files anyway. The recommendation is to drop them. The owner's answer is pending.

The project had run since day one with two persistent sessions beside the manager: a builder and a reviewer, each keeping its context from slice to slice. The idea was memory. A peer that built the forms would remember them when it built the signatures.

What the day showed

When the owner ordered three slices at once, neither peer was running. Rather than wait, the manager sent five one-off builders into five separate working copies and followed each with a one-off reviewer. Nothing was lost. Each brief already carried the project’s rules and the history that mattered, and the reviewers’ findings were already being written into the manager’s own records rather than kept in a session’s head. Three branches merged within hours, with review rounds where they were needed.

The honest answer

Asked directly, the manager said the peers had not paid for themselves. Their advantage was memory, and the memory was elsewhere. Their cost was real: a terminal tab for the owner every time one was started, and a session that could be down exactly when it was needed. The recommendation is to run the project on one-off agents only. The roster rows stay in place until the owner says so.