On the very first page of chapter 1, Gleeson provides a callout with the simple but profound observation: “Building software is nothing like building a house.” Software development is a tricky process for many reasons, but the best way to irrevocably get off on the wrong foot is to fail to acknowledge and respect this statement. Thinking that building software is like building a house is a profound mistake like thinking you can change somebody’s political views with your fists. Not only is it profoundly incorrect; it is almost impossible to recover from. Why is this the case? A dozen metaphors and analogies come to mind involving investments, raising a baby, lighting a charcoal grill, putting up a circus tent, and so on. But none of them are adequate. This problem is further exacerbated by the fact that many professional project managers believe, incorrectly, that the techniques used to build a bridge or a nuclear power plant can be applied with only minor adjustments to software development. Such confident practitioners cannot be convinced otherwise until they have personally experienced a massive failure brought on by their naiveté. Chapter 2 attempts to explain why “building software is nothing like building a house” and does a reasonably good job. But, I already agree with this statement. I am not sure if a naïve skeptic would be convinced.

Chapter 3 introduces agile development (the author amusingly and insightfully spells it (fr)agile). Agile views software development as a learning process rather than a production process, where the team works in short bursts of development activity, followed by assessment and course corrections. Agile development is extremely popular today and is a vast improvement over previous software development models. To be fair, I should point out that agile is not the solution to every software development challenge. For example, if you are installing a payroll processing system for the 100th time, or undertaking a massive software engineering task such as developing a new operating system, then agile might not be the first choice. But the vast majority of software developed today is characterized by people doing something they haven’t done before with technology they haven’t used before for users who cannot imagine what the results will look like. And for that, a learning system like agile fills the bill. The author missed an opportunity in this chapter for another callout, which might say something like “Effective software development can be learned but cannot be taught.” That philosophy is ingrained in the agile approach and is the philosophy underlying this book. You can’t really explain to someone how to develop software using the agile approach, but you can prepare him for the learning that will occur as he undertakes a task in this way.

The book begins and ends with project management issues. For example, the last chapter, “When It All Goes Wrong,” addresses a few (but certainly not all) worst-case scenarios. However, intertwined with the project management chapters are several chapters that would best be described as programmer management. This is equally as mystifying as software project management and is best thought of as a learning process as well. These chapters address recruiting and understanding this very different kind of employee. One chapter is called “What Do They Do All Day?” Others address those funny words they use and the odd things that they seem to care about. Understanding programmers is vital to successful software development, and these chapters provide some useful points of reference.

Software project management and successful management of programmers are both skills that cannot be learned from a book. They are skills that must be learned from experience. However, the topics provided in this book will provide the aspiring manager with some things to think about that will greatly accelerate the learning process. This book is unique and worthwhile to anyone who is involved in managing software development. It is easy to read and full of insights. It could serve as a backup book for a course in software project management. Readers would still need something that covers PERT charts, lifecycle, and methodologies, which are, as they say, necessary but not sufficient. Anyone involved in the software development process might be interested in this book. It is one of those odd, folksy, almost mystical books, with many stories, where you don’t feel like you are really learning that much until later when events occur and bits of the book come back to mind.

More reviews about this item: Amazon, Goodreads