Rating: 
Summary: Explains the personal software process (PSP)
Review: Analyze your personal software development performance as a self-improvement initiative. Categorize time in phases and record the amount of time spent on each assigned task in each phase. Develop historical databases of size and productivity as illustrated by the project-planning framework (Fig 5.1). Compare initial estimates of size, effort, and schedule versus actual size, effort, and schedule (management metrics). Track defects, classify defects, identify problem components, and establish reliability measurements (product metrics). Presents the goal-question-metric, design and code reviews, cost-of-quality measures, unit testing, defect prevention strategies, and verification process. Includes a set of exercises that put the PSP program into practice. The appendix contains an excellent section on statistical techniques and a complete set of forms and instructions for implementing the various PSP measurement programs. Some questionable practices: the author insists on counting compiler errors as defects, the author uses compiler errors in reliability metrics calculations, and the author recommends performing a code review before compiling the program.A quote from the author, "In addition to providing the data you need to handle management pressure, the PSP offers many other potential benefits as follows: The insight you gain into your talents and abilities; The stimulation of an almost unlimited stream of improvement ideas; The framework it provides for personal improvement; The degree of control you gain over your work; The feeling of pride and personal accomplishment; An improved basis for effective teamwork; The conviction to do the job the way you know you should."
Rating: 
Summary: How to, Value, Aim for and Real case
Review: I did skim read much of this book looking for the how to's and evidence of value, of which I found many in the 1st half of the book. The last few chapters tend to describe things he thinks are worth aiming for, rather than precise actions known to have value. The major exception is Chapter 13, which has a Quality Function Deployment table that describes how to balance competing development objectives.
The methods described in this book are known to be very successful, see "Software Process Improvement Works" [Ferguson 99]. The methods described are used by Microsoft, Intuit, The Boeing Company, Allied Signal, Lockheed Martin, NAVAIR, and SAIC, see SEI web pages.
I wish he had omitted his long explanations and labelled the sections "How to, Value, Aim for and Real case", then I could have bypassed the "Aim for" sections, as I was not interested in them. My impression, "A discipline for software engineering" is the work of a genius, read it.
Rating:
Summary: Not for the developer that thinks he/she is good.
Review: I have read the book and implemented the processes both in and out of a school envirnoment. I have seen measurable positive results in my skills. I recently learned that an instructor I had over 7 years ago still refers to me as the best programmer he has ever met, and I owe this entirely to this book. If you think you are already good, then chances are are that the book won't change you. If you want to find out how good you are, or more importantly become the best you can be you will most likely be enthralled by it.
Rating:
Summary: A good introduction to programming for work
Review: In addition to describing the Personal Software Process, this book introduces practical topics that are important to a working programmer. Of particular importance are metrics, inspections, estimation, and scheduling. It takes effort to implement those practices well, but they do address important concerns. If you program for a living, I recommend this book.
Rating:
Summary: A good introduction to programming for work
Review: In addition to describing the Personal Software Process, this book introduces practical topics that are important to a working programmer. Of particular importance are metrics, inspections, estimation, and scheduling. It takes effort to implement those practices well, but they do address important concerns. If you program for a living, I recommend this book.
Rating: 
Summary: The apotheosis of meaningless measurement
Review: Sometimes I question the need for philosophy, then a book like this comes along and I remember why philosophy is important. Philosophers do us the service of carefully analyzing premises, claims, and all the varied artifices of thought. Philosophers notice the clouds beneath the castle. Watts Humphrey's book is in need of a philosophical overhaul. It is a fine expression of 19th-century ideas about scientific management and the nature of human cognition, but takes little note of modern revelations about how human minds work, and how software design happens. The book is an ode to measurement. Humphrey doesn't justify or explain his measurement theory, though. He seems more intent on telling us what to do than on helping us ask questions like "What do these numbers mean?" He proposes ways to measure quality, but not ways to understand goodness; ways to measure productivity, but not ways to understand productivity in relation to our ambitions. Reflection, inspiration, collaboration, dialogue, discovery, invention, ingenuity, all of these vital processes are ignored in his calculus. But since his calculus is embedded in a prescription for what we're supposed to do, anything left out is driven underground (or underwater, like an animal that doesn't get a ticket for Noah's Ark). It's a good thing for the technology that so few people are disciplined in the way Humphrey proposes. I just want to point out that there is an alternative to the Brave New World of Watts Humphrey and the SEI. Search for books by Gerald Weinberg and you'll find a polar opposite view of software engineering as a social and cognitive discipline. Weinberg's book on measurement "Quality Software Management, Vol. 2: First-Order Measurement" is a must read. I also recommend "Things That Make Us Smart" and "Cognition in the Wild", two books that startled me by showing how much cognitive psychology could help the software engingeering craft, if ever we computer people but wake up and take notice. Discipline is important in any search for excellence. Let's build our discipline on a sound and meaningful foundation, eh?
Rating:
Summary: A great complementary reference for XP - also CMM L-4 & 5
Review: This book's title contains two key words that are woefully missing from most development projects: "discipline" and "engineering". With this book Mr. Humphrey introduced the personal software process (PSP), which subsequently spawned the team software process (TSP). Although the material is over 6 years old and does not seem to have gained wide acceptance in commercial development and project environments, it provides a roadmap to effectively integrating the increasingly popular extreme programming (XP)approach that was developed by Kent Beck. How does PSP align to XP? Both approaches focus heavily on project planning and estimating, and controlling quality, cost and schedule. Both approaches also use metrics as a baseline and past performance to predict future productivity and quality during the planning and estimation phases of new projects. Moreover, both approaches impose a rigorous discipline at a low level in the development process - PSP at the individual level and XP at the 2-person paired team level. An excellent book on XP that supports this premise is Planning Extreme Programming by Kent Beck and Martin Fowler. The methods that Mr. Humphrey proposes in this book are the building blocks of an effective XP organization because much of the metrics he proposes for capture, analysis and tracking are the very ones that are key to XP. These methods add the "discipline" into the development process, and "engineering" into the quality approach to any development effort, regardless of whether the methods are aligned to XP or any other methodology. Further, the disciplined engineering approach will provide organizations striving for capability maturity model (CMM) level 4 (managed) or 5 (optimizing) with some valuable tools and techniques with which to achieve these higher levels of maturity. Of course, this is also useful to organizations that are implementing SPICE (Software Process Improvement Capability dEtermination), organizing software process engineering groups, or implementing mature project management methods for development projects. I agree with a previous reviewer that development is also a social and cognitive discipline, but it is not solely those. The social and cognitive approach will only get you so far. The same is true of the disciplined engineering approach. You need both, and this book is a valuable work for the latter. In my opinion this book is probably more valuable today then when it was first published because the approach required too much rigor for most organizations to adopt. However, with the growing movement towards XP I believe that this book will add details and techniques that are only superficially addressed in the XP body of knowledge and literature. If you are a proponent of XP this book provides some proven, concrete techniques. If you are striving for higher levels of capability maturity this book (and the companion, Introducing the Team Software Process by Mr. Humphrey) will give you the tools to get to managed, and from there to optimizing. I believe this book is a 5-star classic that was ahead of its time.
Rating:
Summary: A great complementary reference for XP - also CMM L-4 & 5
Review: This book's title contains two key words that are woefully missing from most development projects: "discipline" and "engineering". With this book Mr. Humphrey introduced the personal software process (PSP), which subsequently spawned the team software process (TSP). Although the material is over 6 years old and does not seem to have gained wide acceptance in commercial development and project environments, it provides a roadmap to effectively integrating the increasingly popular extreme programming (XP)approach that was developed by Kent Beck. How does PSP align to XP? Both approaches focus heavily on project planning and estimating, and controlling quality, cost and schedule. Both approaches also use metrics as a baseline and past performance to predict future productivity and quality during the planning and estimation phases of new projects. Moreover, both approaches impose a rigorous discipline at a low level in the development process - PSP at the individual level and XP at the 2-person paired team level. An excellent book on XP that supports this premise is Planning Extreme Programming by Kent Beck and Martin Fowler. The methods that Mr. Humphrey proposes in this book are the building blocks of an effective XP organization because much of the metrics he proposes for capture, analysis and tracking are the very ones that are key to XP. These methods add the "discipline" into the development process, and "engineering" into the quality approach to any development effort, regardless of whether the methods are aligned to XP or any other methodology. Further, the disciplined engineering approach will provide organizations striving for capability maturity model (CMM) level 4 (managed) or 5 (optimizing) with some valuable tools and techniques with which to achieve these higher levels of maturity. Of course, this is also useful to organizations that are implementing SPICE (Software Process Improvement Capability dEtermination), organizing software process engineering groups, or implementing mature project management methods for development projects. I agree with a previous reviewer that development is also a social and cognitive discipline, but it is not solely those. The social and cognitive approach will only get you so far. The same is true of the disciplined engineering approach. You need both, and this book is a valuable work for the latter. In my opinion this book is probably more valuable today then when it was first published because the approach required too much rigor for most organizations to adopt. However, with the growing movement towards XP I believe that this book will add details and techniques that are only superficially addressed in the XP body of knowledge and literature. If you are a proponent of XP this book provides some proven, concrete techniques. If you are striving for higher levels of capability maturity this book (and the companion, Introducing the Team Software Process by Mr. Humphrey) will give you the tools to get to managed, and from there to optimizing. I believe this book is a 5-star classic that was ahead of its time.
Rating:
Summary: A Textbook for Software Engineering
Review: This is an excellent textbook for software developers with sufficient experience and discipline to produce professional software. It is not a philosophical treatise or a book on skills. It is not to be read casually before bedtime. In order to get something out of it, you must carry out the assignments. The PSP training is an iterative process, slowly enhancing your process. The PSP is all about gathering data, devising improvements, and seeing the improvements through. The assignments in the book are challenging enough to require some design and have enough lines of code that you can gather data. Over the course of the book, you'll make up to six enhancements to your proces, to the point that you have the experience to develop your own processes. If you carry out the book assignments, you'll also have some basic tools for measuring your software (lines of code counters) and process (statistical software). In order to be effective with the PSP (or software in general), you need to follow good software design practices. The PSP enables you to capture the data that show this. Good design, though, is outside the scope of this book. This book was the textbook for a PSP course for engineers I just completed. The course was a lot of work. In order to get something out of it, I had to be disciplined. In order to get something out of the book, you'll need to be very disciplined because you won't have the structure of a class to ensure you carry out your assignments. The PSP does not work without discipline to capture good time and defect data and to follow the process improvements. If you have successfully learned the PSP process, be it in a formal classrom setting or through this book, you will be able to give estimates of size and time that are +/- 10% with a confidence of 70%. Of course large projects require larger processes than the Personal Software Process--those are outside the scope of this book. For an industry that is plagued by over-estimates, this is an excellent first step for engineering at the individual level.
Rating:
Summary: Of doubtful practical value
Review: This is not a software engineering text. The author does not talk about how to write better programs. Instead he addresses how engineers might produce better numerical data to give management more control over the software development process.
The book readily admits that the methods only work well when an identifiable customer is able to provide an accurate and detailed problem statement. Perhaps in some isolated cases this may be so.
The author relies heavily on statistical methods. This may be comforting to management schooled in 6 sigma methodology. However it is bound to make an experienced engineer feel like a production unit on a software manufacturing line.
The book is extremely dry and tedious. The author does not know how to hold the reader's attention. He tends to ramble on for many pages before getting around to making a very small point.
The material may be useful in some isolated cases, but for most, the evidence isn't abundant that the benefit justifies the effort.
| 
