You are previewing Beyond Legacy Code.
O'Reilly logo
Beyond Legacy Code

Book Description

We're losing tens of billions of dollars a year on broken software, and great new ideas such as agile development and Scrum don't always pay off. But there's hope. The nine software development practices in Beyond Legacy Code are designed to solve the problems facing our industry. Discover why these practices work, not just how they work, and dramatically increase the quality and maintainability of any software project.

Table of Contents

  1. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">&#160;</span>ForewordForeword
    1. Legacy
    2. Agility
    3. Work
  2. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">&#160;</span>AcknowledgmentsAcknowledgments
  3. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">&#160;</span>IntroductionIntroduction
    1. How to Use This Book
    2. Online Resources
  4. Part I. The Legacy Code Crisis
    1. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">1. </span>Something&#8217;s WrongSomething’s Wrong
      1. What Is Legacy Code?
      2. Down the Waterfall
      3. Playing All or Nothing
      4. Why Waterfall Doesn’t Work
      5. When “Process” Becomes “Busy Work”
      6. Concrete Management
      7. Here Be Dragons
      8. Estimating Unknowns
      9. An Industry of Amateurs
      10. Retrospective
    2. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">2. </span>Out of CHAOSOut of CHAOS
      1. The CHAOS Report
      2. Refuting Standish
      3. Why Projects Fail
      4. The Cost of Failure
      5. Retrospective
    3. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">3. </span>Smart People, New IdeasSmart People, New Ideas
      1. Enter Agile
      2. Smaller Is Better
      3. Implementing Agile
      4. Balancing Art and Craft
      5. Agile Crosses the Chasm
      6. Demand Technical Excellence
      7. Retrospective
  5. Part II. Nine Practices to Extend the Life (and Value) of Your Software
    1. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">4. </span>The Nine PracticesThe Nine Practices
      1. What Experts Know
      2. Shu-Ha-Ri
      3. First Principles
      4. To Be a Principle
      5. To Be a Practice
      6. Principles Guide Practices
      7. Anticipate or Accommodate
      8. Defining “Good” in Software
      9. Why Nine Practices
      10. Retrospective
    2. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">5. </span>Practice 1: Say What, Why, and for Whom Before HowPractice 1: Say What, Why, and for Whom Before How
      1. Don’t Say How
      2. Turn “How” Into “What”
      3. Have a Product Owner
      4. Stories Tell What, Why, and for Whom
      5. Set Clear Criteria for Acceptance Tests
      6. Automate Acceptance Criteria
      7. Let’s Get Practical
      8. Retrospective
    3. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">6. </span>Practice 2: Build in Small BatchesPractice 2: Build in Small Batches
      1. Tell Smaller Lies
      2. Be Willing to Flex
      3. Cadence Dictates Process
      4. Smaller Is Better
      5. Divide and Conquer
      6. Shorten Feedback Cycles
      7. Speed Up the Build
      8. Respond to Feedback
      9. Build a Backlog
      10. Break Stories Into Tasks
      11. Think Outside the Time Box
      12. Manage Scope
      13. Let’s Get Practical
      14. Retrospective
    4. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">7. </span>Practice 3: Integrate ContinuouslyPractice 3: Integrate Continuously
      1. Establish the Heartbeat of a Project
      2. Know the Difference Between Done, Done-Done, and Done-Done-Done
      3. Practice Continuous Deployability
      4. Automate the Build
      5. Integrate Early and Often
      6. Take the First Step
      7. Let’s Get Practical
      8. Retrospective
    5. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">8. </span>Practice 4: CollaboratePractice 4: Collaborate
      1. Extreme Programming
      2. Communication and Collaboration
      3. Pair Program
      4. Buddy Program
      5. Spike, Swarm, and Mob
      6. Research Unknowns in Time Boxes
      7. Schedule Code Reviews and Retrospectives
      8. Amplify Learning and Spread Knowledge
      9. Always Strive to Be Mentoring and Mentored
      10. Let’s Get Practical
      11. Retrospective
    6. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">9. </span>Practice 5: Create CLEAN CodePractice 5: Create CLEAN Code
      1. Quality Code Is Cohesive
      2. Quality Code Is Loosely Coupled
      3. Quality Code Is Encapsulated
      4. Quality Code Is Assertive
      5. Quality Code Is Nonredundant
      6. Code Qualities Guide Us
      7. Increase Quality Today to Increase Velocity Tomorrow
      8. Let’s Get Practical
      9. Retrospective
    7. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">10. </span>Practice 6: Write the Test FirstPractice 6: Write the Test First
      1. The Things We Call Tests
      2. Quality Assurance
      3. Write Good Tests
      4. TDD Gives Rapid Feedback
      5. TDD Supports Refactoring
      6. Write Testable Code
      7. TDD Can Fail
      8. Introduce TDD to a Team
      9. Become Test Infected
      10. Let’s Get Practical
      11. Retrospective
    8. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">11. </span>Practice 7: Specify Behaviors with TestsPractice 7: Specify Behaviors with Tests
      1. Red Bar/Green Bar/Refactor
      2. An Example of Specifying Behaviors Test-First
      3. Introducing Constraints
      4. What I Created
      5. Tests Are Specifications
      6. Be Complete
      7. Make Each Test Unique
      8. Cover Code with Tests
      9. Bugs Are Missing Tests
      10. Test Workflows with Mocks
      11. Create a Safety Net
      12. Let’s Get Practical
      13. Retrospective
    9. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">12. </span>Practice 8: Implement the Design LastPractice 8: Implement the Design Last
      1. Impediments to Changeability
      2. Sustainable Development
      3. Coding vs. Cleaning
      4. Software Is Read More than It’s Written
      5. Program by Intention
      6. Reduce Cyclomatic Complexity
      7. Separate Use from Creation
      8. Emergent Design
      9. Let’s Get Practical
      10. Retrospective
    10. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">13. </span>Practice 9: Refactor Legacy CodePractice 9: Refactor Legacy Code
      1. Investment or Debt?
      2. Become a “Deadbeat”
      3. When Code Needs to Change
      4. Refactoring Techniques
      5. Refactor to Accommodate Change
      6. Refactor to the Open-Closed
      7. Refactor to Support Changeability
      8. Do It Right the Second Time
      9. Let’s Get Practical
      10. Retrospective
    11. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">14. </span>Learning from Our LegacyLearning from Our Legacy
      1. Better, Faster, Cheaper
      2. Don’t Spend Money You Don’t Have To
      3. Walk the Straight and Narrow
      4. Improve the Software Profession
      5. Beyond Agile
      6. Embody Understanding
      7. The Courage to Grow
  6. <span xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" class="toc-secnum">&#160;</span>BibliographyBibliography