Extreme Programming

Ken Bauer 15 August 2012

Outline
The Software Problem History of the Software Problem Our Solution: XP & Agile Methods Implementation Issues Management Issues Review, Conclusions, Future
15 August 2012 XP, Ken Bauer 2

Education background
B.Sc. Computer Science (Honours), University of Victoria, 1993 M.Sc. Computer Science University of Washington, 1995 OOPSLA Committee member 1995-present (attendee since 1992)

15 August 2012

XP, Ken Bauer

Academic Background
Professor, Computer Science ITESM, Campus Guadalajara 1995-1997, 1999-present O-O, S.E., P.L., O.S. Introduced Java to ITESM in 1996 Director, ISC at Campus Guadalajara 2000 - present
15 August 2012 XP, Ken Bauer 4

Industry Background
Object Technology International (IBM) 1997, Software Engineer, worked on VAJava v1.0 Harley Street Software, 1998 Safeware Engineering Inc., 1998 Consulting in O-O, Java, XP, systems administration and security since 1999
15 August 2012 XP, Ken Bauer 5

The Software Problem

15 August 2012

XP, Ken Bauer

Why Is Software So Hard?

Is it technical Or is it human Are systems just bigger Or did we have problems with small systems Or is it really that hard?
XP, Ken Bauer 7

15 August 2012

Technical Issues
Compilers
Development Environments Wizards

15 August 2012

XP, Ken Bauer

Compilers
The human code-optimizers of the 1970s and 1980s are no longer needed Computers parse fast Humans parse slow Humans need abstraction

15 August 2012

XP, Ken Bauer

Development Environments
Syntax checkers/highlighters Debuggers (distributed) Source Code Control Team development support

15 August 2012

XP, Ken Bauer

10

Wizards
Wizards, code-generators, templates, frameworks are all buzzwords. Which ones work? Wizards are magical and mystical
But who was that code generated? And do you understand it? ALL of it?
15 August 2012 XP, Ken Bauer 11

Human Issues
Management Style Programmer as a profession Software is written by people for people People make mistakes People get bored People get defensive
etc, etc
15 August 2012 XP, Ken Bauer 12

Management Style
What is the managers role?
(fill in our work here)

15 August 2012

XP, Ken Bauer

13

Programmer As a Profession
What kind of people are we getting? Who is responsible for the development of the developer?
University/College The company The developer herself Government
15 August 2012 XP, Ken Bauer 14

Software is Peopleware
Software almost always involves people at the end, and definitely in the beginning and middle

15 August 2012

XP, Ken Bauer

15

Software is Peopleware
Software almost always involves people at the end, and definitely in the beginning and middle People have needs

15 August 2012

XP, Ken Bauer

16

Software is Peopleware
Software almost always involves people at the end, and definitely in the beginning and middle People have needs People have desires

15 August 2012

XP, Ken Bauer

17

Software is Peopleware
Software almost always involves people at the end, and definitely in the beginning and middle People have needs People have desires People have lives!!!!

15 August 2012

XP, Ken Bauer

18

To Err Is Human
Can we finally accept this? If so, what are we going to do about it? Testing, code reviews, system builds, code walkthroughs Can we live with buggy systems?

15 August 2012

XP, Ken Bauer

19

Everyone Needs Stimulation

Grunt programmers produce grunt code In general, people like people and even working with them Two heads (together) think better than one two (apart) People learn best from people, not books, videos, code, banging their head against the monitor
15 August 2012 XP, Ken Bauer 20

People Have Their Pride

There is no such thing as the egoless programmer Who do we deal with this ego? Smash it with a hammer? Or should we harness it, culture it?

15 August 2012

XP, Ken Bauer

21

Environment Issues
Today and tomorrow are different Time does not stand still, neither do needs (requirements) Systems need to be ready to adapt to needs (adaptable systems) People should not be required to adapt to systems
15 August 2012 XP, Ken Bauer 22

Tomorrow, Tomorrow
What happens between today and tomorrow gives us more information Good experience is experience So is bad experience! We need to use what we learn everyday to the best advantage

15 August 2012

XP, Ken Bauer

23

Change, Death and Taxes

These all have something to do with software Changing requirements are a reality Death (or at least other disasters) will affect your project Regulations (government and otherwise) will be part of the process
15 August 2012 XP, Ken Bauer 24

Systems Change
Whenever a system is installed, somebody gains and somebody loses power. Tom DeMarco, OOPSLA 2001 Systems need to be able to change and built for that in mind

15 August 2012

XP, Ken Bauer

25

People Dont Like to Change

Again, that quote by Tom Every system creates losers and winners (in the change department) Our users should get the changes they want, not the ones that are thrust upon them

15 August 2012

XP, Ken Bauer

26

History of the Software Problem

15 August 2012

XP, Ken Bauer

27

Fred Brooks
No Silver Bullet 1975 (kwb) Silver Bullet Refired, 1995 (kwb) His comments on Eric Raymond

15 August 2012

XP, Ken Bauer

28

David Parnas
Modular Programming Star Wars project and his abandonment of the project Shouldnt be building projects so incredibly huge.

15 August 2012

