SQP welcomes a new associate editor with responsibility for the journals Resource Reviews section. Susan McGrath Carroll is a senior software quality analyst with SAS in North Carolina. She has worked in the Quality Assurance Division at SAS for the past 14 years, concentrating on internal and external quality awareness, process improvement, and communication. She began her service with the ASQ Software Division as co-chair of the 1992 International Conference on Software Quality (ICSQ), chaired the 1994 ICSQ, and served as programs chair, chair-elect, and division chair (1996-98). She has been the divisions Internet liaison and maintained its Web site since 1998. Carroll was co-founder of the software group of the North Carolina Quality Assurance Discussion Group, which has since evolved into the RTP-SPIN. She served on the cut-score committee for the CSQE and became a CSQE in 1998. Carroll is a senior member of ASQ, and a member of IEEE, the Computer Society, and IEEE Standards group.
After the Gold Rush: Creating a True Profession of Software Engineering
Steve C. McConnell. 1999. Redmond, Wash.: Microsoft Press. 182 pages (CSQE Body of Knowledge areas: Software Processes, Software Project Management)
Reviewed by Pieter Botman, True North Systems Consulting
Software quality practitioners may view themselves as quality assurance professionals applying their knowledge within the software domain, or as software engineers focused on specific application of quality assurance techniques within the software life cycle. While this book delivers insight to all software quality professionals, it is most relevant to those who see themselves within the field of software engineering.
This book is written about a broad topic, for a broad audience. McConnell wishes to describe the occupation of computer programming as it exists today, and the profession of software engineering as it can exist in the future. A tall order, indeed!
Thanks to his well-known bestsellers Rapid Development and Code Complete, readers will be familiar with McConnells down-to-earth style and use of realistic scenarios or incidents. McConnell uses several stereotypical situations to illustrate the lack of professionalism and the corresponding need for it.
Consider this example: A team leader produces an estimate for a software product development cycle, but his manager does not accept it, eventually forcing the team leader to agree to some unreasonable combination of functional requirements, available time, and resources. The team leader (correctly) objects when his manager overrules his estimates, but feels he had little choice in accepting the managers dictates. The manager, on the other hand, has little faith in the team leaders estimate, and less faith in the process that produced the estimate. The result? An impasse between the unbelieving and the unbelievable.
McConnell points out that while managers (and customers) can always be expected to push software developers to compromise in one or more ways, the true software engineering professional should be prepared--prepared with credible methods and appropriate data. The essence of professionalism is credibility and respect, and that cuts both ways. Software engineers must earn respect from their managers and from society at large. They can earn the respect by (collectively) consistently producing reliable software.
Everyone in todays technology-oriented society knows of high-profile software fiascos. Like other books, this book points out that many software projects are canceled or fail to achieve their goals. These and other motivations presented by McConnell for the establishment of a true software engineering profession should come as no surprise. What might be more difficult for a code jockey to accept is McConnells pragmatic assessment of what must be done. He describes some of the necessary elements of a profession, starting with a recognized core body of knowledge. Around this core, he adds elements such as professional education programs and their accreditation, professional skills development and individual certification, professional societies, and a code of ethics.
It might seem that little progress has been made in establishing and agreeing upon these elements, but McConnell provides evidence of such. He devotes adequate space to a discussion of the licensing controversy, which is to be expected when there are so many groups with vested interests. But licensing per se should not be the primary goal of a drive toward the establishment of a software engineering profession. Accordingly, McConnell emphasizes the positive aspects of professionalism and completes his vision of a well-established and effective software engineering profession.
The train is starting to roll, gathering momentum. Recent issues of IEEE Computer and IEEE Software have addressed software engineering as a profession, and additional information on the various elements of the profession (ACM Code of Ethics, SWEBOK Stoneman release, and so on) is being published. But this book should be read, as it provides an excellent introduction to the scope of software engineering as a profession, and what professionalism entails for individuals working in the industry today. It is suitable for all software developers, regardless of background. It should be read by individuals who are unsure of their career course within the profession of software engineering. It serves as a wake-up call to individuals interested only in the hottest languages or technologies of the day, and to managers who promote this short-term kind of thinking.
The Deadline: A Novel About Project Management
Tom DeMarco. 1997. New York: Dorset House Publishing. 310 pages. (CSQE Body of Knowledge areas: Software Quality Management, Software Project Management)
Reviewed by Dr. Patricia McQuaid, associate professor of Management Information Systems, California Polytechnic State University
I read this book shortly after it was published in 1997 and was immediately impressed with how DeMarco successfully ties software project management and software quality together in a captivating manner. I could see the relevance to both current software professionals and to those aspiring to work in the field. As a professor, I decided to incorporate it into my software quality management class, which consists mostly of graduating seniors from both the Department of Management Information Systems (College of Business) and from the Department of Computer Science (College of Engineering) at California Polytechnic State University.
The book is a fictional account of a project manager, Mr. Tompkins, who is kidnapped to an island where he may be able to realize his dream: to experiment with team sizes and developers of varying levels of expertise. The teams compete against each other to develop the best products, all the while allowing him to experiment with his project management theories. Of course, there is an impossible deadline to deal with. In addition to weaving an entertaining story around his methodology, he records certain key principles at the end of chapters in the form of entries into his diary.
This book review is different from others in that the majority of the review consists of comments from my students. The class is taught once a year, and this is the second year I have incorporated the book into the course. After the students read the book and before we discussed it in class, I gave an in-class, closed-book quiz, with a review of The Deadline being the last question. Following are representative comments from the students which readers might find interesting. I believe these comments capture the essence of the book. (I have slightly edited the comments for clarification purposes and obtained the students permission to include their comments in this review.)
This is the question posed to students: I would like your honest opinion of how valuable you found this book to be for the class. There is no one correct answer here, but to receive full credit, you need to justify your answer. (If you dont like it, fine; justify your response.)
Following are their responses.
This book is very valuable. It gives a real-life view of problems that can come up for a large project. Although it is a fictional story, the problems mentioned plague most projects and are not dealt with properly. DeMarco does a fantastic job of showing the reader how to solve problems. He covers numerous aspects such as team size, conflict resolution, design, emotions, pathological politics, metrics, and so on to teach the reader the most efficient ways to run a project properly. This book taught me a lot and was also fun to read.
I believe this is quite valuable for the class; it gives a lot of real-world situations that commonly occur in the software development process and a lot of reasons why things work the way they do in management. It reveals the many factors in a successful project and why projects usually never meet their deadlines.
I thought that it was a good book. The journal entries (diary entries) that Tompkins made gave me some important things to remember. The book made me realize a lot of important concepts and made me think a lot, too. I didnt just read itI would think about how I would react in some of the given situations when reading the book.
I actually enjoyed the book and found it very valuable. Knowledge of general project management skills is very useful, especially for this class. I plan to keep this book and will probably refer to Mr. Tompkins journal entries for a clear and concise synopsis of the valuable points in each chapter. He goes over everything from risk management, to design, to conflict. These are all invaluable subjects for this class and in the workplace.
This book was educational and entertaining. I found the story hysterical at times, and the management principles were expressed in the least dry way possible (although quite technical at times). Thanks!
It was definitely a cross between fiction and nonfiction, which made it all the more enjoyable. The part I liked the most is the journal. It sums up all the key points that DeMarco was trying to get across. He made numerous valid points and got across his ideas in a very understandable way.
I thought the book was a great learning tool. Some of the material we read can be pretty dry, and this was a nice change of pace. It took real-world problems, and showed how to address them and what to learn from them. The ending was a little far-fetched, but I enjoyed it nonetheless!
I really like this book. I would probably want to read it again to fully absorb the concepts, since there were so many lessons learned. I like how it tied everything we learned into one book: from people problems and basic team characteristics to risk management. I think this book has a lot to teach, and I am glad to have had the chance to read it. It was an easy read, as well. One of the main points I liked is when Tompkins was complimented that it wasnt the fact that people liked him, but that he liked people. I hope to incorporate the books concepts, in my hopes of being a future manager.
It was light, casual reading that brought home a lot of the project management ideals we are learning here. I really wish there were more books like this for every subject, and maybe we could get rid of those boring, dry textbooks, and learn in a more fun, enjoyable setting.
I feel that the book, though a little far-fetched, is a wonderful summary of many of the points we covered in this course. It put them together in a real-world situation so we could see how they might actually affect a real project. It definitely gives some insight into how the concepts work rather than just the theoretical, which is all some students get from lecture-type classes. Seeing the concepts in action is the icing on the cake for a course such as this. Great choice!
I honestly enjoyed reading this book. It was by no means a homework assignment where I felt forced to read it. I casually read it every night before I went to sleep, and it was really enjoyable. I got a lot out of how to manage a project, but what I liked most were the more generic comments or points made by DeMarco. For example, the sense that everyone feels less intelligent than the others is so right on the money. I see it happen every day in my classes, where I know not everyone knows what is going on, but they dont want to say anything. I also liked the anger = fear point. Next time I see an angry manager I dont think I will be as intimidated. I think that many times managers are fearful and take it out on their employees. This book is an innovative way of approaching project management, and DeMarco turns what could be a painfully dry subject into anything but that.
I found this book one of the most valuable parts of this class. It was both interesting and funny. But above all, it helped me learn. It took a lot of words that I had heard before and put them into a story. This gave me a way to relate to these key phrases and figure out what an important role they play in business and software development. It was also a good way to see how hard project management truly is. I always thought project management just entailed making Gannt charts and putting people into groups. It is so much more than that. Project managers are the key to each organizations successes and failures. This book is a wonderful way to get students into what we are learning.
I think the book has some really good points with regard to project management and some realistic advice as well. One of the best sections is at the end, about dealing with clueless or horrible upper management. It says, bide your time, for opportunities here or elsewhere and miracles can happen, but dont count on it. I thought the book was great for getting its point across in an amusing way. I think the real value of the book will come out later though, when we are actually managing a project or at least working on one, and a situation comes up that makes me snap my fingers and say, Ahh, thats what DeMarco was talking about....