It's an old joke among programmers that questions of the efficacy of programming languages, abstraction models, management models, or other fundamental ideas of software engineering are simply "religious wars" -- i.e. conflicts impossible to resolve, because they are based on faith and superstition rather than any kind of objective evidence. And yet, a lot of important decisions are based on these ideas. So it's refreshing to see a book that attempts to apply real scientific rigor to the questions of programming and software engineering, and that's what "Making Software" gives us.

I found it very interesting to see popular ideas that I had picked up from forums which had previously been justified with little more than "hand waving" arguments, put to the test

I found the book fascinating largely because of my background in science, and my interest in the philosophical problems in the first few chapters on how to ask the questions in a quantifiable and objective way.

I also found it very interesting to see popular ideas that I had picked up from forums which had previously been justified with little more than "hand waving" arguments, put to the test. In some cases, the conventional wisdom was supported, while in others it was refuted. It's a complex subject, so I'm hesitant to think of even these objective tests as the last word on the subject, but much of the evidence is compelling, and it makes an interesting read.

The contents

The chapters of the book are papers submitted by different authors, making this a bit like a conference proceedings in structure. You're unlikely to read this book straight through. It's more of a reference collection.

The first several chapters of this book (comprising "Part I") are not about programming itself, but about the meta-question: "What kind of objective methodology can we use to evaluate questions about software?" It's a tough question: is software engineering more like "engineering", "sociology", "physical sciences", "medicine", or "biology"? It has aspects of all of them, and so determining what framework to use in asking and answering questions about it is not easy. In the end, several methods are identified that may be of use, and it's possible to recognize their impact in the later chapters of the book.

After this, in "Part II", the papers approach a number of common questions and ideas about modern programming. A few of the interesting topics addressed include: "Pair Programming" (how effective is it?), "Conway's Law" (Is it really true, and can we measure it?), "Women in Computer Science" (examined from a variety of perspectives), and "Modularization" (How much does it really help?).

Who’s this book for?

This book is at a fairly academic level, so it may be mostly of interest to students of computer science. But there is material here of real value to an ambitious software engineering manager who wants more solid evidence to back up management strategies.

Relevance to free software

For the most part, this book is agnostic with respect to free or proprietary software licensing and development models. A couple of chapters directly address the issue, most notably "Quality Wars: Open Source Versus Proprietary Software". Most of the articles would apply equally to either, though.

For the most part, this book is agnostic with respect to free or proprietary software licensing and development models

Pros

Scientific rigor -- or at least the attempt at it, is the main focus here. Some commonly-held ideas are debunked, and some are confirmed. Most of the time, the evidence is quite compelling.

Cons

In terms of practical management advice, this book may be lacking, because it's just too academic. It would take a fairly large amount of mental effort to get from here to practical recommendations. Don't buy it if you are looking for a simple "how to" book!