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
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.