Interlude: some minor automation

One of the great appeals of the PSP philosophy is that of identifying the repetitive and uninteresting portions of a task and giving them structure and form so that they're easier to accomplish. Surely one of the best ways to do this is automate the process, using the computer itself-- after all, it is supremely qualified for repetitive and uninteresting tasks. And the process of collecting and processing data can (and should be automated.

To that end, I did a quick web search for the "personal software process" and "Emacs" using Google (my favorite search engine), and turned up the University of Karlsruhe's PSP tools page, referenced by a Mr. Lutz Prechelt. I don't know Mr. Prechelt personally, but had corresponded with him before on a scripting language "contest" he was hosting, and the tools on the page seemed consistent with his continuing efforts to improve the software development process.

The only tool I really stuck with so far, though, is pplog-mode, an Emacs add-in package which helps automate the data-collection process. It adds a window in an Emacs project; whenever a loggable item occurs, the developer presses F8 and is greeted with a time-stamp; by typing in a few mnemonic codes, one can log the beginning and end of development phases, interruptions, and defect fixes. A portion of the log I generated while playing with pplog-mode and the Eiffel program from lesson 1 is below:

1999-12-20 18:16:01 bcp                                    
1999-12-20 18:16:02 bi                                     
1999-12-20 18:16:04 ei                                     
1999-12-20 18:16:08 be                                     
1999-12-20 18:16:52 ee cp syn kn main.e                    
   didn't add the word "then" to the if-block
1999-12-20 18:20:24 be
1999-12-20 18:21:52 ee cp syn kn number_list.e
   numerous problems using = instead of := for assignment

The pplog-mode package had a companion piece, evalpplog, a Perl script for parsing logs and gathering information, but the information produced was too copious for me to use, and in a format I didn't like. To get something more to my needs, I cobbled together a python script which can take a "log format" and produce something which will better suit my needs for this independent study:

It can produce time logs in addition to defect logs. Hopefully this will suit my needs better, will streamline the process of data collection, and make this a more enjoyable experience; after all, if a process is too difficult to use, developers simply won't use it.

It should be noted that the log tools as they stand have a serious weakness: they only allow the representation of one error at a time, and obviously it's possible to have several extant defects simultaneously. But even the PSP defect recording log has this problem, since it focuses on "fix time"-- so here, we'll only log defects when we're actively focused on fixing them, to better judge fix time.

One last note: the new logging tool allows me to log both a defect type and a defect reason (actually, any number of classifications, but I'll stick to type and reason). This, to me, is critical-- a defect's type is interesting, but a defect's cause is more critical-- it gives me something to work toward; if most of my defects are caused by knowledge of syntax, for example, I can combat that by studying the language's syntax (or by choosing a less-confusing language!). To that end, and because numeric typecodes are poor mnemonics, I will be adopting the following as type and reason codes, taken directly from Lutz Prechelt's defect classification standard at http://wwwipd.ira.uka.de/PSP/Dokumente/DefTyp/defecttypes.html: