Cultivating Successful Software Development

Rating:
Summary: State of the Art in Software Engineering...
Review: .

...for 1994.

The book is a typical example of the literature available when SEI CMM was the next silver bullet to save our industry from the dreaded "software lottery" that everyone loses (a favorite phrase of the authors).

The authors come from a DoD background and it shows with their selection of methodologies and recommendations. There is a lot of good information in here, but they don't cover many alternative concepts to how DoD builds software. Can you develop good software following this book?

Sure.

On the other hand, the same sort of methodology was used on the FAA AAS project...one of the industry's classic software disaster stories.

Take for example, the authors assertion that the basis for customer input and understanding customer needs (and the resulting project artifacts) is the Statement of Work. Which is technically true for government contracts from a contractural point of view. From an engineering point of view, a better basis of understanding customer desires is a careful analysis of current and desired workflow...on site, watching real users perform the activities that makes their businesses run.

We have a moderately large body of more recent literature that suggests that this is a (much) better method to capture user requirements and expectations than traditional DoD methodology.

There are more examples of this kind of bias but what is most damning about this book are the examples they use. Their discussion on product assurance (pg 39) has an example where product assurance testers find problems with software on the Friday before a delivery and the management "can focus its attention and resources on those areas that must be redone for Monday's release".

Excuse me?

This example is so bad on so many levels that one wonders if this is actually how SAIC does business. Certainly, I would expect that for practitioners in a "mature organization" this sort of example wouldn't even come to mind.

Likewise, the example solution on page 94 on how a CCB might respond to the problem of staff turnover is cross training. Of course this doesn't solve any of the root causes for staff turnover or even the fact that you now have N-1 programmers to do the work of N programmers.

Obviously for authors that blithely accepts that testing occurs the last minute and that programmers should work on weekends this is more than acceptable "solution".

The reason why these kinds of examples are damning is because examples are often better insight into what is actually practiced and internalized by the authors rather than the ideals presented in the book.

Rating:
Summary: My Favorite Reference
Review: .

...for 1994.

The book is a typical example of the literature available when SEI CMM was the next silver bullet to save our industry from the dreaded "software lottery" that everyone loses (a favorite phrase of the authors).

The authors come from a DoD background and it shows with their selection of methodologies and recommendations. There is a lot of good information in here, but they don't cover many alternative concepts to how DoD builds software. Can you develop good software following this book?

Sure.

On the other hand, the same sort of methodology was used on the FAA AAS project...one of the industry's classic software disaster stories.

Take for example, the authors assertion that the basis for customer input and understanding customer needs (and the resulting project artifacts) is the Statement of Work. Which is technically true for government contracts from a contractural point of view. From an engineering point of view, a better basis of understanding customer desires is a careful analysis of current and desired workflow...on site, watching real users perform the activities that makes their businesses run.

We have a moderately large body of more recent literature that suggests that this is a (much) better method to capture user requirements and expectations than traditional DoD methodology.

There are more examples of this kind of bias but what is most damning about this book are the examples they use. Their discussion on product assurance (pg 39) has an example where product assurance testers find problems with software on the Friday before a delivery and the management "can focus its attention and resources on those areas that must be redone for Monday's release".

Excuse me?

This example is so bad on so many levels that one wonders if this is actually how SAIC does business. Certainly, I would expect that for practitioners in a "mature organization" this sort of example wouldn't even come to mind.

Likewise, the example solution on page 94 on how a CCB might respond to the problem of staff turnover is cross training. Of course this doesn't solve any of the root causes for staff turnover or even the fact that you now have N-1 programmers to do the work of N programmers.

Obviously for authors that blithely accepts that testing occurs the last minute and that programmers should work on weekends this is more than acceptable "solution".

The reason why these kinds of examples are damning is because examples are often better insight into what is actually practiced and internalized by the authors rather than the ideals presented in the book.

Rating:
Summary: Too Much in Too Samll a Package.
Review: I think this resource is better for reference purposes than it is for comprehension. The charts, forms, tables, graphics and flowcharts are great, but the reading itself and its presentation, e.g. the font size, need correction or refinement. This book helped me to understand important process, project management, and software engineering concepts, and when combined with other SW Eng resources, such as Pfleeger's SW Engineering (PH, 1998) makes a great resource.

Rating:
Summary: My Favorite Reference
Review: I've just ordered my second copy of this book (to replace one that vanished from my desk - I simply did not want to be without it). As a software development manager with fifteen years experience I find this book very valuable - it is logically laid out and has excellent visuals. I refer to it on a regular basis to help me put my thoughts in order and to jog my memory when I'm planning, documenting, and training.