Software Development Pearls: Lessons from Fifty Years of Software Experience

Cover Page
Title Page
Contents
Table of Contents
Foreword
Acknowledgments
About the Author
Chapter 1. Learning from Painful Experience
Chapter 2. Lessons About Requirements
    First Steps: Requirements
    Lesson #1. If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.
    Lesson #2. The key deliverables from requirements development are a shared vision and understanding.
    Lesson #3. Nowhere more than in the requirements do the interests of all the project stakeholders intersect.
    Lesson #4. A usage-centric approach to requirements will meet customer needs better than a feature-centric approach.
    Lesson #5. Requirements development demands iteration.
    Lesson #6. Agile requirements aren’t different from other requirements.
    Lesson #7. The cost of recording knowledge is small compared to the cost of acquiring knowledge.
    Lesson #8. The overarching objective of requirements development is clear and effective communication.
    Lesson #9. Requirements quality is in the eye of the beholder.
    Lesson #10. Requirements must be good enough to let construction proceed at an acceptable level of risk.
    Lesson #11. People don’t simply gather requirements.
    Lesson #12. Requirements elicitation must bring the customer’s voice close to the developer’s ear.
    Lesson #13. Two commonly used requirements elicitation practices are telepathy and clairvoyance. They don’t work.
    Lesson #14. A large group of people can’t agree to leave a burning room, let alone agree on exactly how to word some requirement.
    Lesson #15. Avoid decibel prioritization when deciding which features to include.
    Lesson #16. Without a documented and agreed-to project scope, how do you know whether your scope is creeping?
    Next Steps: Requirements
Chapter 3. Lessons About Design
    First Steps: Design
    Lesson #17. Design demands iteration.
    Lesson #18. It’s cheaper to iterate at higher levels of abstraction.
    Lesson #19. Make products easy to use correctly and hard to use incorrectly.
    Lesson #20. You can’t optimize all desirable quality attributes.
    Lesson #21. An ounce of design is worth a pound of recoding.
    Lesson #22. Many system problems take place at interfaces.
Chapter 4. Lessons About Project Management
    First Steps: Project Management
    Lesson #23. Work plans must account for friction.
    Lesson #24. Don’t give anyone an estimate off the top of your head.
    Lesson #25. Icebergs are always larger than they first appear.
    Lesson #26. You’re in a stronger negotiating position when you have data to build your case.
    Lesson #27. Unless you record estimates and compare them to what actually happened, you’ll forever be guessing, not estimating.
    Lesson #28. Don’t change an estimate based on what the recipient wants to hear.
    Lesson #29. Stay off the critical path.
    Lesson #30. A task is either entirely done or it is not done: no partial credit.
    Lesson #31. The project team needs flexibility around at least one of the five dimensions of scope, schedule, budget, staff, and quality.
    Lesson #32. If you don’t control your project’s risks, they will control you.
    Lesson #33. The customer is not always right.
    Lesson #34. We do too much pretending in software.
    Next Steps: Project Management
Chapter 5. Lessons About Culture and Teamwork
    First Steps: Culture and Teamwork
    Lesson #35. Knowledge is not zero-sum.
    Lesson #36. No matter how much pressure others exert, never make a commitment you know you can’t fulfill.
    Lesson #37. Without training and better practices, don’t expect higher productivity to happen by magic.
    Lesson #38. People talk a lot about their rights, but the flip side of every right is a responsibility.
    Lesson #39. It takes little physical separation to inhibit communication and collaboration.
    Lesson #40. Informal approaches that work for a small colocated team don’t scale up well.
    Lesson #41. Don’t underestimate the challenge of changing an organization’s culture as it moves toward new ways of working.
    Lesson #42. No engineering or management technique will work if you’re dealing with unreasonable people.
    Next Steps: Culture and Teamwork
Chapter 6. Lessons About Quality
    First Steps: Quality
    Lesson #43. When it comes to software quality, you can pay now or pay more later.
    Lesson #44. High quality naturally leads to higher productivity.
    Lesson #45. Organizations never have time to build software right, yet they find the resources to fix it later.
    Lesson #46. Beware the crap gap.
    Lesson #47. Never let your boss or your customer talk you into doing a bad job.
    Lesson #48. Strive to have a peer, rather than a customer, find a defect.
    Lesson #49. Software people love tools, but a fool with a tool is an amplified fool.
    Lesson #50. Today’s “gotta get it out right away” development project is tomorrow’s maintenance nightmare.
    Next Steps: Quality
Chapter 7. Lessons About Process Improvement
    First Steps: Software Process Improvement
    Lesson #51. Watch out for “Management by Businessweek.”
    Lesson #52. Ask not, “What’s in it for me?” Ask, “What’s in it for us?”
    Lesson #53. The best motivation for changing how people work is pain.
    Lesson #54. When steering an organization toward new ways of working, use gentle pressure, relentlessly applied.
    Lesson #55. You don’t have time to make each mistake that every practitioner before you has already made.
    Lesson #56. Good judgment and experience sometimes trump a defined process.
    Lesson #57. Adopt a shrink-to-fit philosophy with document templates.
    Lesson #58. Unless you take the time to learn and improve, don’t expect the next project to go any better than the last one.
    Lesson #59. The most conspicuous repeatability the software industry has achieved is doing the same ineffective things over and over.
    Next Steps: Software Process Improvement
Chapter 8. What To Do Next
    Lesson #60. You can’t change everything at once.
    Prioritizing Changes
    Action Planning
    Your Own Lessons
Appendix. Summary of Lessons
    Requirements
    Design
    Project Management
    Culture and Teamwork
    Quality
    Process Improvement
    General
References