Translation and notes
A readable adaptation of the article's core ideas, with the original source clearly credited.
A coherent mental model makes a program easier to change; interruptions can disrupt that understanding. This short adaptation introduces an independent exercise for a fictional appointment-software team. Its workflow and measures are proposals of this article, not examples reported by the original author. The team wants to let customers reschedule appointments. Before delivery, it needs to discover whether sales, support, and engineering expect the same behavior.
Sales has promised editable appointments, while support knows that some services share a room or equipment. An engineer checks only the staff calendar. Map the request from the proposed time through capacity checks, saving, and notification. For each step, record what must remain true. Ask each role to predict the outcome of three invented cases independently: a normal change, competing requests for the final slot, and cancellation midway through a change. Compare answers before discussing implementation; an unexplained difference is an open product question.
Choose one difference to resolve. If the new slot becomes unavailable, should the old appointment remain? Assign someone to decide the rule and someone to implement it. Keep unrelated display requests outside this change’s acceptance criteria. Have a person who did not write the change run the cases and record actual versus expected outcomes, including any verbal help needed. Separate time spent repairing an implementation error from time spent settling a newly discovered policy question.
Keep a brief decision record with the accepted rule, checked cases, open question, and next review owner. If capacity rules remain disputed, resolve that dependency before expanding the feature. If behavior matches the agreed rule, use the team’s normal release process. This exercise should produce one reviewable decision and an explanation of one source of rework. A week of observations is not enough to rank team productivity; it can still reveal a misunderstanding before customers encounter it.
Selected advice from the article
- Prepare normal, capacity-conflict, and interrupted-change cases.
- Keep the rule and review evidence with the work item.
Operating takeaways
- Map the whole customer change and state the condition at every step.
- Collect independent predictions for invented cases before the review.
- Assign decision and implementation ownership for one unresolved rule.
- Compare observed outcomes with expectations using a reviewer other than the author.
- Separate defect repair from time spent making a new product decision.
Quick feedback
What did this article make clearer for you?
Choose a reaction or share a question or experience. Useful responses can shape future notes.
This is a free adaptation, not a word-for-word republication of the original article.