Defect tracking is another of the primary tools of the PSP. By keeping track of your errors you can learn where your strengths and weaknesses are. You can also determine how much time you spend "bug hunting". For example, if you logs show that you spend nearly all of your time fixing design flaws, you can probably infer that you're not spending enough time in design. At first, it seems odd to predict how many errors you will have. We'd all like to have zero for our total expected defects, but that is not a reasonable expectation. By planning on our errors and preparing for them, we can minimize their impact. It's also important to know what phase our errors are being created in so that it's possible to pay more attention during that phase. Both the Defects Injected and the Defects Removed pages are very similar. In future versions, I'd like to put an image of an impaled bug on these pages to liven them up a little. While defects are the topic of conversation, you should try out the Defect Log. This dialog simply lets you keep track of your defects. It is important that if you're going to track defects, you are thorough. This means ever defect, right down to the semicolon. If you don't log all of the defects then your data will be skewed and worthless. Even though you can fix errors much faster if you are not logging them, the logging data is useful later. (The effort of entering the data about the error is also good negative reinforcement not to make errors in the first place!) You can update your Actual data fields on your project pages with the log too. Your defect log for the project is automatically loaded and saved when you open or exit from the dialog. I use a different classification for errors than the one described in _A_Discipline_For_Software_Engineering_. Here is my classifications and their meanings: PNC Puncuation. This includes all the simple typos that come from C++ Included are missing ; incorrect {} () lack of :: and the like. This does not include < > = = ! && || because these are logical errors. SCP Scope. Scope deals mostly with lack of include headers. Any time you want to use something and find that it is not available you have a scope error. This includes public: and private: errors. ARG Arguments. Argument refer to function matching. From the header to the definition to the usage. If the arguments are inconsistant it's an ARG error. Included in arguments is forgetting to tell the compiler that a method belongs to a particular class, since the class the the method is in is a kind of an argument. Matching returns is also of this type, but forgetting to return somehting is a FFNC error. OO Object Orientation. Refers to incorrectly using the OO features of C++ in a conceptual mis-understanding. Failing to correctly derive from multiple base classes is an example. FFNC Forgot Functionality. Indicates that I have forgotten to code some bit of functionality. This must be something that I clearly understand, but have simply forgotten to type in. Often for me this is forgetting to produce output. CFNC Changed Functionality. Built it to do one thing, but decided I like it better different. Usually this notes a cosmetic change. Things that do not change the underlying design but do change code go here. MNMR MisNoMeR. Gave something the wrong name. Either typed the name wrong Misspelled it, gave it multiple names, anything involving my inability to spell. LGL Logical. These are the errors where I have incorrectly done some math. Not had the > facing the right wa. Basically, this is when I've wrtten code that looks ok, compiles and still dosen't do anything useful. TYPE Type. I have decided that I want one or more variables to be of a different type. For example, deciding to move all my vars from float to double, or from int to long. ENV Environment. Compiler crashes, Source code not completely saved, General Protection Fault, Sudden Total Existance Failure....