Accelerate Your Pursuit of Software Excellence by Learning from Others' Hard-Won Experience
"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."
-- From the Foreword by Steve McConnell, Construx Software and author of Code Complete "Wouldn't it be great to gain a lifetime's experience without having to pay for the inevitable errors of your own experience? Karl Wiegers is well versed in the best techniques of business analysis, software engineering, and project management. You'll gain concise but important insights into how to recover from setbacks as well as how to avoid them in the first place."
--Meilir Page-Jones, Senior Business Analyst, Wayland Systems Inc.
Experience is a powerful teacher, but it's also slow and painful. You can't afford to make every mistake yourself! Software Development Pearls helps you improve faster and bypass much of the pain by learning from others who already climbed the learning curves. Drawing on 25+ years helping software teams succeed, Karl Wiegers has crystallized 60 concise, practical lessons for all your projects, regardless of your role, industry, technology, or methodology.
Wiegers's insights and specific recommendations cover six crucial elements of success: requirements, design, project management, culture and teamwork, quality, and process improvement. For each, Wiegers offers First Steps for reflecting on your own experiences before you start; detailed Lessons with core insights, real case studies, and actionable solutions; and Next Steps for planning adoption in your project, team, or organization. This is knowledge you weren't taught in college or boot camp. It can boost your performance as a developer, business analyst, quality professional, or manager.
- Clarify requirements to gain a shared vision and understanding of your real problem
- Create robust designs that implement the right functionality and quality attributes and can evolve
- Anticipate and avoid ubiquitous project management pitfalls
- Grow a culture in which behaviors actually align with what people claim to value
- Plan realistically for quality and build it in from the outset
- Use process improvement to achieve desired business results, not as an end in itself
- Choose your next steps to get full value from all these lessons
Register your book for convenient access to downloads, updates, and/or corrections as they become available. See inside book for details.
Author(s): Karl Wiegers
Edition: 1
Publisher: Addison-Wesley
Year: 2021
Language: English
Pages: 330
Tags: Software Development; Software Engineering; Software Methodology
Foreword
Acknowledgments
About the Author
Chapter 1: Learning from Painful Experience
My Perspective
About the Book
A Note on Terminology
Your Opportunity
Chapter 2: Lessons About Requirements
Introduction to Requirements
Many Types of Requirements
Subdomains of Requirements Engineering
The Business Analyst Role
Requirements Are Foundational
First Steps: Requirements
Lesson 1: Get the requirements right or the project will fail
The Right Requirements—But When?
The Right Requirements—But How?
Lesson 2: Requirements development delivers shared understanding
Lesson 3: Stakeholder interests intersect at the requirements
Stakeholder Analysis
Who Makes the Call?
We’re All on the Same Side Here
Lesson 4: Favor a usage-centric approach to requirements
Why the Excess Functionality?
Putting Usage First
A User Story Concern
Usage Rules!
Lesson 5: Requirements development demands iteration
Progressive Refinement of Detail
Emergent Functional Requirements
Emergent Nonfunctional Requirements
Lesson 6: Agile requirements aren’t different from other requirements
Roles and Responsibilities
Terminology
Documentation Detail
Activity Timing
Deliverable Forms
When to Prioritize
Is There Really a Difference?
Lesson 7: Recording knowledge is cheaper than acquiring it
Fear of Writing
Benefits of Written Communication
A Sensible Balance
Lesson 8: Requirements are about clear communication
Multiple Audiences, Multiple Needs
Choosing Representation Techniques
Can We Talk?
Lesson 9: Requirements quality is in the eye of the beholder
Many Requirements Beholders
Requirements Quality Checklist
Lesson 10: Requirements must be good enough to reduce risk
Dimensions of Detail
How Much Is Enough?
Lesson 11: People don’t simply gather requirements
Gathering versus Elicitation
When to Elicit Requirements
The Elicitation Context
Elicitation Techniques
Laying the Foundation
Lesson 12: Elicitation brings the customer’s voice to the developer
Communication Pathways
Product Champions
Other Requirements Communication Pathways
Bridging the Gap
Lesson 13: Telepathy and clairvoyance don’t work
Guess That Requirement!
Being Explicit
Telepathy Fails
Lesson 14: Large groups have difficulty agreeing on requirements
Pay Attention!
Facilitator to the Rescue
Focus, Focus, Focus
Reaching Outside the Group
Lesson 15: Avoid decibel prioritization
Prioritization Techniques
Prioritization Criteria
Analysis over Volume
Lesson 16: Define scope to know whether your scope is creeping
The Specter of Scope Creep
How to Document Scope
Is It in Scope?
Fuzzy Requirements = Fuzzy Scope
Next Steps: Requirements
Chapter 3: Lessons About Design
Introduction to Design
Different Aspects of Design
Do You Have a Good Design?
First Steps: Design
Lesson 17: Design demands iteration
The Power of Prototypes
Proofs of Concept
Mock-ups
Lesson 18: It’s cheaper to iterate at higher levels of abstraction
Stepping Back from the Details
Rapid Visual Iteration
Iteration Made Easy
Lesson 19: Make products easy to use correctly, hard to use incorrectly
Make It Impossible for the User to Make a Mistake
Make It Difficult for the User to Make a Mistake
Make It Easy to Recover from an Error
Just Let It Happen
Lesson 20: You can’t optimize all desirable quality attributes
Dimensions of Quality
Specifying Quality Attributes
Designing for Quality
Architecture and Quality Attributes
Lesson 21: An ounce of design is worth a pound of recoding
Technical Debt and Refactoring
Architectural Shortcomings
Lesson 22: Many system problems take place at interfaces
Technical Interface Issues
Input Data Validation
User Interface Issues
Interface Wars
Next Steps: Design
Chapter 4: Lessons About Project Management
Introduction to Project Management
People Management
Requirements Management
Expectation Management
Task Management
Commitment Management
Risk Management
Communication Management
Change Management
Resource Management
Dependency Management
Contract Management
Supplier Management
Managing Away the Barriers
First Steps: Project Management
Lesson 23: Work plans must account for friction
Task Switching and Flow
Effective Hours
Other Sources of Project Friction
Planning Implications
Lesson 24: Don’t give anyone an estimate off the top of your head
Hasty Predictions
Fear of Fuzz
Lesson 25: Icebergs are always larger than they first appear
Contingency Buffers
Risky Assumptions
Contracting on Icebergs
The Beauty of Buffers
Lesson 26: Data strengthens your negotiating position
Where Did You Get That Number?
Principled Negotiation
Lesson 27: Use historical data to improve estimates
Multiple Sources of Historical Data
Software Metrics
Lesson 28: Don’t change an estimate just to make someone happy
Goals versus Estimates
When to Adjust
Lesson 29: Stay off the critical path
Critical Path Defined
Keeping Out of the Way
Lesson 30: Incomplete tasks get no partial credit
What Does “Done” Mean?
No Partial Credit
Tracking by Requirements Status
Doneness Leads to Value
Lesson 31: A project team needs flexibility to adapt to change
Five Project Dimensions
Negotiating Priorities
The Flexibility Diagram
Applying the Five Dimensions
Lesson 32: Uncontrolled project risks will control you
What Is Risk Management?
Identifying Software Risks
Risk Management Activities
There’s Always Something to Worry About
Lesson 33: The customer is not always right
Being “Not Right”
Respecting the Point
Lesson 34: We do too much pretending in software
Living in Fantasyland
Irrational Exuberance
Games People Play
Next Steps: Project Management
Chapter 5: Lessons About Culture and Teamwork
Introduction to Culture and Teamwork
Keeping the Faith
Cultural Congruence
Crystallizing the Culture
Growing the Group
First Steps: Culture and Teamwork
Lesson 35: Knowledge is not zero-sum
The Knowledge Hog
Rectifying Ignorance
Scaling Up Knowledge Transfer
A Healthy Information Culture
Lesson 36: Don’t make commitments you know you can’t fulfill
Promises, Promises
Life Happens
Lesson 37: Higher productivity requires training and better practices
What’s the Problem?
Some Possible Solutions
Tools and Training
Individual Developer Variation
Lesson 38: The flip side of every right is a responsibility
Some Customer Rights and Responsibilities
Some Developer Rights and Responsibilities
Some Project Manager or Sponsor Rights and Responsibilities
Some Autonomous Team Rights and Responsibilities
Concerns before Crises
Lesson 39: Surprisingly little separation can inhibit communication
Barriers of Space and Time
Virtual Teams: The Ultimate in Separation
A Door, a Door, My Kingdom for a Door!
Lesson 40: Small-team approaches don’t scale to large projects
Processes and Tools
The Need for Specialization
Communication Clashes
Lesson 41: Address culture change during a change initiative
Values, Behaviors, and Practices
Agile and Culture Change
Internalization
Lesson 42: Engineering techniques don’t work with unreasonable people
Try a Little Teaching
Who’s Out of Line Here?
In Favor of Flexibility
Next Steps: Culture and Teamwork
Chapter 6: Lessons About Quality
Introduction to Quality
Definitions of Quality
Planning for Quality
Multiple Views of Quality
Building Quality In
First Steps: Quality
Lesson 43: Pay for quality now or pay more later
The Cost-of-Repair Growth Curve
Harder to Find
Early Quality Actions
Lesson 44: High quality naturally leads to higher productivity
A Tale of Two Projects
The Scourge of Rework
The Cost of Quality
Lesson 45: Organizations somehow find time to fix bad software
Why Not the First Time?
The $100 Million Syndrome
Striking the Balance
Lesson 46: Beware the crap gap
The Crap Gap Illustrated
Crap-Gap Scenarios in Software
Lesson 47: Never let anyone talk you into doing a bad job Power Plays
Rushing to Code
Lack of Knowledge
Shady Ethics
Circumventing Processes
Lesson 48: Strive to have peers find defects
Benefits of Peer Reviews
Varieties of Software Reviews
The Soft Side: Cultural Implications of Reviews
Lesson 49: A fool with a tool is an amplified fool
A Tool Must Add Value
A Tool Must Be Used Sensibly
A Tool Is Not a Process
Lesson 50: Rushed development leads to maintenance nightmares
Technical Debt and Preventive Maintenance
Conscious Technical Debt
Designing for Quality, Now or Later
Next Steps: Quality
Chapter 7: Lessons About Process Improvement
Introduction to Process Improvement
Software Process Improvement: What and Why
Don’t Fear the Process
Making SPI Stick
First Steps: Software Process Improvement
Lesson 51: Watch out for “Management by Businessweek”
First Problem, Then Solution
A Root Cause Example
Diagnosis Leads to Cure
Lesson 52: Ask not, “What’s in it for me?” Ask, “What’s in it for us?”
The Team Payoff
The Personal Payoff
Take One for the Team
Lesson 53: The best motivation for changing how people work is pain
Pain Hurts!
Invisible Pain
Lesson 54: Steer change with gentle pressure, relentlessly applied
Steering
Managing Upward
Lesson 55: Don’t make all the mistakes other people already have
The Learning Curve
Good Practices
Lesson 56: Good judgment and experience can trump a process
Processes and Rhythms
Being Nondogmatic
Lesson 57: Shrink templates to fit your project
Lesson 58: Learn and improve so the next project goes better Looking Back
Retrospective Structure
After the Retrospective
Lesson 59: Don’t do ineffective things repeatedly
The Merits of Learning
The Merits of Thinking
Next Steps: Software Process Improvement
Chapter 8: What to Do Next
Lesson 60: You can’t change everything at once
Prioritizing Changes
Reality Check
Action Planning
Your Own Lessons
Appendix: Summary of Lessons
References
Index
