Daniel Berry says:

First, a truth-in-advertising disclaimer:

I was a reviewer paid by the publisher to review the book

prior to its publication. While my position is highly

favorable, I do not regard it as prejudiced or influenced

by the publisher’s payment. It was clearly understood

before I took the job that I could end up disliking the

book and that I was expected to report my opinion whatever

it turned out to be. Therefore, the opinion that I report

here was arrived at in the normal fair manner. I decided

that the book was good after reading it from beginning to

end, starting with a hope that the book would teach me

something. The book taught me plenty and was so well

written that I had difficulty putting the book down.

To give a flavor of the book, I give the table of contents:

Part I Software Development Environments

1 The Nature of Software Engineering (SE)

2 SE Methods (including Spiral Model, Unified Process, AND XP)

3 Working in Teams

4 Software as a Product

Part II The World of SE

5 Code of Ethics of SE

6 International Perspectives on SE

7 Different Perspectives on SE

8 The History of SE

Part III Software-Human Interaction

9 Program Comprehension, Code Inspections, and Refactoring

10 Learning Processes in SE

11 Abstraction and Other Heuristics of Software Development

12 Characteristics of Software and the Human Aspects of SE

Part IV Business Analysis of SE

13 Software Project Estimation and Tracking

14 Software as a Business

15 The Internet and the Human Aspects of SE

Part V SE Education

16 Case Studies in SE

17 Students’ Summary Projects and Presentations

18 Remarks about SE Education

19 Additional Information on Resources used in This Book

I like the coverage of the book. It includes all of the

subjects I would have thought relevant and then some. It’s

a great follow on to what was the first and until now the

ONLY book in the area, Ben Shneiderman’s _Psychology of

Computer Programming_. Moreover, it goes so much farther

than Ben’s book, as it should considering how long ago

Ben’s book was published. I really liked Tomayko and

Hazzan’s inclusion of ethical issues, the international

issues, the discussion of a variety methods from the

programmer’s point of view, the citation of empirical data,

the comparisons to other professions, the history of SE,

and the reflective practices idea.

My own history includes software development experiences,

participations in start ups, participation in the history

of SE, and participation in developing SE education. I

found the chapters on software development teams, software

as a product, international perspectives, the history of

SE, program comprehension and code inspections, software as

a business, and SE education particularly resonating.

The coverage is the correct completeness for a textbook. I

suppose that as a researcher concerned with these issues, I

would like to have seen more depth. However, I can see that

such depth is not appropriate for a text and not

appropriate for a practitioner who wants to just see the

issues and not how the research is carried out and not what

open issues need to be followed up on. However, on the

other side of the coin, their many study questions and

tasks point to this additional depth. Thus the interested

reader can begin to explore them on his own.

Each topic is treated quite thoroughly in that every issue

I can think of about the topics is covered either in their

explanations or in an question that they raise. Of course,

Tomayko and Hazzan do not answer the questions completely

in the book, leaving it to the reader or instructor to have

fun finding the answers.

I love the addition of the tasks for the reader. They got

me thinking. I think they belong where they are, because

then they come up at a time when it is most useful to think

about them. I like the whole approach.

The biggest strength of the book is that it is so engaging

that it is hard to only skim it. One ends up reading it,

and then it is very hard put it down. It is fun to read. It

is informative. It got me to think.

I might add that I simply cannot understand the review of

John Plemme. As one can see even by looking at only the

table of contents, so little of the book is about eXtreme

programming. As a matter of fact, what there is about XP is

not entirely supportive of the idea; it is a careful

discussion of the pros and cons supported by data that the

authors and others have found.

What Mr. Plemme has learned about when programmers are

happy to write documentation and code ownership seem to be

among observations that Tomayko and Hazzan make.

Finally, there is a discussion of the psychology and

sociology of software development teams in Chapter 3.

Did John Plemme read the same book that I did?

Moreover, I happen to know that one of these college

professor authors, namely Tomayko, has over 40 years of

industrial experience developing software, e.g., for a

large aerospace contractor. My view of this book is that

it’s a joint effort in which an education expert, Hazzan,

provides reflection on the hard-knocks experiences of a

software development expert who had become an excellent

software engineering professor.

Rating: 5 / 5