Part One, "Software Development in an Imperfect World", forwards the author's hypothesis that the corporate world and its inhabitants are not only hostile to developers and their projects, but that they actively and perniciously seek to undermine them. Chapter Two's title, "Business is War. Meet the Enemy.", is a good example of the tone of this section.
Duncan says repeatedly that management arbitrarily sets deadlines: "Exactly what is an unrealistic deadline? Simply put, it's a no-win scenario in which the game is lost before it's even begun because the software cannot possibly be developed, tested, and delivered in the allotted time." He's right as far as he goes, but he portrays the developer as an innocent victim. I disagree. Most developers and development groups are active participants in their own demise. To his credit, he also mentions "The Enemy Within" as a source of problems. The overriding theme is that management capriciously and even maliciously lords over developers who are "at the bottom of the food chain". This oversimplifies the real cultural and communication problems between an itinerant artists' colony (developers) that wants to write cool code and the controlling faction (business people) that wants to accumulate wealth. Negatively labelling and stereotyping management for a differing world view (as Duncan repeatedly does) will not help this situation.
In Part Two, "Guerilla Tactics for Front Line Programmers", Duncan sets out to provide real world techniques that will make developers' jobs more gratifying and also make company management happier with better-managed projects and higher-quality product releases. With Chapters such as "Preventing Arbitrary Deadlines" and "Getting Your Requirements Etched in Stone", he presents some solid project management theory in a very understandable way.
His advice falters in chapter Six when he suggests that development teams "Roll Your Own Design Methodology". This is a potential time-wasting disaster. A group of developers arguing design methodologies is not a sensible way to make the design phase shorter and more productive. Quite the opposite is much more likely. It would be better to pick a simple set of symbols, agree on their meaning, and be done with it. This is one place where management can help by setting a standard for everyone.
None of this is new material, but it is presented in a condensed form which won't satisfy the needs of Project Managers but could be useful as an overview for developers and business people. Anyone expecting "Guerilla Tactics" as promised in the title will be sorely disappointed. This is a collection of solid technical project management techniques.
Simply put, I despise war analogies, and they are heaped on throughout this book. Chapter Two's title is a good example. Business isn't war. War is war. Likening an unpleasant corporate meeting to "storming a machine gun nest" is inappropriate. The constant war analogies are sophomoric and detract from the book's overall message. The author has a pleasant, approachable, intimate style that is nearly ruined by this. It was probably cute when the author was drawing planes and bombs in seventh grade. It's not cute any more. Let it go.
Another annoyance is that the Table of Contents is shown "At a Glance", then separately presented in the expected format, then again in a summarized form. This all takes place in the space of a twenty-page introduction. I was wondering if I was expected read it three times and to forget it twice within twenty pages! This makes one wonder if the author was required to hit 200 pages and needed three Tables of Contents to do so.
From Chapter One, "Welcome to Corporate America": "We truly care about the quality and content of our work. We are artists, idealists, and inspired creators. We are also quite logical. None of this meshes very well with the typical corporate environment in which more time is spent on political maneuvering and career enhancement than producing something valuable."
The book's premise can be reduced to:
"Coding Bliss" is a developer's desired state.
Bad management interferes with "Coding Bliss".
Fix management, and one can return to "Coding Bliss".
This is a breathtakingly naive view of business in general and the software business in particular. It's also incredibly egocentric, and a dimly myopic view of the business world. Businesses exist to make money, not happiness and certainly not "Coding Bliss". And while the above reductive analysis is logical, it's not sensible. However, it is valuable in that it accurately depicts the thought process many developers bring to work every day.
Because it accurately depicts the typical developer thought process, this book would be most valuable to the very people it derides and sets out to alienate by labelling them "The Enemy": Project Managers, Technical Managers, and business people in general. Any business person who is depending on technical "talent" to produce something valuable would benefit from keeping in mind the developer duality of naivete coupled with highly structured and logical thought. While useful for being creatively technical, this duality makes for extremely difficult-to-manage individuals.
Duncan admits his view is paranoid and that he emphasizes the bizarre aspects of the business world in order to make a point: "I realize I often paint a picture of Corporate America as a place in which common sense is never a priority and people are always scheming, unreasonable, or just plain hard to work with." If this is your world view or you are tasked with managing people who have this world view, this book is for you.