Verification is the deliberate check that an idea, assumption, or creation is correct and works as intended. A painter steps back, a poet rereads, and a scientist calculates or experiments. In programming, verification turns a promising insight into something trustworthy. section 5.2.1
Treat verification as part of a recursive creative process, not as a final ceremony. Compile and execute unit tests; if they fail, return to the idea, gather more information, or let the problem incubate before trying again. This resembles test-driven development’s red, green, and refactor cycle. section 5.2
Make assumptions visible and test them:
- Inspect unclear code instead of relying on a plausible explanation. section 5.2.1
- Place breakpoints and inspect memory when runtime behavior is uncertain. section 5.2.1
- Step through execution to break up confusion. section 5.2.1
- Write unit tests so verified behavior remains clear to colleagues and to your future self. section 5.2.1
- Invite critical questions and feedback; other people’s evaluation can reveal unclear or overly complicated work. section 5.6
The aggregated-root assumption
A programmer assumes that saving one object automatically cascades to another parameter. A colleague asks for inspected code and integration tests. The assumption becomes knowledge only after those checks show what actually happens. section 5.2.1
Figure 5.2 The five steps of the creative process. An overabundance of arrows emphasizes the interrelatedness among the steps. Participation is usually step 1, but a sudden idea might just as well put the process in motion. Rejection is not necessarily the end, provided enough energy remains to rework the concept.
The interrelated arrows emphasize that verification can send a creator back to participation, incubation, or illumination rather than ending the process. section 5.2
