Personal Software Process (or PSP) refers to a reasonably rigourous method for a single developer to log his programming activity and the results. This information can help him track how he uses his time, and with the addition of line of code estimates and counts, can give him an accurate estimate of the amount of time it will take him to create future projects.

This is a list of the logs that I keep in my own PSP. The links on the various logs should (eventually) lead to examples of each kind of log.

  • Time log -- tracks dates, the project development phase I am in (planning, design, code, documentation, testing, etc...), sometimes the coding cycle I am in (if I am using a cyclical development model), and the amount of time spent in each phase. For mine, it is possible to have multiple entries for a single phase be separated by entries for different phases, which is useful since I will sometimes implement a feature (coding phase), and then test and repair it (testing phase).
  • Defect log -- tracks date of the defect being found, a guess as to which phase of the process it was injected into the code, the actual phase in which it was removed from the code, the type of defect it is, and how long it took to repair the defect. There is also a field that indicates which defect fix actually caused this defect (I rarely use it, but it is there since sometimes one fix will break something else). This log is painful to keep because it forces me to record my errors.
  • Size log -- this is where the LOC count is kept. My size log has fields in which build a list of the code modules that I am going to reuse along with the size of those modules and my estimate for the number of new lines of code I plan to add, a list of the code modules that I am going to write along with an estimated size of them, and then a table that summarizes my estimates and the actual results later.
  • Improvements log -- a document in which I enter ways to improve my PSP as I am writing the program. It is important to write improvements as soon as you think of them, otherwise there is a good chance you will forget them.
  • Engineering log -- *VITAL* if you keep nothing else, keep this! In this log, you write down what you are doing, when you are doing it, and why. It is really useful for writing down why certain design decisions were made. It can help other people in maintaining your code, and it can be used in court cases (if you're ever unlucky enough to get into one, and if the court decides to accept it) in your defense to show that you are not incompetent and that you properly thought through what you were doing. Think of this as the engineering equivalent of a lab manual which most lab scientists depend on to prove the credibility of their own work.
  • Progress log -- actually, I haven't developed this, but it is going to be a log that shows everything that I have to write and gives it a score based on either how long it will take or how big it will be. This is one of those things that can give a warm fuzzy, in addition to giving an idea of how much longer before you can tell your boss to shut up and distribute the software.
  • Overall summary -- I keep the summary for my size log as well as a summary of the time spent in each phase, the number of defects found in each phase, and the number of defects injected in each phase.

Now that you've gone through all of this, check out my tips for creating your own PSP.

The most important thing with this is that you must always be honest when working on a PSP. This is supposed to help *you*, not your manager, although it can give your manager some information that will help him plan the rest of this project and future projects. With this system (actually taught in one of the Software Engineering courses at OU), I got to the point that on a 12 - 15 hour project (I never did one that took longer), I could estimate my finishing time and be accurate to about 60 minutes.

Unfortunately, most managers either see no value in this or would use this information as a hiring/firing measure. This is BAD, and it probably causes a stigma against the use of such tools. Only managers who realize the value of this sort of system would realize that the information it reports should almost never be used in making employment decisions. It's mere existence should show a good level of discipline in the programmer that should make him valuable.

Also unfortunately, my initial experiments to expand this to something that an entire software engineering team could use met with failure, probably as a result of their lack of enthusiasm. I think that with some help and some experimenting, the results of multiple PSP's from a team can be put together to keep a team PSP.

Log in or registerto write something here or to contact authors.