0%

Experience is a powerful teacher, but it is also slow and painful -- and software practitioners cannot afford to make every mistake others have suffered. This book helps you compress your learning curve and bypass much of the pain by absorbing lessons from others who served in the trenches before you. Drawing on 20+ years helping software teams succeed in nearly 150 organizations, Karl Wiegers presents 60 concise lessons and practical recommendations you can apply to all kinds of projects, regardless of your application domain, technology, development lifecycle, or platform infrastructure.

The principles, perspectives, and philosophical observations Wiegers holds have proven valid for decades, and will remain relevant for many years to come. Embodying both wisdom for deeper understanding and guidance for practical use, they represent an invaluable complement to the technical "nuts and bolts" software developers usually study.

Software Development Pearls covers multiple crucial domains of project success: requirements, design, project management, culture and teamwork, quality, and process improvement. Each chapter suggests several "first steps" and "next steps" to help you begin immediately applying the author's hard-won lessons -- and writing code that is more successful in every way that matters.

Table of Contents

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