How Software Is Built tackles the first requirement for developing Quality Software (the name of this series of books): learning to think correctly about problems, solutions, and quality itself. The book sets out guidelines that stimulate the kind of thinking needed.

Topics include a discussion of quality, software cultures, patterns of quality, patterns of management, feedback effects, the size/complexity dynamic in software engineering, the role of customers, and how to diagram causes and effects.

The book contains chapter summaries and many invaluable diagrams, as well as exercises, to bring home its lessons. 

Here's a few of many five-star reviews:

"Weinberg addresses more clearly the form and essence of quality that we software people worry about... I can't imagine a better way to help change the thinking process in your organization than the wide-scale distribution of Jerry Weinberg's wonderful book." - Ed Yourdon, American Programmer

"I like Jerry Weinberg. He's a lunatic: I like that in a person. He writes from a technical and psychological perspective, describing how to think about what you do. . . . This series is one of my favorites." - Ron Jeffries, xprogramming.com

"The notation is so elegant that it takes almost no effort to learn and use it. The diagrams are simple and easy to understand and used in such a consistent manner that one has to wonder why this notation is not in widespread use. I hope it will be. . . ." —Software Quality World

"A must book for every software development manager." —C.C. Dilloway Computer Books Review

". . . very highly recommended!"  —New Book Bulletin

"With the current frenzy for Total Quality Management, ISO 9000, and Baldrige Awards dominating the industry, it's refreshing to have someone as down-to-earth as Weinberg focusing on the need for high-quality management as a necessary prerequisite for high-quality software. . . . [a] people-oriented approach to quality."  —Warren Keuffel. Computer Language

"This is one of those landmark books that comes along at the right time and addresses the right set of issues. . . . what makes this book unique and invaluable is the organization and presentation of the material. This is a book every software development manager should study." —Shel Siegel. CASE Trends

Lyndon Vrooman wrote what many readers have said about the effect "Why Software Gets In Trouble" had on him: "I'll be honest, about half way through this book, I thought that I found it rather bland and full of things that I was already doing. This changed however as I was assessing an application that I had been working with for years and we had found some critical faults in. I started thinking more about the book and the contents of it. After re-reading it, I realized that I hadn't been looking closely enough for faults, only going just beneath the skin. As I started to apply more and more of the information within, I began to realize more and more of what I had been learning was adding tremendously to the quality of the product. In short, after thinking more and more about this book, it's quickly gone to one that I recommend to everyone that I work with."

Another reviewer, Joe Strazzerel recounted the contents: "Jerry describes many of the ways errors occur, the correct way of thinking about errors (such as "Errors are not a moral issue" and "Quality is not the same thing as absence of errors"), how companies and processes get into a state where errors are more likely to occur (increased pressure, high levels of stress, poor estimation, lack of control, etc), and the effects of breakdowns."

"This book is fairly short, yet surprisingly thorough over its seven chapters:Chapter 1: Observing and Reasoning About ErrorsChapter 2: The Failure Detection CurveChapter 3: Locating The Faults Behind The FailuresChapter 4: Fault Resolution DynamicsChapter 5: Power, Pressure, and PerformanceChapter 6: Handling Breakdown PressureChapter 7: What We've Managed To Accomplish""For me, this was a very timely book. My team is going through some of the same pressure patterns Jerry writes about. For virtually every point made, I found myself saying 'I remember when that happened,' and sometimes 'That's happening right now!'""If you are a Software Testing professional, you should read this book. You should then give a copy to your manager, and to your manager's boss. Then, be prepared to discuss with them the realities of software development from a tester's point of view. After reading 'Why Software Gets In Trouble." you'll almost certainly have a more enlightened (and hopefully more receptive) audience."

And Don Gray wrapped up by adding in his review with a case example from one of his clients: "After three quarterly 'successful' releases a company had 453 defects opened in a single day against the 'successful' releases."

"Many books exist for any given programming language. Every developer had two or three at their desk. One book on software engineering may exist for every 100 language books. Maybe not. I noticed one developer had one.""453 defects don’t suddenly happen. Something in the process and culture allowed them to build until they could no longer be ignored. It seems to me someone at the company might benefit from learning about system dynamics and the reasons behind software errors.""Why Software Gets in Trouble is the only book I know of that explores the systemic dynamics and reasons behind software errors. Using stories, graphs and Diagrams of Effects, this book explores how different software cultures:   * notice and think about errors   * detect failures   * locate the faults behind the errors   * resolve faults   * apply and handle pressure"The content applies to both managers and developers. If you’ve wondered why you keep experiencing the same patterns concerning shipping software, this book will help you understand why.""NOTE: If you’ve not read How Software is Built, you might find reading Why Software Gets in Trouble's appendices on Diagrams of Effects and Software Engineering Cultural Patterns helpful prior to starting the main text."