XP, Ken Bauer

29

Tom DeMarco
Peopleware, Lidster and DeMarco, 1987 The first to insist that software is a people problem, not a technical one Most software development projects fail because of failures within the team running them Keynote at OOPSLA 2001
15 August 2012 XP, Ken Bauer 30

Watts Humphrey
PSP, Personal Software Process TSP, Team Software Process CMM, Capability Maturity Model Focused on a disciplined approach to Software Engineering

15 August 2012

XP, Ken Bauer

31

Levels of CMM
1 No order 2 Repeatable 3 Defined (processes) 4 Managed (quantifiable quality goals) 5 Optimizing (continuous improvement)
XP, Ken Bauer 32

15 August 2012

Larry Constantine
Larry wrote continued to write about Peopleware in the 90s The Peopleware Papers, 2001 Brings a psychological background and business school education to the industry

15 August 2012

XP, Ken Bauer

33

Ed Yourdon
The Decline and Fall of the American Programmer, 1992 Rise And Resurrection of the American Programmer, 1996 Death March, 1999

15 August 2012

XP, Ken Bauer

34

Steve McConnell
Code Complete, Rapid Development, Software Project Survival Guide and After the Gold Rush Software Engineering as a profession Editor in Chief, IEEE Software www.construx.com Reading list is excellent
15 August 2012 XP, Ken Bauer 35

Kent Beck
Smalltalk/OOPSLA community Early Patterns work eXtreme Programming Manifesto XP Series (7 now) Keynote at CongresoISC 2000 at ITESM, Campus Guadalajara
XP, Ken Bauer 36

15 August 2012

Alistair Cockburn
The Agile Software Development Series Agile Software Development Writing Effective Use Cases Surviving Object-Oriented Projects

15 August 2012

XP, Ken Bauer

37

The Pragmatic Programmers

Dave Pragmatic Thomas Andy Hunt Programming as a craft Metaphors such as gardening

15 August 2012

XP, Ken Bauer

38

Linus Torvalds, Eric Raymond

Open Source Movement Cathedral and the Bazaar

15 August 2012

XP, Ken Bauer

39

Our Solution: XP &Agile Methods

15 August 2012

XP, Ken Bauer

40

XP (white-book) Forward by Erich Gamma (OTI)

XP nominates programming as the key activity throughout a software project.
This cant possibly work!

15 August 2012

XP, Ken Bauer

41

XP (white-book) Forward by Erich Gamma (OTI)

Work in a just-in-tie software culture with compressed release cycles and high technical risk Change becomes your friend Communication in and across geographically separate teams (done with code)
15 August 2012 XP, Ken Bauer 42

XP (white-book) Forward by Erich Gamma (OTI)

Read code to understand new or evolving system APIs Life cycle and behavior is defined in test cases (done with code) Problem reports come in with test cases demonstrating the problem (again, with code)
15 August 2012 XP, Ken Bauer 43

XP (white-book) Forward by Erich Gamma (OTI)

Continuously improving code with refactoring OTI has a code-centric development process (pre XP) and it worked. And worked well with products shipped on time

15 August 2012

XP, Ken Bauer

44

XP (white-book) Forward by Erich Gamma (OTI)

This is not just daredevil, cowboycoder based Delivering software is hard, and delivering quality software in time is even harder To make it work requires the disciplined use of additional best practices
15 August 2012 XP, Ken Bauer 45

XP (white-book) Forward by Erich Gamma (OTI)

Kent Beck wrote the book on bestpractice patterns in Smalltalk (literally) Dave Thomas (big Dave of OTI, not the pragmatic Dave or the Wendys Dave) co-wrote the Smalltalk with Style book

15 August 2012

XP, Ken Bauer

46

XP (white-book) Forward by Erich Gamma (OTI)

Kent Beck and Ward Cunningham inspired much of the Pattern movement and best practices They also refined what they were seeing into a lightweight methodology That is what XP is. The writing down of what they were experiences
15 August 2012 XP, Ken Bauer 47

XP Manifesto
Clear separation of roles of customer and programmer Bill of Rights Courage Customers: scope, priority, composition and dates of releases Programmers: estimates, technical consequences, process, detailed schedule
15 August 2012 XP, Ken Bauer 48

XP Is an Onion
Processes
Team Practices

Programming

15 August 2012

XP, Ken Bauer

49

Risk
Schedule slips Project canceled System goes sour Defect rate Business misunderstood Business changes False feature rich Staff turnover
15 August 2012 XP, Ken Bauer 50

Schedule Slips
Short release cycles 3 months AT MOST Within release are iterations 1 4 weeks per iteration Highest priority features first

15 August 2012

XP, Ken Bauer

51

Project Cancelled
Customer chooses smallest release that works best for them Keeps value of software at its greatest

15 August 2012

XP, Ken Bauer

52

System goes sour

Create and maintain comprehensive suite of tests Run and re-run after every change Several times a day! Keep system in prime condition Cruft cannot accumulate
XP, Ken Bauer 53

15 August 2012

Defect Rate
Tests from the perspective of programmers function-by-function Tests from the perspective of the customers feature-by-feature

15 August 2012

