Build the Smallest Thing That Answers the Riskiest Unknown First
Some questions a design raises cannot be settled by argument, because nobody in the room knows the answer. Will this store hold the write rate we expect on the hardware we can afford? Does this component's interface actually support the operation our design needs, or only something close to it? How long does a failover really take? Analysis makes those questions sharper and never answers them. A time-boxed experiment does. The rules that make it useful are strict. Pick the unknown whose wrong answer would cost the most to discover late, which is usually one that sits under an irreversible decision. Write the question as something with a measurable answer before you start, so you cannot rationalise afterwards. Fix a time budget and stop when it runs out, answered or not, because an unanswered question is itself a finding. Build only enough to answer that one question, and expect to throw the code away. Then write the answer where the decision will be made, not in someone's head. Doing this in order means the design's biggest risk retires first, while there is still time and little has been built on top of it. You can now turn a design argument into a question with a measurable answer and a time budget, and order several unknowns by what learning late would cost.
This Concept is waiting for its first lesson!
Some questions a design raises cannot be settled by argument, because nobody in the room knows the answer. Will this store hold the write rate we expect on the hardware we can afford? Does this component's interface actually support the operation our design needs, or only something close to it? How long does a failover really take? Analysis makes those questions sharper and never answers them. A time-boxed experiment does. The rules that make it useful are strict. Pick the unknown whose wrong answer would cost the most to discover late, which is usually one that sits under an irreversible decision. Write the question as something with a measurable answer before you start, so you cannot rationalise afterwards. Fix a time budget and stop when it runs out, answered or not, because an unanswered question is itself a finding. Build only enough to answer that one question, and expect to throw the code away. Then write the answer where the decision will be made, not in someone's head. Doing this in order means the design's biggest risk retires first, while there is still time and little has been built on top of it. You can now turn a design argument into a question with a measurable answer and a time budget, and order several unknowns by what learning late would cost.
Are you a teacher? Sign in to start contributing.
Sign In