It is hard to find a successful path between this book’s title topics, the gee-whiz of technology transition and the ho-hum of software engineering. I did not expect to like this book when I started to read it, but I was soon converted.

Utz takes us on a journey from crafted software through tooled software to engineered software. He then takes us beyond, to what he calls “automated engineered” software and finally “automated intelligent engineered” software.

During this journey, he maintains a careful balance between theory and practice. He presents object-oriented approaches as a worthy technology, but tempers that with a pragmatic list of “problems to be solved” in their use. He favors moving the field forward, but suggests transferring largely those technologies that lie “at the leading edge of proven practice.” He speaks of automated approaches, but says “software design and specification have always been, are now, and will always be a human activity … technology transfer is simply automating the routine part of the process.”

What does Utz believe? He believes that the technology transfer process requires a formal, planned approach, through an assigned manager and a “software advancement team” (SWAT); that the passage from crafted to engineered software is necessary, even inevitable; that the transitions in that passage should occur when we can no longer answer the question, “Is this project technically manageable?” (and, thus, that project size and scope should drive the transitions); and that the presence and use of a methodology is an essential prelude to most other technology change.

As with any book, some oddments appear. On page 128, we see that we should “minimize or eliminate inspections” because engineering software will allow us to “do it right the first time.” But later, on pages 214, 260, and (to a lesser extent) 133, we see inspections as an important element of software engineering. Writing for an audience of “software developers, students, and hardware engineers” (that combination in itself is an oddment), Utz uses a hardware analogy to discuss and explain software testing. He takes the position early in the book that “software engineering requires a completely new methodology,” goes on to add, “although a complete methodology has not emerged,” and never draws any closer to that goal.

Still, those problems are minor. If you are interested in software, this book is a possible choice, but if you are trying to facilitate change in software, it is a must.