Amazon.com Interview About SPSG

The Author's Voice

Project management guru Steve McConnell's latest book Software Project Survival
Guide offers a menu of solutions for a host of software development ills.

Some might think that Steve McConnell has already done enough to help developers. When
he started writing his latest work Software Project Survival Guide, he was already the
author of Rapid Development and Code Complete, two of the most respected and widely read
books on software development around. In this third book, he takes a broader look at
software projects and how the pieces of sound developmental practice fit together into a
single survival strategy. Amazon.com spoke to Steve McConnell just as his book appeared.

Tom Mace, Amazon.com:

Software Project Survival Guide is your third book on
software project management. Is this book an update to your existing work? Or does it
cover new areas or address a new audience?

Steve McConnell:

Software Project Survival Guide is an expansion of a narrow
slice of Rapid Development. Rapid Development was like a cookbook that contained a lot of
recipes, but no specific menu. Software Project Survival Guide selects a few of
Rapid
Development's recipes and combines them into a meal--hopefully a nutritious one.

I don't think there is one "right" meal, and I don't think Software Project
Survival Guide is the one "right" way to conduct a software project either. But
some meals are tastier than others, and I think that Software Project Survival Guide
describes one of the better ways a person can run a software project.

Amazon.com:

Many people involved in big software projects seem to view them
as doomed to failure from the start and some project-management books seem to reflect this
negative approach. Your book is surprising for its optimistic tone. Do you really see the
malaise of software development as something that is addressable by organizational means?

McConnell:

Some software projects push the state of the art, some in many
directions at once, and those projects will always involve high risk and be exceptionally
challenging. Other projects are very large and challenging just for that reason. But most
small- and medium-size projects can more or less choose the level of risk they take on,
and those projects can be run in a way that virtually assures success.

The major problem the software industry faces at this time is not that we don't know
how to run projects successfully. It's that not enough of us know how. People are flooding
into the software field faster than we can train them. We're doing OK at training
programmers to use current technologies--programming languages, development environments,
and so on--but we're doing very poorly at training project leaders and technical managers
in the software-specific technical-management skills they need to conduct projects
successfully. If we can get these people trained in the kinds of skills I describe in
Software Project Survival Guide, then I think we have every reason to be optimistic about
software project outcomes.

Amazon.com

: How did you first get interested in the subject of software
project management? Were you on the front lines of a big software project that went down
in flames?

McConnell:

I've seen my share of software projects go down in flames, but
I've never really been interested in software project management for its own sake. I'm
interested in how to make software projects succeed. Some of the critical factors in
project success come into play at the coding level. I talked about those in Code Complete.
Some come into play at the technical leadership level or project management level, and I
talked about those in Rapid Development and Software Project Survival Guide. I'm
interested in working in the highest leverage areas I can find.

Amazon.com

: Of all the phases of software development, where are things most
likely to go totally wrong?

McConnell:

This is a key question because there is a big difference between
where things really go wrong and where the symptoms of those problems eventually appear.
Most times, things go wrong upstream, during requirements development or design. The main
reason requirements or design go wrong is that people don't do them. What makes this
difficult for people to see is that the symptoms of neglecting upstream work don't show up
until late in the project. Projects get mired in an extended code/debug/test cycle, and so
people quite naturally think they need better coding, debugging, and testing practices.
But they don't. Rewriting 15 modules because an interface needs to be changed isn't a
coding problem; it's a design problem. Changing databases at the end of the project
because performance turns out to be too slow is a requirements analysis or architecture
problem. Most of the really big problems are upstream problems, and projects need to fix
the roots of these problems upstream.

Amazon.com

: Your most recent book does not delve deeply into a comparison of
development methodologies. Do you have strong views on the subject or do you see the
battle of the methodologies as a side show?

McConnell:

We have a lot of methodologists in our industry who are selling
hammers, and they're trying to convince the industry that all software problems look like
nails. I see methodologies as tools that software developers need to apply selectively to
specific situations. If your problem looks like a nail, use a hammer. If it looks like a
nut, use a wrench.

Software Project Survival Guide doesn't delve deeply into methodology comparisons
because my first two books had already done that and I wanted to try a different approach.
With Code Complete and Rapid Development, I made the assumption that readers could read
about a whole range of methodologies and would have the good sense to choose the right
methodology for their specific situations. With Software Project Survival Guide, I made
the assumption that readers could read about one well-structured approach and would have
the good sense to depart from the generic approach when their situations called for it.

Amazon.com

: One of the classics of software development management,
The
Mythical Man-Month by Frederick Brooks was written over 20 years ago, yet people still
line up to read it. That doesn't speak very well for the industry's ability to improve
with time. Have you seen any hopeful signs over the five years since your first book on
the subject was published?

McConnell:

I interpret The Mythical Man-Month's success differently. I think
it identified some lasting truths about software development. Most books in the software
field don't last very long because they are identifying "truths of the
moment"--how to accomplish a specific operation in Java 1.1, how to double the
performance of your ActiveX control, and that kind of thing.

We absolutely need the truths of the moment. But for the software industry to improve
long-term, we also need to identify a lasting core body of knowledge that software
developers can learn and carry with them throughout their careers. I think we need more
books that people will line up to read 20 years after they're written. More of those books
exist today than did 5 to10 years ago, and so I find the success of The Mythical Man-Month
very hopeful both for what it is and for what it represents.