September 2000
Volume 2 • Number 4
Contents
Resource Reviews
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.
PROFESSIONAL CONDUCT
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.
PROJECT MANAGEMENT
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....