Some time ago, I developed some applications for MS-DOS, then the dominant operating system for small home computers. The applications (a graphics and sound framework intended for simple animation and multimedia, and a small game using the libraries) were recieved well enough for an amateur effort, and even brought in a little cash and the thrill of seeing my game on the "cheapware" racks at the local software store. Near this time, Windows '95 had just been released, and both my publishers and myself felt that this "new" operating system might well be a dominant player in the games market (here in late 1999, with the dominance of Windows as a personal computer OS fairly well established, this was apparently a wise prediction!). As a result, we decided that a quick 3-4 month rewrite was in order.
It is now nearing 2000, almost four years after the original planned rewrite-- which still is not complete. While many other things have impacted this-- several moves, the decision of the publishers to stop producing games, many additional time commitments-- the fundamental problem has been a lack of personal engineering practices.
Even in one of the simplest of software development environments-- a single developer on a single project-- I could not predict with any degree of reliability the size of a development task, or the cost in time and resources to complete it; I had little comprehension of basic software engineering processes; my environment was very much what Steve McConnell refers to as "code-and-fix development" [McConnell96].
This project, an independent study of the Software Engineering Institute's (SEI) Personal Software Process (PSP), represents part of my search for ways to improve my own personal practices and to seek tools for use by the small developer. The PSP promises to be a scaled-down version of industrial processes, suitable for the individual practicioner. While Watts Humphreys, author of the primary reference used in this study (A Discipline for Software Engineering), notes that "The PSP can help to make software engineering the fun it should be", I am primarily interested in its effects on software predictability, reliability, and quality.
Because the object of study is a personal software process, the focus in this study will be on my interactions with it as a single developer-- how much effort it takes to employ the PSP, how much it impacts the development process, how much it can be automated to reduce its impact on personal work styles, etc. Because I'd like this to be useful not just as an academic study, but also as a readable document to other single (or small-team) developers, I will focus on readability and practicality over erudition. When I was doing informal research on the PSP some time ago, I found few personal accounts; I mean to make this into the document I desired then.