Software Development Pearls

Foreword xix<br>Acknowledgments xxi<br>About the Author xxiii <br> <br> Chapter 1: Learning from Painful Experience 1 <br>My Perspective 1 <br>About the Book 2 <br>A Note on Terminology 4 <br>Your Opportunity 5 <br> <br> Chapter 2: Lessons About Requirements 7 <br>Introduction to Requirements 7 <br>First Steps: Requirements 11 <br>Lesson 1: Get the requirements right or the project will fail 12 <br>Lesson 2: Requirements development delivers shared understanding 15 <br>Lesson 3: Stakeholder interests intersect at the requirements 17 <br>Lesson 4: Favor a usage-centric approach to requirements 21 <br>Lesson 5: Requirements development demands iteration 25 <br>Lesson 6: Agile requirements aren't different from other requirements 28 <br>Lesson 7: Recording knowledge is cheaper than acquiring it 33 <br>Lesson 8: Requirements are about clear communication 37 <br>Lesson 9: Requirements quality is in the eye of the beholder 41 <br>Lesson 10: Requirements must be good enough to reduce risk 44 <br>Lesson 11: People don't simply gather requirements 46 <br>Lesson 12: Elicitation brings the customer's voice to the developer 51 <br>Lesson 13: Telepathy and clairvoyance don't work 55 <br>Lesson 14: Large groups have difficulty agreeing on requirements 57 <br>Lesson 15: Avoid decibel prioritization 61 <br>Lesson 16: Define scope to know whether your scope is creeping 64 <br>Next Steps: Requirements 69 <br> <br> Chapter 3: Lessons About Design 71 <br>Introduction to Design 71 <br>First Steps: Design 75 <br>Lesson 17: Design demands iteration 76 <br>Lesson 18: It's cheaper to iterate at higher levels of abstraction 79 <br>Lesson 19: Make products easy to use correctly, hard to use incorrectly 84 <br>Lesson 20: You can't optimize all desirable quality attributes 87 <br>Lesson 21: An ounce of design is worth a pound of recoding 92 <br>Lesson 22: Many system problems take place at interfaces 94 <br>Next Steps: Design 100 <br> <br> Chapter 4: Lessons About Project Management 103 <br>Introduction to Project Management 103 <br>First Steps: Project Management 108 <br>Lesson 23: Work plans must account for friction 109 <br>Lesson 24: Don't give anyone an estimate off the top of your head 114 <br>Lesson 25: Icebergs are always larger than they first appear 116 <br>Lesson 26: Data strengthens your negotiating position 121 <br>Lesson 27: Use historical data to improve estimates 124 <br>Lesson 28: Don't change an estimate just to make someone happy 127 <br>Lesson 29: Stay off the critical path 129 <br>Lesson 30: Incomplete tasks get no partial credit 132 <br>Lesson 31: A project team needs flexibility to adapt to change 136 <br>Lesson 32: Uncontrolled project risks will control you 140 <br>Lesson 33: The customer is not always right 145 <br>Lesson 34: We do too much pretending in software 149 <br>Next Steps: Project Management 151 <br> <br> Chapter 5: Lessons About Culture and Teamwork 153 <br>Introduction to Culture and Teamwork 153 <br>First Steps: Culture and Teamwork 158 <br>Lesson 35: Knowledge is not zero-sum 159 <br>Lesson 36: Don't make commitments you know you can't fulfill 163 <br>Lesson 37: Higher productivity requires training and better practices 166 <br>Lesson 38: The flip side of every right is a responsibility 171 <br>Lesson 39: Surprisingly little separation can inhibit communication 173 <br>Lesson 40: Small-team approaches don't scale to large projects 177 <br>Lesson 41: Address culture change during a change initiative 180 <br>Lesson 42: Engineering techniques don't work with unreasonable people 185 <br>Next Steps: Culture and Teamwork 187 <br> <br> Chapter 6: Lessons About Quality 189 <br>Introduction to Quality 189 <br>First Steps: Quality 194 <br>Lesson 43: Pay for quality now or pay more later 195 <br>Lesson 44: High quality naturally leads to higher productivity 200 <br>Lesson 45: Organizations somehow find time to fix bad software 205 <br>Lesson 46: Beware the crap gap 207 <br>Lesson 47: Never let anyone talk you into doing a bad job 209 <br>Lesson 48: Strive to have peers find defects 213 <br>Lesson 49: A fool with a tool is an amplified fool 217 <br>Lesson 50: Rushed development leads to maintenance nightmares 221 <br>Next Steps: Quality 224 <br> <br> Chapter 7: Lessons About Process Improvement 225 <br>Introduction to Process Improvement 225 <br>First Steps: Software Process Improvement 228 <br>Lesson 51: Watch out for "Management by Businessweek" 229 <br>Lesson 52: Ask not, "What's in it for me?" Ask, "What's in it for us?" 233 <br>Lesson 53: The best motivation for changing how people work is pain 236 <br>Lesson 54: Steer change with gentle pressure, relentlessly applied 238 <br>Lesson 55: Don't make all the mistakes other people already have 241 <br>Lesson 56: Good judgment and experience can trump a process 244 <br>Lesson 57: Shrink templates to fit your project 247 <br>Lesson 58: Learn and improve so the next project goes better 252 <br>Lesson 59: Don't do ineffective things repeatedly 256 <br>Next Steps: Software Process Improvement 259 <br> <br> Chapter 8: What to Do Next 261 <br>Lesson 60: You can't change everything at once 262 <br>Action Planning 266 <br>Your Own Lessons 267 <br> <br> Appendix: Summary of Lessons 269 <br> <br> References 273<br>Index 285