Wiegers K., Software Development Pearls (2021)

 |  Book Reviews

The book is a collection of lessons from decades of the author's' work in software engineering.

It covers lessons in software requirements, design, quality, project and process management, organization culture and teamwork.

Steve McConnell's foreword to the book says: "Karl is one of the most thoughtful software people I know. He has reflected deeply on the software development irritants he has encountered over his career, and this book contains 60 of his most valuable responses".

Contents

Summary

[Wiegers K.] If you don’t have time to do it right, when will you have time to do it over? Why Not the First Time? (p. 205)

The book is not just a simple set of categorized lessons. Each lesson contains a concise but thorough description of the context it arises from, the problems, and the consequences. It also connects to other relevant lessons. Out of this, the book becomes great learning material—effectively structured and very to the point.

As with many such books, we tend to recognize only the lessons that resonate with our own professional context. For this review, I’ve selected those that align with my experience, that I consider the most valuable, and made a short summary for each.

Do not miss reading the book yourself.

Selected Lessons

# Lesson
Requirements
1 If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project (p. 12)
The accurate requirements are the foundation of any successful software project. Without them, even flawless execution in design, coding, or testing won’t prevent failure—users may reject the system, or costly late-stage fixes may become necessary.
2 Lesson 2 The key deliverables from requirements development are a shared vision and understanding (p. 15)
The true value of requirements development lies in creating shared understanding among stakeholders. A clear vision statement helps align expectations early, preventing costly misalignment between teams. This principle connects fundamentally to getting requirements right, iterative refinement, and effective stakeholder collaboration. Requirements documentation purpose is to capture consensus.
6 Agile requirements aren’t different from other requirements (p. 28)
A developer needs the same information to correctly implement the right functionality no matter what development process the project uses. All projects require the same fundamental requirements activities.
7 The cost of recording knowledge is small compared to the cost of acquiring knowledge (p. 33).
Once documented, the knowledge avoids costly acquisition by by new team members in the future via reverse engineering.
Design
18 It’s cheaper to iterate at higher levels of abstraction (p. 79)
Changing code is times and orders of magnitude more costly (money and time wise) and error-prone depending on how much code has to be changed. It is even more difficult to agree on changes if there is no higher-level system model (design) exists.
Project Management
25 Icebergs are always larger than they first appear (p. 116)
Iterative nature of knowledge acquisition implies requirements to grow times and orders of magnitude as you discover the problem domain. If you don’t anticipate some growth and plan to accommodate it, you’re certain to fall behind plan.
28 Don’t change an estimate based on what the recipient wants to hear (p. 127)
Negotiate to reach some agreement. There’s no justification for altering a thoughtfully crafted estimate just because someone wasn’t pleased with it. We base estimates on what we know about the problem at the time, our previous experiences with similar work, and the assumptions we make. The less we know about all these factors, the less likely it is that the estimate will match the ultimate reality.
Culture and Teamwork
35 No matter how much pressure others exert, never make a commitment you know you can’t fulfill (p. 163)
Unrealistic commitments do not increase the probability of its achievement. It imposes the multiple risks to overrun: team members leave due to excessive pressure, or relax silently due to anyway unachievable terms. False commitments ripple negatively across every member of the entire value chain, from customer, to suppliers, from top managers to employees.
39 It takes little physical separation to inhibit communication and collaboration (p. 173).
The easy informal personal communication is what makes effective and good quality work possible. Asynchronous communication serves as substitute and compliment to the personal communication. Both ways of communication require discipline to let others do their work comfortably uninterrupted and get prepared to wisely use their time.
Quality
43 When it comes to software quality, you can pay now or pay more later (p. 195) (see also my relevant publications on business matters).
The cost of correcting a defect depends on when it was introduced into the product and when someone fixed it. Different sources report cost ranges from 1:1 to >1:1000
45 Organizations never have time to build software right, yet they find the resources to fix it later (p. 205)
Organizations often rush software development, skipping critical quality practices like proper testing and clear requirements to meet deadlines. However, this short-term haste leads to flawed systems that require costly fixes, rework, or even complete overhauls later—defects caught post-release can be 100x more expensive than those addressed early.
49 Software people love tools, but a fool with a tool is an amplified fool (p. 217).
If people don’t understand a technique and know when—and when not—to use it, a tool that lets them do it faster and prettier won’t help.
Process Improvement
56 Good judgment and experience sometimes trump a defined process (p. 244).
Sensible processes, situationally adjusted based on experience, guide teams to repeated success. People need to select, scale, and adapt processes to yield the maximum benefit for each situation. A process is a structure, not a straitjacket.