Document Work


Bug state is not static, and tricky defects can take several iterations of work to find and fix properly.


The bug report has a life and grows with changes. In the context of this ongoing work, knowing what changed and why, and what worked or didn't, helps maintain a sense of history to the code. One might use this to implement something like the BuiltForLife? idea.


This kind of long-term overview information is really important, particularly to people jumping on the horse mid-stream. Additionally, TheRoadNotTraveled helps to prevent mistakes being repeated.

Periodically revisiting notes, logbooks, and weekly reports reveals what kind of knowledge the team has collected over time. This sort of review helps bring about the understanding of knowledge evolving into the domain of wisdom.


Document all work on a problem in the bug tracking tool. Use the description and comments field to make note of important issues and facts. Attach files with error output, screenshots, or even snippets of code patches to document what was done and why. Records of what was worked on and resolved represent a knowledge base.
See: CoordinateEfforts, MicroDecisionAwareness, DefectTrackingPatterns, BlindAlley

Contributors: MartySchrader

CategoryKnowledge, CategoryDocumentation

EditText of this page (last edited May 10, 2010) or FindPage with title or text search