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
