Book Review - PSP - A Self-Improvement Process for Software Engineers by Watts S. Humphrey
Category Book Reviews
As an IT professional and software developer, I'm all for standards and processes. PSP - A Self-Improvement Process for Software Engineers by Watts S. Humphrey (Addison-Wesley) outlines a personal methodology for improving your development efforts. But it's definitely not applicable to all environments...
Chapter List: The Personal Process Strategy; The Baseline Personal Process; Measuring Software Size; Planning; Software Estimating; The PROBE Estimating Method; Software Planning; Software Quality; Design and Code Reviews; Software Design; The PSP Design Templates; Design Verification; Process Extensions; Using The Personal Software Process; Index
From an overall perspective, I think the concepts in here are good and the book is well-written. Watts has devised a methodology that a developer can apply on their own to improve their coding, estimating, and defect resolution skills. This is done by extensive measurement and recording of statistic and time taken to accomplish certain tasks. These numbers are transferred to forms that can then be statistically analyzed to see the trends and make corrections in your techniques based on personal problem areas. The advantage that this methodology offers is that you don't have to get buy-in from an entire department in order to implement it. Conversely, PSP can be extended to apply to a team development environment in order to improve everyone's ability to work and develop code as a group.
Where I start to have issues is that it doesn't translate well to all environments. It's best applied to situations where you're developing programs with actual lines of code (like Java or C++) that allow you to do things like count lines of code, program sizes, or function points. It doesn't address rapid application development (RAD) environments like Lotus Notes/Domino very well, as "lines of code" is often next to nothing. Graphical design techniques that code underlying "plumbing" will make your numbers seem very small. Counting and tracking defects could be useful, but once again you'll often have to ignore stats related to defects per program size. You'll also need to be pretty comfortable with statistics to work with this methodology, as Watts gets into some pretty large formulas to generate the "score" of some of the tracking measures.
This is one of those books where if I were coding 15000 line Java programs, I might be really excited. Developing in a RAD environment makes me see a lot of this as unnecessary tracking for tracking's sake. But if you're a "true software engineer" in the most traditional sense, you'll probably find things in here that you'll want to try out.
As an IT professional and software developer, I'm all for standards and processes. PSP - A Self-Improvement Process for Software Engineers by Watts S. Humphrey (Addison-Wesley) outlines a personal methodology for improving your development efforts. But it's definitely not applicable to all environments...
Chapter List: The Personal Process Strategy; The Baseline Personal Process; Measuring Software Size; Planning; Software Estimating; The PROBE Estimating Method; Software Planning; Software Quality; Design and Code Reviews; Software Design; The PSP Design Templates; Design Verification; Process Extensions; Using The Personal Software Process; Index
From an overall perspective, I think the concepts in here are good and the book is well-written. Watts has devised a methodology that a developer can apply on their own to improve their coding, estimating, and defect resolution skills. This is done by extensive measurement and recording of statistic and time taken to accomplish certain tasks. These numbers are transferred to forms that can then be statistically analyzed to see the trends and make corrections in your techniques based on personal problem areas. The advantage that this methodology offers is that you don't have to get buy-in from an entire department in order to implement it. Conversely, PSP can be extended to apply to a team development environment in order to improve everyone's ability to work and develop code as a group.
Where I start to have issues is that it doesn't translate well to all environments. It's best applied to situations where you're developing programs with actual lines of code (like Java or C++) that allow you to do things like count lines of code, program sizes, or function points. It doesn't address rapid application development (RAD) environments like Lotus Notes/Domino very well, as "lines of code" is often next to nothing. Graphical design techniques that code underlying "plumbing" will make your numbers seem very small. Counting and tracking defects could be useful, but once again you'll often have to ignore stats related to defects per program size. You'll also need to be pretty comfortable with statistics to work with this methodology, as Watts gets into some pretty large formulas to generate the "score" of some of the tracking measures.
This is one of those books where if I were coding 15000 line Java programs, I might be really excited. Developing in a RAD environment makes me see a lot of this as unnecessary tracking for tracking's sake. But if you're a "true software engineer" in the most traditional sense, you'll probably find things in here that you'll want to try out.
| Permalink |
Comments
While it is true that the book mostly covers lines of code, he does mention that you should use any measure that seems to make sense for your language/environment and even gives some examples.
I mostly work in Mac OS X and use InterfaceBuilder both to build my UI and, increasingly, to hook it directly to my model (via Apple's NSBinding technology). So, technically I can't count Lines of Code for the UI, but what I could do is count whatever aspects of the interface I think might be a useful metric. For example, I could simply count each UI element (probably not a very good metric), or I could count every connection that I create (probably a much better metric of UI complexity).
Probably what I would do (will do, once I'm more comfortable with PSP) is measure everything I can think of for a while, then analyze all of my measures and see which ones correlate with time spent developing/testing/debugging the UI. The biggest unknown about this is that I'm not entirely sure I can automate this counting, which would certainly be necessary for any large projects.
One thing he does stress a lot is that the PSP is just the beginning. Once you're comfortable with it you can, and actually should, adjust it to suit how you work.
Posted by Andrew At 14:18:19 On 15/11/2006 | - Website - |
Are you aware of any standard / tailored norm for measuring Lotus Notes Code in terms of LOC. If you have any knowledge about it or can point me to somewhere where I can get some info on this it will be very helpful. We need it urgently to measure our project which is using Lotus Notes.
Thanks and Regards
Posted by Deb At 20:32:00 On 05/11/2006 | - Website - |
Posted by Duffbert At 18:38:05 On 07/11/2006 | - Website - |
Posted by eddy At 19:11:53 On 20/11/2005 | - Website - |