XP, Ken Bauer

54

Business misunderstood
Customer is integral part of team Specification is continually refined Learning by customer and team can be reflected in the software

15 August 2012

XP, Ken Bauer

55

Business Changes
XP shortens release cycle Less change during a release Customer welcome to substitute new functionality for functionality not yet completed

15 August 2012

XP, Ken Bauer

56

False feature rich

XP insists that only the highest priority tasks are addressed Customer makes the priority decisions NOT the programmer

15 August 2012

XP, Ken Bauer

57

Staff turnover
Programmers accept responsibilty for estimating and completing their own work XP gives them feedback about the actual time taken so they can improve estimates XP encourage human contact among the team
15 August 2012 XP, Ken Bauer 58

Economics of Software
Cash flows in and out Interest rates Project mortality

15 August 2012

XP, Ken Bauer

59

Maximizing Economic Value

Spending less, difficult Earning more, superior marketing and sales organization Spending later and earning sooner to pay less interest and earn more interest Increasing the probability that the project will stay alive
15 August 2012 XP, Ken Bauer 60

Options in Economics
Option to abandon cancel is sometimes good Option to switch change direction Option to defer wait to spend money Option to grow - capitalize

15 August 2012

XP, Ken Bauer

61

Four Variables in S.E.

Cost Time Quality Scope Focus on Scope
15 August 2012 XP, Ken Bauer 62

Cost of Change
Graph on board Requirements Analysis Design Implementation Testing Production
15 August 2012 XP, Ken Bauer 63

Four Values
Communication Simplicity Feedback Courage

15 August 2012

XP, Ken Bauer

64

Basic Principles
Rapid feedback Assume simplicity Incremental change Embracing change Quality work

15 August 2012

XP, Ken Bauer

65

Other Principles
Teach learning Small initial investment Play to win Concrete experiments Open, honest communication
15 August 2012

Work with peoples instincts, not against Accepted responsibility Local adaption Travel light Honest measurement
XP, Ken Bauer 66

Test First
JUnit (or other testing framework) If tests always ran correctly, then we wouldnt have to write them. Tests are interesting when they fail, especially if we didnt expect them to fail.
JUnit: A Cooks Tour Kent Beck & Ward Cunningham

15 August 2012

XP, Ken Bauer

67

Basics of Programming
Coding Testing Listening Designing

15 August 2012

XP, Ken Bauer

68

The 12 XP Practices
The Planning Game Small Releases Metaphor Simple design Testing Refactoring Pair Programming Collective ownership Continuous integration 40-hour week On-site customer Coding standards
XP, Ken Bauer 69

15 August 2012

Planning Game
Business people:
Scope Priority Composition of releases Dates of releases

Technical people:
Estimates Consequences Process Detailed scheduling

15 August 2012

XP, Ken Bauer

70

Small Releases
Small as possible Containing the most valuable business requirements Has to make sense as a whole No half-implemented features

15 August 2012

XP, Ken Bauer

71

Metaphor
Replaces much of what others call architecture Give everyone a coherent story within which they can work A story that can easily be shared by business and technical people

15 August 2012

XP, Ken Bauer

72

Simple Design
The right design:
Runs all the tests Has no duplicated logic States every intention important to the programmers Has the fewest possible classes and methods

15 August 2012

XP, Ken Bauer

73

Testing
Any program feature without an automated test simply does not exist Unit tests build confidence in the operation of the program for the programmers Functional tests give customers confidence in the operation of the program
15 August 2012 XP, Ken Bauer 74

Refactoring
Changing the existing program to make adding a new feature simpler Making the program simpler but still passing the tests

15 August 2012

XP, Ken Bauer

75

Pair Programming
One keyboard, mouse and monitor Inactive partner IS active:
Is this whole approach going to work? What are some other test cases that might not work yet? Is there some way to simplify the whole system so the current problem just disappears?
15 August 2012 XP, Ken Bauer 76

Pair Programming (cont)

All I Need to Know about PairProgramming I Learned in Kindergarten Laurie Williams?? http://collaboration.csc.ncsu.edu/lauri e/Papers/Kindergarten.PDF Or ACM Digital Library

15 August 2012

XP, Ken Bauer

77

Collective Ownership
Anyone adds value when needed and they can Better than individual ownership Better than NO ownership

15 August 2012

XP, Ken Bauer

78

Continuous Integration
Daily builds are for wimps Big builds are hard Fixing broken builds is harder

15 August 2012

XP, Ken Bauer

79

40-Hour Week
Being fresh Overtime is a symptom of a serious problem on the project Vacations of at least 2 weeks People need downtime

15 August 2012

XP, Ken Bauer

80

On-site Customer
Those quick questions become really quick And we actually ask them Instead of assuming The customer can do other stuff

15 August 2012

XP, Ken Bauer

81

Coding Standards
Do it my way.
Just needs to be agreed on. Once and Only Once rule (no duplicate code) Adopted voluntarily by the whole team
XP, Ken Bauer 82

15 August 2012

Management Issues

The Green Book

15 August 2012

XP, Ken Bauer

83

Review, Conclusions, Future

15 August 2012

XP, Ken Bauer

84