What do you think?
Rate this book
DISCIPLINE FOR SOFTWARE ENGINEERING
This new work from watts humphrey, author of the influential book, managing the software process, broadens his orderly view of software process management, and lays the foundation for a disciplined approach to software engineering. In his earlier book, t
Paperback
First published January 10, 1994
10 people are currently reading
186 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 4 of 4 reviews
December 16, 2015
First, some background on me. I'm a professional software engineer with just shy of 15 years experience. I've worked on everything from compilers and virtual machines for industrial automation to websites at massive scale with tens of the thousands of requests per second. I've freelanced for clients, served under managers, and led development teams.
I can say that nothing has been harder and more painful to learn in my career so far than quality and schedule management. I was never taught proper planning and estimation, and most of the books I read on Agile development never provided effective estimation tools - clients were rarely happy with estimation performance. As for testing, I learned very quickly and painfully that at scale, doing TDD alone is an inadequate quality management strategy - there are simply far too many types of issues TDD can't or won't catch. So what other strategies are there if not TDD? This book has many answers and will point you to even more.
The book provides many of the missing pieces glossed over or skipped entirely by university computer science programs and other, more popular books on software engineering. Namely, how to measure and manage software quality, construct sane plans, and produce reliable estimates. It provides exercises and process scripts to help you practice and reinforce what you've learned. The process evolution is also designed to introduce the new and usually foreign practices in a piecemeal fashion to prevent you from getting overwhelmed.
The main gripe that people seem to have with the book is the level of discipline required to actually follow its practices, which I think many view as oppressive or scary. However, as mentioned many times in the book - maintaining that discipline eventually becomes habitual and the insight and improvement produced by the process more than make up for the initially intimidating level of discipline.
As a motivator, I used the PSP to develop a project recently. I constructed a plan, used personal design and code reviews to manage quality, and filled out forms to log all the required data. While my estimation error for individual components was between -75% and +50% - the project itself ended up being delivered 8% ahead of schedule. The overall size was roughly 5,000 LOC, and to-date there have only been 3 defects found after development.
If this were a traditional software project there would have been no plan or the plan would have been no better than a guess, so I couldn't have tracked my planning performance or given a reliable estimate. Additionally, testing would have been my only quality management strategy, and using my earlier data as a guide there would have been anywhere from 250 - 1000 defects in the overall program. Even assuming an atypically high testing yield of 75% there would have been 63 - 250 defects remaining after development.
If you're ready to move from chaotic and undisciplined practices to something that will make your professional life more sane and effective I'd highly recommend this book to you.
I have and will continue to recommend this book to other software developers despite its relative obscurity. It has been invaluable for me, and I hope it will be for others too.
I can say that nothing has been harder and more painful to learn in my career so far than quality and schedule management. I was never taught proper planning and estimation, and most of the books I read on Agile development never provided effective estimation tools - clients were rarely happy with estimation performance. As for testing, I learned very quickly and painfully that at scale, doing TDD alone is an inadequate quality management strategy - there are simply far too many types of issues TDD can't or won't catch. So what other strategies are there if not TDD? This book has many answers and will point you to even more.
The book provides many of the missing pieces glossed over or skipped entirely by university computer science programs and other, more popular books on software engineering. Namely, how to measure and manage software quality, construct sane plans, and produce reliable estimates. It provides exercises and process scripts to help you practice and reinforce what you've learned. The process evolution is also designed to introduce the new and usually foreign practices in a piecemeal fashion to prevent you from getting overwhelmed.
The main gripe that people seem to have with the book is the level of discipline required to actually follow its practices, which I think many view as oppressive or scary. However, as mentioned many times in the book - maintaining that discipline eventually becomes habitual and the insight and improvement produced by the process more than make up for the initially intimidating level of discipline.
As a motivator, I used the PSP to develop a project recently. I constructed a plan, used personal design and code reviews to manage quality, and filled out forms to log all the required data. While my estimation error for individual components was between -75% and +50% - the project itself ended up being delivered 8% ahead of schedule. The overall size was roughly 5,000 LOC, and to-date there have only been 3 defects found after development.
If this were a traditional software project there would have been no plan or the plan would have been no better than a guess, so I couldn't have tracked my planning performance or given a reliable estimate. Additionally, testing would have been my only quality management strategy, and using my earlier data as a guide there would have been anywhere from 250 - 1000 defects in the overall program. Even assuming an atypically high testing yield of 75% there would have been 63 - 250 defects remaining after development.
If you're ready to move from chaotic and undisciplined practices to something that will make your professional life more sane and effective I'd highly recommend this book to you.
I have and will continue to recommend this book to other software developers despite its relative obscurity. It has been invaluable for me, and I hope it will be for others too.
February 7, 2013
This book is almost a text book and definitely not for light reading. At the same time it is not too difficult to grasp for any software engineer.
In my view this book should form a mandatory part of any software engineering curriculum.
A must read for all software engineers and proponents of Agile too (since I could sense the principles of agile development throughout the process) !
However it needs to be revisited and overhauled to fit the current scenario of software development (this book was written 1995 !). It requires too much of a discipline which while is nice to have is rather difficult to inculcate.
But all said and done hats off to Watts Humphrey for such a pioneering work.
More about this book at
http://bookwormsrecos.blogspot.in/201...
In my view this book should form a mandatory part of any software engineering curriculum.
A must read for all software engineers and proponents of Agile too (since I could sense the principles of agile development throughout the process) !
However it needs to be revisited and overhauled to fit the current scenario of software development (this book was written 1995 !). It requires too much of a discipline which while is nice to have is rather difficult to inculcate.
But all said and done hats off to Watts Humphrey for such a pioneering work.
More about this book at
http://bookwormsrecos.blogspot.in/201...
October 7, 2008
Too many programmers like to think of programming as art. And it is. But in doing so they fail to recognize the "engineering" part of software engineering. Some people might say that this book focuses too much on discipline and processes (via forms, metrics, etc.). Admittedly, I probably would not use all the forms and metrics outlined in this book, but I will certainly use many of the ideas. Moreover, I think that this emphasis on discipline is necessary especially for the hacker types who tend to dismiss it. The industry will mature through deliberate self-evaluation (including quantitative measurements) as this book prescribes.
Read
December 4, 2017dsadsadsad
Displaying 1 - 4 of 4 reviews