5.0 out of 5 stars Not for the developer that thinks he/she is good.
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...
Published on Oct. 28 2004 by S. Rozell
2.0 out of 5 stars The apotheosis of meaningless measurement
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...
Published on June 26 1999
Most Helpful First | Newest First
5.0 out of 5 stars Not for the developer that thinks he/she is good.,
This review is from: A Discipline for Software Engineering (Hardcover)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.
5.0 out of 5 stars A Textbook for Software Engineering,
By A Customer
This review is from: A Discipline for Software Engineering (Hardcover)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.
1.0 out of 5 stars Boooooring,
By A Customer
This review is from: A Discipline for Software Engineering (Hardcover)When I flipped thru it at the book store it looked interesting. When I started to read it at home my eyes glazed over. The subject is very interesting, too bad the book is so boring.
4.0 out of 5 stars Explains the personal software process (PSP),
This review is from: A Discipline for Software Engineering (Hardcover)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."
5.0 out of 5 stars A great complementary reference for XP - also CMM L-4 & 5,
This review is from: A Discipline for Software Engineering (Hardcover)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.
5.0 out of 5 stars A good introduction to programming for work,
This review is from: A Discipline for Software Engineering (Hardcover)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.
2.0 out of 5 stars The apotheosis of meaningless measurement,
By A Customer
This review is from: A Discipline for Software Engineering (Hardcover)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?
4.0 out of 5 stars A blueprint for capturing metrics!,
By A Customer
This review is from: A Discipline for Software Engineering (Hardcover)Watts again shows why he has helped pioneer the field of Software Process Improvement (SPI). The book breaks down large and complex industrial software practices to a much smaller and indiviual scale. This allows developers and Software Process Engineering Groups (SPEG's) to clearly identify software processes within their own work. The examples from small developmental work samples easily show the correlation with statistical trends and what metrics to capture. This book will help SPEG's and developers use the correct metric results right from the start to help create better software products.
Most Helpful First | Newest First
A Discipline for Software Engineering by Watts S. Humphrey (Hardcover - Dec 31 1994)
CDN$ 83.99 CDN$ 79.72
Not in stock; order now and we'll deliver when available