SOFTWARE DEVELOPMENT RHYTHMS -- CONTENTS -- PREFACE -- Special Acknowledgment -- Part I: Essentials -- 1 NO PROGRAMMER DIES -- 1.1 Developing Software versus Building a Tunnel -- 1.1.1 The Good Old Days? -- 1.1.2 The More Things Change, the More They Stay the Same? -- 1.1.3 Behind Software Products -- 1.1.4 Deal or No Deal -- 1.2 Do-Re-Mi Do-Re-Mi -- 1.2.1 Iterative Models -- 1.2.2 Code and Fix -- 1.2.3 Chaos -- 1.2.4 Methodology that Matters -- 1.3 Software Development Rhythms -- 1.3.1 Stave Chart by Example -- 1.3.2 Game Theory -- 1.3.3 In-Out Diagram -- 1.3.4 Master-Coach Diagram -- 1.3.5 No Mathematics -- 1.3.6 Where to Explore Rhythms -- References -- 2 UNDERSTANDING PROGRAMMERS -- 2.1 Personality and Intelligence -- 2.1.1 Virtuosi -- 2.1.2 Meeting Your Team -- 2.1.3 Recruiting Programmers -- 2.2 Outsourced Programmers -- 2.2.1 Programmers in Their Environments -- 2.2.2 Programmers, Cultures, and Teams -- 2.3 Experienced Management -- 2.3.1 Being Casual about Causal Relationships -- 2.3.2 Not Learning from Experience -- 2.3.3 Doing Things Right Right Now -- References -- 3 START WITH OPEN SOURCE -- 3.1 Process and Practice -- 3.1.1 The Four Ps of Projects -- 3.1.2 Agile Values -- 3.1.3 Zero-Point Collaboration -- 3.2 Open-Source Software (OSS) Development -- 3.2.1 Software Cloning -- 3.2.2 Software Quality -- 3.2.3 Starting Processes -- 3.2.4 Open-Source Development Community -- 3.2.5 Ugrammers -- 3.2.6 Participant Roles -- 3.2.7 Rapid Release -- 3.2.8 Blackbox Programming -- 3.2.9 OSS Practices -- 3.3 OSS-Like Development -- 3.3.1 Agile Practices -- 3.3.2 Communication Proximity -- 3.3.3 Loose and Tight Couples -- 3.3.4 Collocated Software Development -- 3.4 Conclusion -- References -- Part II: Rhythms -- 4 PLAGIARISM PROGRAMMING -- 4.1 Plagiarism -- 4.1.1 Existing Code -- 4.1.2 Social Network Analysis -- 4.1.3 Being Plagiarized.

4.1.4 Turn Everyone into a Programmer -- 4.1.5 Pattern Language -- 4.1.6 Software Team Capability -- 4.1.7 Rough-Cut Design -- 4.1.8 Training Is Not a Solution -- 4.2 Nothing Faster than Plagiarism -- 4.2.1 Immorality -- 4.2.2 Unprecedented Code -- 4.2.3 People Network -- 4.2.4 Rhythm for Plagiarism -- 4.2.5 Plagiarism at Work -- 4.3 Business and Rhythm for Plagiarism -- 4.3.1 15-Minute Business Presentation -- 4.3.2 Marketing Research -- 4.3.3 Chatting Robot -- 4.3.4 Old Song, New Singer -- References -- 5 PAIR PROGRAMMING -- 5.1 Art and Science -- 5.1.1 The Right Partner -- 5.1.2 Noisy Programming -- 5.1.3 Just Training -- 5.1.4 Pay to Watch -- 5.2 Two Worlds -- 5.2.1 Moneyless World -- 5.2.2 Money-Led World -- 5.2.3 Economics -- 5.2.4 Mythical Quality-Time -- 5.2.5 Elapsed Time Accelerated -- 5.2.6 Critical Path Method -- 5.2.7 Why Two, Not Three: The Antigroup Phenomenon -- 5.2.8 Software Requirements Are Puzzles -- 5.3 Programming Task Demands -- 5.3.1 2 and 4 Is 6 -- 5.3.2 2 and 4 Is 4 -- 5.3.3 2 and 4 Is 3 -- 5.3.4 2 and 4 2 -- 5.3.5 2 and 4 is Unknown -- 5.4 Pair Programming Is More than Programming -- 5.4.1 Design by Code -- 5.4.2 Pair Design -- 5.4.3 Rhythmic Pair Programming -- 5.5 Pair Programming Team Coached -- References -- 6 REPEAT PROGRAMMING -- 6.1 Controversies in Pair Programming -- 6.1.1 Is Programming a Unique Work? -- 6.1.2 Are Three Minds Better than Two? -- 6.1.3 Unreplicable Experiments -- 6.2 Repeat Programming -- 6.2.1 Variances -- 6.2.2 Principles -- 6.2.3 Triple Programming Unproductive -- 6.3 Rhythm: Pair-Solo-Pair-Solo -- 6.3.1 Persistence -- 6.3.2 Connection -- 6.3.3 Motivation -- 6.4 An Exception that Proves Brooks ́Law -- 6.4.1 Low Morale -- 6.4.2 Communication Costs -- 6.4.3 Rhythm for Late Projects -- References -- 7 AGILE TEAMING -- 7.1 Project Teams -- 7.1.1 Self-Organizing Teams -- 7.1.2 Teams in a Team.