To consistently produce high-quality software in today's competitive marketplace, managers must have reliable information, obtained through careful observation and measurement. How to Observe Software Systems is a comprehensive guide to the basic measurement activities every organization must perform to manage the software development process.

Many management failures are caused by poor observation. First-Order Measurement tells how to observe properly with the aid of a four-step model to break the complex observation process into a series of smaller, simpler, steps. The book also defines the different levels of measurement, and describes the minimum set of activities in order to start a measurement program.

Numerous examples and diagrams illustrate the author's points, and exercises challenge readers to test their understanding of the concepts. Topics include

• why observation is important

• selecting what to observe

• visualizing the product

• visualizing the process

• pitfalls when making meaning from observations

• the direct observation of quality

• comparison of cost and value

• meta-measurement

This stand-alone text is the third in a series of volumes in which acclaimed author Gerald Weinberg explores the most difficult aspects of building high-quality software.

A Sticky Minds reviewer wrote: "This book focuses on an issue of huge importance to software managers: how to respond appropriately to people (clients, bosses, team members) in difficult, emotionally charged situations."

"The author uses simple but effective models to explain human behavior. He includes examples from the software engineering industry to put these models in contexts familiar to software developers. The models can help all software professionals to understand and deal with conflicts more effectively, using the insights gained from this book every day with software development teams, clients, employees, and personal interactions."

"As the author has pointed out, one of the main questions in software engineering is 'Why do people so often do things wrong when they know how to do them right?' As this book shows, to do the right thing often requires that in a moment of confrontation, you must interact with all points of view, with the needs and fears and personalities of all parties to the issue. The insights, examples, and tools Weinberg provides here can help you become much more effective in working with others. I strongly recommend this book, and the rest of the set, to people who lead software projects and lead project managers themselves."

Reviewer Keith Collyer wrote that he "didn't see how anyone can consider themselves interested in software quality without having some of Gerald Weinberg's books on their shelves (preferably well-thumbed). While I don't always agree with everything that Weinberg says, he does force you to THINK. My only real quibble is that the title of the series limits the perceived coverage to software. In my opinion, the material in these books is applicable in any development activity."

Reviewer Stuart M Scott wrote: Weinberg uses simple but effective models to explain human behavior, and examples from the software engineering industry to put these models in contexts familiar to software developers. I first read this book several years ago, and as a professional facilitator had immediate opportunities to evaluate my own ability to behave congruently under stress. I quickly found that Weinberg's models helped me to understand and deal with conflicts more and more effectively.

Today I use the insights gained from this book every day in my work with software development teams, clients, employees, and my own family. As Weinberg has pointed out, one of the main questions in software engineering (and perhaps in life) is Why do people so often do things wrong when they know how to do them right? As this book shows, to do the right thing often requires that in a moment a conflict or confrontation you behave congruently with all points of view, with the needs and fears and personalities of all parties to the issue.

The insights, examples, and tools Weinberg provides here can help you become vastly more effective in working with others. I strongly recommend this book, and the rest of the Quality Software Series, to people who lead software projects.

Becoming an effective manager of teams is the subject of this sixth volume in Gerald M. Weinberg's highly acclaimed series, Quality Software.

To be effective, team managers must act congruently. These managers must not only understand the concepts of good software engineering and effective teamwork, but also translate them into their own practices. Effective managers need to know what to do, say what they will do, and act accordingly. Their thoughts and feelings need to match their words and behaviors.

Congruence has the sense of "fitting" —in this case, simultaneously fitting your own needs, the needs of the other people involved, and the contextual, or business, needs. Managers themselves must take responsibility for improving the quality of management and for changing their own attitudes and thinking patterns before they attempt to impose changes on everyone else.

As the author advises, "If you cannot manage yourself, you have no business trying to manage others." This book offers practical advice on how to act, and how to manage others congruently. Examples, diagrams, models, practice suggestions, and tools s fortify the author's recommendations.

Topics include:

• Achieving Congruent Management

• Curing the Addiction to Incongruence

• Ending the Placating Addiction

•  Ending the Blaming Addiction

• Engaging the Other

• Reframing the Context

• Informative Feedback

• Managing the Team Context

• Why Teams?

• Growing Teams

