Channels ▼


Project Management

Greg is a DDJ contributing editor, and can be reached at [email protected] His most recent book is Data Crunching: Solve Everyday Problems Using Java, Python, and More.

Applied Software Project Management
Andrew Stellman and Jennifer Greene
O'Reilly & Associates, 2005
308 pp., $39.95
ISBN 0596009488

Software Project Secrets: Why Software Projects Fail
George Stepanek
Apress, 2005
165 pp., $39.99
ISBN 1590595505

At my partner's request, I finally uninstalled Homeworld (still the best game ever). That left me with lots of time to catch up on my reading, so I plowed through Stellman and Greene's Applied Software Project Management and Stepanek's Why Software Projects Fail back to back. They made an interesting pair, and the differences between their authors' positions say a lot about where the software industry is today.

Stellman and Greene's book is the more conventional of the two. Their aim is to put everything you need to know to run a small-to-medium-sized software project between two covers. After a short introduction, which lays out the principles they believe successful managers should follow, the book is divided into two parts. The first, "Tools and Techniques," includes all the usual suspects: planning, estimation, schedules, reviews, requirements, design and programming, and testing. While their language is sometimes a little highfalutin' ("Wideband Delphi estimates," anyone?), the advice is all solidly grounded and eminently practical. It's all been said before, but as covers go, this is as good as The Clash's version of "I Fought the Law."

The book's second half is about the act of management. Its chapter titles tell the story: "Understanding Change," "Management and Leadership," "Managing an Outsourced Project," and "Process Improvement." In my experience, these topics are nearly impossible to teach in book form: The only way to learn them is to have someone coach you while you're doing them. That said, Stellman and Greene do as good a job as anyone, while thankfully avoiding anything that smells of Tony Robbins. It's a solid book, well researched, and definitely worth reading.

Stepanek's Software Project Secrets is a marked contrast. The tag line on the front cover is, "Resolving the conflicts between software development and project management," and it's clear from page one that the author (a) has been caught in this particular vise more than once, and (b) really wants to find a better way to do things. Drawing on both his personal experience and the published literature, Stepanek gives 12 reasons why software is different. Some of them are inarguable: Software is complex and abstract, and construction is design.

But then there's: "Requirements are incomplete." Stepanek treats this as being intrinsic to software development, when in fact, it is merely common (bad) practice. His own point number 11, "Change is considered easy," is the reason, but shifting sands are no more inescapable in software than they are in civil engineering. "What happens if the scope can't be completely defined?" he asks, as if it were any easier or more natural for architects to get specs from their clients than it is for programmers.

Similarly, while Stepanek refers to many of the classic works in software engineering, he seems to have missed most of what's appeared in the primary literature in the last 10 years. New journals such as Empirical Software Engineering have both reflected, and encouraged, new studies of what actually works and doesn't—studies that are methodologically sounder than many of their predecessors—and I think they ought to be required reading for anyone writing about software engineering today. I share Stepanek's sense of frustration, but think that software engineering isn't as special as it is often convenient for software engineers to believe.

DDJ Recent Top 5 Programming Books

  1. Microsoft Office Project 2003 Step by Step
    Carl Chatfield
  2. HTML for the World Wide Web with XHTML and CSS: Visual QuickStart Guide, Fifth Edition
    Elizabeth Castro
  3. The Pragmatic Programmer: From Journeyman to Master
    Andrew Hunt and David Thomas
  4. Head First Servlets and JSP: Passing the Sun Certified Web Component Developer Exam (SCWCD)
    Bryan Basham
  5. Excel 2003 Power Programming with VBA
    John Walkenbach

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.