Decision questions
The quality of the question determines the quality of the answer. Every answer is marked tested or assumed; questions are versioned when refined.
Choosing a methodology for a system
- M1 Source of truth. Which artifact should win when artifacts disagree, what form can it take (prose, structured data, executable tests, a formal contract or model, or running code), and who or what changes it? v2
- M2 Knowability. Can correct behaviour be stated before building, or only discovered by building?
- M3 Requirements stability. How often will intent change, and is the change driven by learning or by outside rules?
- M4 Cost of being wrong and reversibility. What happens if it is built wrong, and how hard is it to undo?
- M5 Verifiability. How will we know it is correct: test, proof, inspection, measurement, use?
- M6 Accountability. Must intent be provable later to a regulator, auditor, client or public?
- M7 Builder. Who or what does the building, and what inputs can that builder reliably use?
- M8 Lifespan. How long will this system live and be maintained?
- M9 Neighbours. What does it meet, which methodologies do those neighbours use, and what boundary contract is needed?
- M10 Switch conditions. What would make us change methodology?
- M11 Evidence. Have we used this methodology on a similar system, and what happened?
Choosing an artifact type
- A1 Question. What question must this artifact answer?
- A2 Reader. Who reads it: a person, an agent, a machine that executes it, an outside party?
- A3 Use. Will it be executed, checked automatically, or only read?
- A4 Duplication. Does an existing artifact already answer this question?
- A5 Upkeep. How long must it stay true, who keeps it current, and what does staleness cost?
- A6 Convention. Does the domain or audience expect a standard notation?
- A7 Fidelity. What is the cheapest form that answers the question well enough?
- A8 Format. Must it be diffed and versioned beside the work?