Extreme Programming

Programming History

1960’s  60’s  “Cowboys” wrote software anyway that they could  Difference between best programmers and worst as high as 28:1 (many sources)  Start of the “software crisis”  1968  Edsger Dijkstra, “GOTO Statement Considered Harmful” (CACM)GOTO Statement Considered Harmful  Recognition that rules can improve the average programmer

Structuring Software Development  Few rules helped immensely  Good rules and practices developed over the 70’s and 80’s  If a few rules are good, more are better…  Late 80’s, major focus on process as a key to quality  ISO 9000 (first published 1987) ISO 9000  Malcolm Baldrige National Quality Award (just celebrated 25 th anniversary) Malcolm Baldrige National Quality Award

ISO 9000  ISO: International body  150 national standards organization (US: ANSI)  Originally technical standards  Has broadened its scope: e.g., quality  ISO 9000: family of standards  Generic management system standard  Not the process but the management of the process  Compendium of best practices  Continues to be updated  ISO 9001 key standard

ISO 9001 Requirements  Business  customer requirement based  communication and validation  internal audits  evaluation and improvements  problem management and effectiveness monitoring  non-conformances and bad product  Quality Policy  formal statement from management  understood and followed at all levels by all employees  used to establish employee measurable objectives  Quality System  regularly audited and evaluated for conformance and effectiveness  decisions based on recorded data  records that trace raw materials and products to the source

Why not apply to software development?  Companies started codifying their practices  Large documents and people to manage them  Rise of the project manager  “Honored in the breach”  More large projects and more late or failed projects  1995 Standish Group Study 1995 Standish Group Study  Jerry Saltzer SOSP 1999 Jerry Saltzer SOSP 1999

1995 Standish Group Study  50% software projects challenged  2x budget  2x completion time  2/3 planned function  30% impaired  Scrapped  20% success

Jerry Saltzer Presentation  Who is Jerry Saltzer?  Early time sharing (CTSS)  Multics Operating System (“inspired” Unix)  Project Athena  Thin client computing  Kerberos  LDAP  Instant messaging

Software Engineering Processes  Differ by how often you do the steps  Points on the spectrum  Differences in overhead  Three fundamental models  Waterfall  Spiral  Iterative  Widely used models  Integrated Product Development  Unified Software Development Process  Extreme Programming

All models address the 4 P’s of Software Engineering  People: those doing it  Product: what is produced  Process: manner in which it is done  Project: the doing of it

Integrated Product Development (IBM)  Originated at GE  Cross-functional teams at all phases  Phased approval (easy to start, easy to kill)  Concept  Plan  Ship  Sunset

Unified (Software Development) Process  Iterations within phases  4 phases and core workflows for each Requirements Analysis Design Implementation Test ElaborationInceptionConstructionTransition

Agile Methodologies: Born from Backlash

Agile Methodologies  Keep only those rules and processes that help  Antidote to bureaucracy  License to hack  Key characteristics  Adaptive  People-oriented

Agile Manifesto  February 2001  Representatives from Extreme Programming SCRUM DSDMAdaptive Software Dev CrystalFeature-Driven Dev Pragmatic Programming

Extreme Programming

 Complete development process  First code drop 2-3 weeks after start (what is the start?)  Customer part of the development team  Iterative development to the max  Derive requirements with customer through hands-on experimentation  Agile methodology

History  Kent Beck considered the inventor  Ideas developed in the early 90’s  First project at Daimler Chrysler in 1996 Smalltalk Design patterns Extreme programming

XP Bills of Rights  Developer has a right to  Clear requirements and priorities  Determine how long requirement will take  Revise estimates  Always produce quality code

XP Bills of Rights  Customer has a right to  An overall plan  See progress in a running system  Change requirements and priorities  Be informed of changes to schedule and have input as to how to adapt  Cancel in the middle and still have something to show for the investment

XP Value System  Communication: Focus on people, not documentation  Simplicity: Of process and code  Feedback: Mechanism to make useful progress  Courage: To trust in people what you would like to know about software that your life depended on? (Bollinger)

Extreme Programming Flowchart

User Stories  Use cases  Written by customer  Used for planning  Developers estimate by story  Stories basis for iteration  Used to build acceptance tests  Remember: correctness equals meeting requirements

System Metaphor Initial system design

Spikes  Technology explorations  Focus on high risk items  Typically considered throw-away code If not, needs to be agreed to by the whole team

Release Planning  Each iteration has its own plan  Function OR date (other is adjusted accordingly) (Recall 4 variables: function, date, resources, quality)  Planning adapts as the project progresses  Measure project velocity Number of user stories and tasks completed  Next iteration looks at planned vs. actual time Allowed to plan last iteration’s number for this iteration

Iteration  Scope: all parts of the system  Only add functions needed for current user stories  Recommendation: 3 weeks  Moving people around  Backup and training  Code is owned by the whole team  Pair programming  Re-factoring

Pair Programming  Two people working at a single computer  Built-in backup and inspections  Collaboration builds better code  Mechanical model  One drives, the other talks  Keyboard slides between the two  Logical model  One tactical, the other strategic  Both think about the full spectrum but bring different perspectives

Pair Programming Experiments  Typical numbers: total manpower not very different  No more than ¼ additional  Implication: actual time reduced  Improved satisfaction also improves productivity Williams et al, “Strengthening the Case for Pair-Programming”Strengthening the Case for Pair-Programming

Refactoring  Each iteration adds just the function needed  If you continue to add new functions every two weeks, code can get messy  Refactoring is the cleaning up of the code at the end of the iteration  Critical to maintaining quality code  (Also applies to the design)  Difference between refactoring & rewriting?

Feedback Loops

The Rules of Extreme Programming  Planning  Managing  Designing  Coding  Testing

When to Use XP  Types of projects  High risk  Poorly understood requirements  Team  Small size: 2 to 12  Needs to include customer  Automated testing  Timing issue

What Makes a Project XP  Paradigm  see change as the norm, not the exception: optimize for change  Values  communication, simplicity, feedback, courage: honor in actions  Power sharing  business makes business decisions; development, technical ones  Distributed responsibility and authority  people make commitments for which they are accountable  Optimizing process  aware of process and whether it is working: experiment to fix  acculturate new team members Ward Cunningham, Ron Jeffries, Martin Fowler, Kent Beck

NOT everyone loves XP

References  Agile Methodologies  Discussion

More on Trust in People

Egoless Programming  Weinberg 1971 The Psychology of Computer Programming  “cowboy” era  Re-issued in 1998  Programmers needed to be team players  Accept inspections and reviews  Open to corrections and critiques

(Lamont Adams)

But pride of ownership is critical to quality

Software Craftsmanship  Emphasizes coding skills of the developers  Recognition of importance of the individual  Basis  Pragmatic Programmer (Hunt and Thomas) Pragmatic Programmer  Software Craftsmanship (McBreen) Software Craftsmanship  Manifesto Manifesto  First conference 2009  Fundamentals  Apprenticeship  Pride in your work

Can Craftsmanship Help?  Craftsmen sign their work  basis for reputationhiring on portfolioforget licensing  Exploit productivity differences between individuals  not managing hordes of 'average' programmers: small teams of good developers  pay differentials  Expose the fallacy of good enough software  Software development is a social, intellectual activity  not mechanical : engineering wrong metaphor  mythical man month problem still exists  Apprenticeship more effective than training  software development as a craft  not the same as being taught how to program.