Compass Method Prototype
Table of Contents
1. When to use this skill
A decision hangs on something observable that nobody has observed. Does this approach actually work; is the difference visible; does the enforcement really bite; which of two layouts reads better. The deliverable is the observation, not the code that produced it.
Reach for it especially when about to ask the operator a question the
system could answer. A question about behaviour, timing, output or
whether a mechanism fires is not theirs to answer
(compass-principle-never-block-on-the-human): building the smallest thing that
shows the answer is faster than the round trip, and it hands them a
result to react to instead of a decision to make.
2. How to use this skill
2.1. 1. Write the question as an observation
What will you look at, and what will each outcome look like? A prototype whose result needs interpreting has not been aimed. "Does pruning the deployed tree actually stop the skills loading" is aimed; "does attenuation work" is not.
Decide in advance what each outcome implies, so the result cannot be read to mean whatever was already preferred.
2.2. 2. Build the smallest thing that produces it
Not a version of the feature. The smallest apparatus that makes the
observation happen (principle-laziness-protocol). Hard-code what does
not bear on the question, skip the error handling, use a copy of the real
thing rather than the real thing where that is safer.
Where the observation can be made against what already exists, make it there and build nothing.
2.3. 3. Observe, and record what you saw
Run it and write down the actual output, not the conclusion. The numbers, the message, the count of what remained. This is the part that survives the prototype, and a summary written from memory a phase later loses exactly the detail that made it evidence.
2.4. 4. Throw it away
Delete the apparatus, or move it to the scratchpad. A prototype kept "because it might be useful" becomes something to maintain that nobody designed and nothing tests.
Restore anything the prototype disturbed, and check that you did.
2.5. 5. Record the decision, not the code
The finding goes where the decision it settled lives: the task's plan or notes, or a knowledge document if it is durable. Say what was observed and what it implies, so the next person does not repeat the experiment to re-derive the answer.
Then re-match to the method the real work needs, now that the fork is settled.
3. When this method is the wrong one
Do not use it for a question whose answer is a preference rather than a fact: which of two acceptable behaviours the product should have is a product decision, and an experiment cannot settle it.
Do not use it when the apparatus would cost more than building the thing properly. At that point the prototype is the feature, and it should be built as one.
4. Recipes
- How do I build the system? — where the apparatus has to compile.
5. Reference
- Methods and the mode — what a method is, and how a phase binds to actions.
- Principles — the rules cited above.
- Verification and evaluation — the difference between an observation and a proof.