7.1.3 Project Team Composition -- 7.1.4 Team Lifecycle versus Learning Curve -- 7.2 Productivity -- 7.2.1 The Illusion of Productivity -- 7.2.2 Collective Code Ownership -- 7.2.3 Accountability, Responsibility, and Transparency -- 7.3 Problems and Problem Owners -- 7.3.1 Rhythm: Trouble-Restructuring -- 7.3.2 Teaming Principles -- 7.4 Failing Projects Rescued -- 7.4.1 Project Traffic Light Reporting -- 7.4.2 A Business Case -- 7.4.3 Steering Committee Meeting -- 7.4.4 Agile Teaming in Action -- 7.5 Beware of Iago -- References -- 8 INCREMENTAL DESIGN -- 8.1 Modeling and Planning -- 8.1.1 Agile Planning -- 8.1.2 Design by Functional Modules -- 8.1.3 Simple Design -- 8.1.4 Total Cost Concept -- 8.2 Rework or Reuse -- 8.2.1 Unpreventable Rework -- 8.2.2 Improvisation -- 8.2.3 Up-Front Design -- 8.3 Just-in-Time Software Development -- 8.3.1 The CMM Rhythm -- 8.3.2 A Factory Tour -- 8.3.3 Walking Worker -- 8.3.4 Just-in-Time Software Development -- 8.3.5 Incremental Design -- 8.4 Requirements Complexity -- 8.4.1 Forgotten Requirements -- 8.4.2 Conflicting Requirements -- 8.4.3 Rapidly Changing Requirements -- 8.4.4 Requirements and Design -- 8.5 Refactoring -- 8.5.1 Refactoring Activities -- 8.5.2 Refactoring by Challenging -- 8.5.3 Refactoring for Design Patterns -- 8.5.4 Making Deliberate Mistakes -- References -- 9 TEST-DRIVEN DEVELOPMENT -- 9.1 Reverse Waterfall -- 9.1.1 Design-Code-Test -- 9.1.2 Test-Code-Design -- 9.2 Test-First Programming -- 9.2.1 Testing and Verification -- 9.2.2 Breakpoint Testing -- 9.2.3 Supporting Practices -- 9.3 Rhythm: Test-Code-Refactor -- 9.3.1 Simple Example -- 9.3.2 Automation -- 9.3.3 Revolution in Consciousness! -- 9.3.4 Test Case for Collaboration -- 9.4 Rapid Software Process Improvement -- 9.4.1 Training Program -- 9.4.2 Project Planning -- 9.4.3 Project Tracking -- 9.4.4 Software Quality.

9.4.5 Software Configuration -- 9.4.6 People Discipline -- References -- EPILOGUE: MEDLEY -- INDEX.