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. |
Email me at stevemcc@construx.com.