• Managing in a Team Environment

• Starting and Ending Teams

• The Diagram of Effects

• The Software Engineering Cultural Patterns

• The Satir Interaction Model

•  Control Models

• The Three Observer Positions

In Volume 7 of the highly acclaimed Quality Software series, Gerald M. Weinberg illustrates how skilled people (Change Artists) work to create a supportive environment for software engineering —an environment in which your organization can realize long-lasting gains in quality and productivity by learning the artistry of managing change.

As the author argues, the history of software engineering is riddled with failed attempts to improve quality and productivity without first creating a supportive environment. Many managers spend their money on tools, methodologies, outsourcing, training, and application packages, but they rarely spend anything to improve or to remove the leaders who created those situations in the first place.

From systems thinking to project management to technology transfer to the interaction of culture and process, Becoming a Change Artist analyzes models of how change really happens, and how change artistry creates the environment for all other changes.

Gerald M. Weinberg illustrates how to create a supportive environment for software engineering —an environment in which your organization can realize long-lasting gains in quality and productivity by learning how to manage change.

As the author argues, the history of software engineering is riddled with failed attempts to improve quality and productivity without first creating a supportive environment. Many managers spend their money on tools, methodologies, outsourcing, training, and application packages, but they rarely spend anything to improve or to remove the management that created those situations in the first place.

From systems thinking to project management to technology transfer to the interaction of culture and process, this volume analyzes transformation from a broad range of perspectives, providing a breadth of awareness essential for successful management of high-quality software development.

Topics include:

Meta-Planning: Information

Meta-Planning: Systems Thinking

Tactical Change Planning

Planning Like a Software Engineer

What Changes Have to Happen

Components of Stable Software Engineering

Process Principles

Culture and Process

Improving Process

Requirements Principles and Process

Changing the Requirements Process

The book also had five important appendices:

Appendix A: The Diagram of Effects

Appendix B: The Software Engineering Cultural Patterns

Appendix C. The Satir Interaction Model

Appendix D. Control Models

Appendix E. The Three Observer Positions

Change Done Well is the ninth volume in the highly acclaimed Quality Software series. In it, renowned author, Gerald M. Weinberg, illustrates how to create a supportive environment for improving software engineering —an environment in which your organization can realize long-lasting gains in quality and productivity by learning how to manage change.

The history of software engineering is riddled with failed attempts to improve quality and productivity without first creating a supportive environment. Many managers spend their money on tools, methodologies, outsourcing, training, and application packages, but these managers rarely spend anything to improve the way in which these hoped-for improvements are adopted and used correctly.

From systems thinking to project management to technology transfer to the interaction of culture and process, Change Done Well analyzes transformation from a broad range of perspectives, providing a breadth of awareness essential for successful transformation to high-quality software creation.

Topics include:

• Starting Projects Correctly

• Sustaining Projects Correctly

• Terminating Projects Properly

• Building Faster By Building Smaller

• Protecting Information Assets

• Managing Design

• Introducing Technology

• The Diagram of Effects

• The Software Engineering Cultural Patterns

• The Satir Interaction Model

• Control Models

• The Three Observer Positions

• and much more

Freshman Murders is a "Nerder Mystery," which means that the detectives who solve these crimes are nerds–brilliant individuals whose social skills may not equal their skills in mathematics, computers, and science.

On the terrified campus of Hurlesburg U., Mathematics Professor and former NSA problem-solver Josh Rosemont, finds a young woman’s body in the woods. He is paralyzed by her resemblance to his murdered daughter. As the murders continue, he is enraged into action by an obstructive Dean. Teaming with his cop-turned-anthropologist wife, Carmela, and his four genius grad students, he sets out to prevent another murder.

Blending every skill and trick of their professions, Rosy's team hounds a twisted trail of false clues to uncloak the Dean’s sex scandal, decipher incriminating evidence in a billion-dollar swindle, and thwart the serial killer–a deranged student who believes raping and killing a potential suicide is not really murder.

But did they catch the real killer?

Jerry Weinberg has been called "the grandfather of Agile Programming." Like all grandfathers, he watches his descendants with close interest and tries to help them succeed in life. In this book, Jerry offers us his grandfatherly observations and advice for those readers who want to grow up to be successful Agilists.

Inside, he describes some of the history leading up to Agile and looks at the strenghts and weaknesses of the key Agile principles. He's looking foward to evolving his impressions by using the feedback from active Agile readers.

If you're using Agile, or thinking about using Agile in the future, Agile Impressions will give you much of the background you need to be successful.