Steve McConnell Text Banner


New Book Projects 

I'm starting a new book, but I learned from the last book not to make any big promises about book publication schedules! If you're interested in being a reviewer for any of these books (some of which might be several years away), please let me know.

Right now, I'm considering several projects:

Software Executive: A Blueprint for Running a Software Organization. This book is aimed at the top software executive in an organization, typically the VP of Software Development or a similar title. I don't believe anyone so far has clearly articulated the detailed ins and outs of the software executive role. Just as being a good programmer does not quality someone to be a good manager, being a good manager doesn't quality someone to be an effective executive. This book will serve in essence as an annoted job description for the software executive job. Unless something completely unexpected happens, this is the book I'll be working on next.

Rapid Development, Second Edition. Rapid Development is 14 years old now, and it's starting to show its age. Good techniques have come out of the agile movement that I'd like to include in the book (test first programming, product backlogs, pair programming, and some others). Some of the techniques that I described in the first edition are now known more commonly by other names or have become strongly associated with specific families of practice. I need to update the discussion to show some awareness of the common families of practice. 

Software Project Survival Guide: Agile Edition. I'm not very inclined to replace SPSG with a second edition. I think the book stands well on its own even after 10 years. The goal of SPSG was to describe "a good approach to running a project that will work pretty well, most of the time, for most projects." I knew when I wrote SPSG that there were any number of good approaches that could work--conceptually there's no limit to how many SPSG: Web Edition, SPSG: Embedded Software Edition, SPSG: Etc. Editions could be created. As the focus in many programming shops has moved to Agile, and to smaller projects and to shorter release cycles, I think the need for a methodology-agnostic book that focuses on short release cycles and changing requirements would be particularly useful.

Software Estimation: The Science of Estimation. My current estimation book focuses on what I call the art of estimation. It avoids deep math and emphasizes relatively simple practices, which is what I think most estimators want. But there's still room for a book that doesn't shy away from the more mathematically intensive approaches, and it would be interesting to me to publish a companion volume to my first estimation book that shows what you can do when you are willing to roll up your sleeves and tackles a few formulas.

Software Project Tracking: How to know the cost, schedule, quality, and functionality of your project at all times. The Software Engineering Institute has identified software project tracking as perhaps the most common management problem afflicting the software industry. It's not uncommon for managers of major projects to think they're on schedule until the day they're supposed to be released -- then find they need to take a 6 to 12 month schedule slip. This 200 page guide will explain how to attain excellent status visibility from Day 1 to ship day. I've had this book on my personal "to do" list for 10+ years, and I think this might be a case where the software industry has actually made the book irrelevant. Burn down charts on agile projects and earned value on traditional projects are both widespread and both accomplish the objective this book would have addressed.

I'd appreciate any comments you have about whether you find these book ideas interesting, which you find the most timely, and so on.

Email me at