2eXtreme Programmingתוכנה פרוייקטי לפיתוח מתודולוגיה Round 1: What is eXtreme Programming Why eXtreme Programming? How eXtreme Programming? Actual implementation Round 2: What is eXtreme Programming? Further details Why eXtreme Programming? Further analysis How eXtreme Programming? Further elaboration
4 Google: "problems with software development” Requirements are complex Clients usually do not know all the requirements in advance Requirements may be changing Frequent changes are difficult to manage Process bureaucracy (documents over development) It takes longer The result is not right the first time It costs more Applying the wrong process for the productProblems in software development
6נתונים :תוכנה פרויקטי75%התוכנה ממוצריללקוחות הנשלחים הגדוליםנחשביםככישלוןלדרישות מתאימים שאינם או כלל בשימוש שאינם או :הלקוחות.Based on: Mullet, D. (July, 1999). The Software Crisis, Benchmarks Online - a monthlypublication of Academic Computing Services 2(7).עלותבאגים של תיקונם-ב שנה בכל נאמדת בארה"ב בתוכנה59.5$ ביליוןThe National Institute of Standards and Technology (NIST), New Release of June 28, 2002.:השוואה לשם-בQ2של2003בארה"ב הושקעובתוכנה200$ ביליון
7What is eXtreme Programmingעל יודעים אתם מהXP?
8What is eXtreme ProgrammingeXtreme Programmingבתעשייה היישעתב החמצמחה. Differences from traditional methodologies Emphasis on people vs. development activities & schedule XP specifies how to behave; still leaves freedom 12 practices 4 values: feedback, simplicity, communication, courage The meaning of ‘eXtreme’ Optimum: teams up to 12 developers; can be adjustedto bigger teams.
9Why XP? Survey: 31 XP/Agile-methods early adopter projects 14 firms Findings: Cost reduction: 5-7% on average Time to market compression: 25-50% reduction This datum will be explained later
10Why XP? big companies using XP in at least some capacity Ford Motor, Chrysler, IBM, HP smaller software houses: Mayford Technologies RoleModel Software tutorials: Industrial Logic, Object Mentor
11How eXtreme Programming?Two days ineXtreme ProgrammingDevelopment Environment
14Business Day – Reflection 5 practices (out of 12)Planning gameOn-site customerSmall releasesSimple designMetaphor Planning game All developers participate All have the same load All developers get anoverview of the entiredevelopment process Simple means Very detailed Levels of abstraction
15Business Day – Reflection 5 practices (out of 12)Planning gameOn-site customerSmall releasesSimple designMetaphor On-site customer Customer’s on-goingfeedback Small releases On-going opportunity toupdate/changerequirements
16Business Day – Reflection 5 practices (out of 12)Planning gameOn-site customerSmall releasesSimple designMetaphor Simple design Develop only what isneeded for yourdevelopment task Metaphor Bridges customers-developers-business gaps
18Development Day Stand-up meeting The development environment Pair programming Test driven development (acceptance, unit-test) Code standards Refactoring Simple design Continuous integration (one integration machine) Collective ownership Sustainable pace (40-hour week)Source: http://www.rolemodelsoftware.com/
19Development Day - Reflection The development environment All see all; fosters communication Stand-up meeting All know what all do Pair programming Each task is thought on two levels of abstraction Unit test (automatic test first) First: improves understanding; Automatic: testing is easy Developers program and test Testing becomes manageable Success vs. failure
20Development Day - Reflection Continuous integration Reduces integration risks in later stages Collective ownership Important in companies with high turnover Coding standards Refactoring and simple design Code improvement is part of the methodology (though it doesntproduce code), gradual process Sustainable pace (40-hour week) Intense and productive work, developers are not tired
21Development and Business Days – ReflectionCode/TechnicalPerspectiveHuman/SocialPerspectiveRefactoringSimple designCoding standardsTestingContinuous integrationSmall releasesCollective ownershipPair programmingSustainable paceOn-site customerPlanning gameMetaphor
22The 12 XP practicesNote:nothing is new;gathering thepracticestogether is XPuniquenessSource: Beck, K. (2000). eXtreme Programming explained, Addison Wesley.
23eXtreme Programmingתוכנה פרוייקטי לפיתוח מתודולוגיה Round 1: What is eXtreme Programming Why eXtreme Programming? How eXtreme Programming? Round 2: What is eXtreme Programming? Further details Why eXtreme Programming? Further analysis How eXtreme Programming? Further elaboration
24What is eXtreme Programming Differences from traditional methodologies All developers are involved with requirements-design-code-testing Emphasis on people vs. development activities & schedule XP specifies how to behave; still leaves freedom and place for creativity The meaning of ‘eXtreme’ 12 practices 4 values: feedback, simplicity, communication, courage
25What is eXtreme Programming Agile Software Development Methodology Other agile methods: SCRUM, Feature DrivenDevelopment, DSDM All acknowledge that the main issue of softwaredevelopment is people: customers, communication Manifesto for Agile Software Development: http://agilemanifesto.org/ eXtreme Programming: Kent Beck, 1996, Chrysler
26Why XP? You do not do XP to save money;However, XP shortens time to market XP is a mature software developmentmethod
27Why XP? Survey: 31 XP/Agile-methods early adopter projects, 14 firms Findings: Cost reduction: 5-7% on average Time to market compression: 25-50% reduction intime
28Why XP? – Analysis Shorter development period: Code is easy-to-work with: less bugs: unit tests code is more readable & workable (invest now to gain benefitslater):pair programming, refactoring, coding standards Development is manageable and controlled: accurate estimation: small releases meets customer needs: customer on-site, planning game,acceptance tests
29Why XP? – Analysis Shorter development period (cont): Knowledge sharing, if one leaves everything continuesas usual: pair programming, collective ownership Production is increased: pair programming (work all the time),sustainable pace Cost for requirements change/update/elaboration isCONSTANT: simple design, planning game (redundant featuresare not added by customer and developers)
30Why XP?Barry W. Boehm (1981). Software Engineering Economics,Englewood Cliffs, N.J.: Prentice Hall. 63 software development projects in corporations such as IBM.Phase of requirement change Cost RatioRequirements 1Design 3-6Coding 10Development testing 15-40Acceptance testing 30-70Operation 40-1000
31Why XP? Under the assumption that “the later a requirements isintroduced the more expensive it is”, customers (anddevelopers) try to make a “complete” list of requirements. Under the assumption that “cost for introducing an update inthe requirements is constant”, customers (and developers)do not assume what the customer will need and developexactly and only what is needed.
32Why XP? You do not use XP to save money;However, XP shortens time to market XP is a mature software developmentmethod (at least CMM level 3)
33XP in Practice: Conceptual Changes XP encourages:Cooperation (vs. knowledge-is-power)Simplicity (vs. habit-of-high-complexity)Change in work habits
34Why XP? – Cognitive and Social Analysisהיישעתב החמצלחתה הסברXP.וחברתית קוגניטיבית מבט מנקודתPrisoner’s Dilemma Analysis of XP within the framework of the Prisoner’sdilemmaConstructivism Analysis of XP within the framework of constructivism GAPS (abstraction, satisfaction)
46The Prisoner’s Dilemma:Collective Ownership In practice “[a]nyone can change any codeanywhere in the system at any time.” (Beck, 2000).:פעולה שיתוף.בקוד שיתוף:בגידה.קוד הסתרתעל-פי עובדים כולםXP.זו מיומנות על-פי גם ולכן.פעולה לשתף האם הדילמה בפני עומדים לאפיתוח לתהליכי תורם הדבר ,פעולה משתפים כולם.נשכרים יוצאים וכולם התוכנה
53XP practices - Cognitive analysis• Small releasesGradual process of knowledge construction re requirements• RefactoringGradual process of knowledge construction re codes structure andreadability• Test driven development• Metaphor
54Cognitive and Social Analysis of XPpracticesCognitive analysis Social analysisRefactoringMetaphorTest-firstSmall releasesCollective ownershipSustainable paceSimple designCoding standards
55Bridging Cognitive and Social Gapsin Software Development usingExtreme ProgrammingBased on:Hazzan, O. and Dubinsky, Y. (2003). Bridging cognitive and social chasms in softwaredevelopment using Extreme Programming, Proceedings of the Fourth InternationalConference on eXtreme Programming and Agile Processes in Software Engineering,Genova, Italy, pp. 47-53.
62abstraction gap:single vs. multiple abstraction level Planning Game the release planning game is carried out on a high level ofabstraction; in the release planning a global view is gained the iteration planning game is carried out on a lower level ofabstraction; details are added only with respect to theforthcoming iteration the entire team participates in the planning game; developerssee the entire picture of the system (and its parts)
63abstraction gap (cont):single vs. multiple abstraction level Small Releases guide not to stay for too long a time in too high level ofabstraction or too low level of abstraction Pair Programming the two individuals in the pair think at different levels ofabstraction; the same development task is thought about attwo different levels of abstraction
64abstraction gap (cont):single vs. multiple abstraction level Sustainable Pace enables detachment from the details involved in softwaredevelopment and thinking on higher levels of abstraction Refactoring and Simple Design in order to improve a piece of code one has to examine it froma higher level of abstraction examining low level of abstraction (the code) from higher levelof abstraction (the design that guides the simplicity)
66satisfaction gap:individual vs. collective satisfaction On-site Customer enables developers to refrain from making decisions withrespect to customer’s needs without first checking with thecustomer as to what is really needed
67satisfaction gap (cont):individual vs. collective satisfaction Pair Programming crossing the gap between individual’s tendency to skip tests,check email, browse the web, etc. and the the benefits thatthe collective gains from pair programming Coding Standards reduces programmers’ tendency to write code in a way that isunderstood only to them
68satisfaction gap (cont):individual vs. collective satisfaction Collective Ownership one knows that everyone looks at what one programs andimproves it if it is not good enough one postpones immediate satisfaction to move on andimproves one’s code prior to its integration Sustainable Pace one can dedicate more time to one’s personal life withouthaving to satisfy the expectations of co-workers to put in longhours of overtime
69satisfaction gap (cont):individual vs. collective satisfaction Refactoring it is not sufficient that the code passes all tests, it should alsobe refactored, restructured and improved one should postpone his or her immediate needs and investmore effort in refactoring before moving on Simple design it is not sufficient that the code passes all the tests, its designshould also be simplified as much as possible before onemoves on to the next development task
70Gaps: SummaryA cognitive gap: abstractionA social gaps: satisfaction Suggestions for additional gaps?
73Agenda Introductory questions Example Refactoring: Focus on its nature, not on techniques What is refactoring? Why refactoring? How refactoring? Why refactoring hard? XP and refactoring Summary
75Example A given design Source: Martin Fowler, Kent Beck (Contributor), John Brant(Contributor), William Opdyke, don Roberts. (2002). Refactoring:Improving the Design of Existing Code, Addison-Wesley.
76Example A given design: Is it well designed? In what cases may itcause problems? Would you change it? If yes:suggest alternative designs.
77Example – Reflection How it emerged? Deal was originally being used to display a single deal. Someone wanted a table of deals. The subclass Tabular Active Deal displays a table. Now you want tables of passive deals. Another subclass is added. Small changes in many places. The code has become complicated, time is pressing, ... Adding a new kind of deal is hard, because the deal logic istangled with the presentation logic.
78Example – Reflection How it emerges? – In general“One day you are adding one little subclass to do a littlejob. The next day you are adding other subclasses to dothe same job in other parts of the hierarchy. A week (ormonth or year) later you are swimming in spaghetti.Without a paddle.” (Fowler)
79Example – Reflection Problems in tangled inheritance: It leads to code duplication. It makes changes more difficult: Strategies for solving a certain problem are spread around. The resulting code is hard to understand.
80Example – Reflection How tangled inheritance can be observed? Spot for a single inheritance hierarchy that is doing 2 jobs. “If every class at a certain level in the hierarchy has subclassesthat begin with the same adjective, you probably are doing twojobs with one hierarchy.” Why it can not be coded “correctly” at the firststage? Step-by-step refactoring (Fowler’s style)
81Example – Step by Step Refactoring First step: identify the jobs being done by thehierarchy. Job #1: capturing variation according to type of deal. Job #2: capturing variation according to presentationstyle.
82 Second step: decide which job is moreimportant.The dealness of the object is far moreimportant than the presentation style.Leave Deal alone and extract thepresentation style to its own hierarchy.Example – Step by Step Refactoring
83Example – Step by Step Refactoring Third step: use Extract Class to create apresentation style. Extract Class You have one class doing work that should be done bytwo. Create a new class and move the relevant fields andmethods from the old class into the new class.
84Example – Step by Step Refactoring Fourth step: Create subclasses of the extractedclass and initialize the instance variable to theappropriate subclass.Adding subclasses ofpresentation style
85Example – Step by Step Refactoring Fifth step: Use Move Method and Move Field tomove the presentation-related methods andvariables of the deal subclasses to thepresentation style subclasses.No code left in the classesTabular Active Deal and TabularPassive Deal. Remove them.
86Example – Step by Step Refactoring Sixth step: Separate the hierarchies: Distinguishbetween single and tabular.
88Example - Reflection What did we do? Is there a difference between the two designs? Ifyes – what is it? How is this change supposed to improve our life? In what way may the change be useful for someonewho did not write the code? How did the need for refactoring emerge? Couldn’t we write the code refactored from thebeginning?
89Example - Summary Tease Apart InheritanceYou have an inheritance hierarchy that is doingtwo jobs at once.Create two hierarchies and use delegation toinvoke one from the other. This format guides Fowler’s book.
90Example - Summary Delegation: The ability of an object to issue a message to anotherobject in response to a message. Delegation can be usedas an alternative to inheritance. Contrast: inheritance.Source: OMG Unified Modeling Language Specification. More about inheritance vs. delegation:http://www-inst.eecs.berkeley.edu/~cs61a-tb/week8/oop.html
91Refactoring In what follows:What is refactoring?Why refactoring?When refactoring? When not?How refactoring?Why refactoring hard?XP and refactoring
92Refactoring Fowler: Refactoring is the process of changing a softwaresystem in such a way that it does not alter the external(observable) behavior of the code yet improves itsinternal structure, to make it easier to understand andcheaper to modify. Kent (in Fowler, p. 51): Refactoring is the process oftaking a running program and adding to its value, not bychanging its behavior but by giving it more of thesequalities that enable us to continue developing at speed.
93Refactoring What do programmers do when refactoring:remove duplicationimprove communication and programcomprehensionadd simplicityadd flexibility
94Refactoring – Metaphors Three metaphors for refactoring :relationships with your programparenthesishealth
95Refactoring – Metaphors I[Refactoring] is like a new kind of relationship with yourprogram. When you really understand refactoring, thedesign of the system is as fluid and plastic and moldableto you as the individual characters in a source code file.You can feel the whole design at once. You can see howit might flex and change – a little this way and this ispossible, a little that way and that is possible. (Kent, inFowler, p. 333)
96Refactoring – Metaphors II Parenthesis (by Alistair Cockburn): “I started seeing 5*a + b*a as 3 operations on 6 things.(5+b)*a is 2 operations on 3 things.You can see the jump to OO programming.Lets take the case ofA.method1() = ... b.doThis(); b.doThat(); ...I change the code toB.doThisThat() = doThis(); doThat().A.method1() = ... b.doThisThat(); ...
97Refactoring – Metaphors II Alistair Cockburn (cont.): […] That change corresponds(in my mind, anyway) exactly to the (5+b)*a refactoring.Nowadays, I see a method and a class as a set ofparentheses, and when I move code out of one methodor class to another, I visualize it just as moving symbolsfrom one set of parentheses to another. Of course, thenet effect of the computation has to be the same, […] ithas to be a behavior preserving transformation.”
98Refactoring – Metaphors III Refactoring as health:exercises and eating a proper diet. The culture we live in. We can always make excuses, but we are only foolingourselves if we continue to ignore good behavior. Near-term and long-term benefits.
99Refactoring Main questions: What is refactoring? OK Why refactoring? When refactoring? When not? How refactoring? Why refactoring hard? Why people do not do that? XP and refactoring
100Why Refactoring Refactoring improves the design of the software fosters the examination of the software design removes duplicated code: reduces the amount of code the code says everything once and only once
101Why Refactoring Refactoring makes software easier to understand helps make your code more readable increases program comprehension: leads to higherlevels of understanding that otherwise may be missed
102Why Refactoring Refactoring helps you program fastersounds counterintuitiveless bugs, no patcheshelps correct bugs: errors need to be modifiedonly in one place
103Refactoring Main questions: What is refactoring OK Why refactoring? OK When refactoring? When not? How refactoring? Why refactoring hard? Why people do not do that? XP and refactoring
104When refactoring You have written some code. Now, if you workby XP, you should refactor it. How would you find what to refactor? What clues in the code may guide you? Fowler, chapter 3 – Bad smells in code
105When refactoringFowler, Chapter 3 – Bad smells in Code Duplicated Code: “If you see the same code structure in more than oneplace, you can be sure that your program will be betterif you find a way to unify them”. Extract Method: When you have the same expressionin two methods of the same class.
106When refactoringFowler, Chapter 3 – Bad smells in Code Long Method: “the longer the procedure is, the more difficult it is tounderstand”. Extract method: find parts of the methods that seemto go nicely together and make a new method.
107When refactoringFowler, Chapter 3 – Bad smells in Code Comments: “if you need a comment to explain what a block of codedoes, try Extract Method. If the method is alreadyextracted but you still need a comment to explain what itdoes, use Rename Method.” “when you feel the need to write a comment, first try torefactor the code so that any comment becomessuperfluous”. “a comment is a good place to say why you did something.This kind of information helps future modifiers”.
108When shouldnt you refactor? When the code is a mess and it wouldbe better to start from the beginning. Factors that will be discussed later:CultureInternal resistance
109Refactoring Main questions: What is refactoring OK Why refactoring? OK When refactoring? When not? OK How refactoring? Why refactoring hard? Why people do not do that? XP and refactoring
110How Refactoring Rasmusson (2002): “The team must refactor all thetime, to the fullest extent. When we didnt follow thisrule, the code became more cumbersome to workwith”. Most of the time it is done in small and local places Sometimes: a sequence of refactoring Refactoring requires high level of awareness All the time Two hats: adding functions and refactoring
111How refactoring Resources for specific refactoring: Refactoring Home Page: http://www.refactoring.com Martin Fowler, Kent Beck (Contributor), John Brant(Contributor), William Opdyke, don Roberts (1999).Refactoring: Improving the Design of Existing Code,Addison-Wesley. Many of the citations in this refactoring presentation are from thebook. Some IDEs (Integrated development environments)offer Refactoring menu Example: Eclipse, IntelliJ
112Refactoring Main questions: What is refactoring OK Why refactoring? OK When refactoring? When not? OK How refactoring? OK Why refactoring hard? Why people do not refactor? XP and refactoring
113Why refactoring hard? Sub-questions:Why people do not refactor naturally?Why does refactoring raise resistance?
114Why refactoring hard? Culture:“refactoring is an overhead activity. I’m paid to writenew, revenue-generating features”. “What do I tell my manager?” When it is part of XP – You do not have a problem When it is not part of XP: Don’t tell!! Treat it as part of the profession: This is how you developcode, it is not viewed by you as an additional work.
115Why refactoring hard? Internal resistance: Why are developers reluctant torefactor? (Opdyke, in Fowler’s book, p. 313) it should be executed when the code runs and all thetests pass. It seems that time is wasted now. if the benefits are long-term, why exert the effort now?In the long term, developers might not be with theproject to reap the benefits. developers might not understand how to refactor. refactoring might break the existing program.
116Refactoring Main questions: What is refactoring OK Why refactoring? OK When refactoring? When not? OK How refactoring? OK Why refactoring hard? OK XP and refactoring
117XP and Refactoring Refactoring is part of eXtreme Programming: Refactoring can be carried out without XP, but it hasadditional value with XP It has similar targets to those that XP inspires When refactoring is part of XP: refactoring becomes part of the routine it stops feeling like an overhead activity
118XP and Refactoring Mutual relationships of refactoring and other XP practicesSource: Beck, K. (2000).eXtreme Programmingexplained, Addison Wesley.
119XP and Refactoring Connection to XP practices - exampleTesting: “Whenever I do refactoring, the first step isalways the same. I need to build a solid set of tests forthat section of code. The tests are essential becauseeven though I follow refactoring structures to avoidmost of the opportunities for introducing bugs, Im stillhuman and still make mistakes.Thus I need solidtests.” (Fowler, p. 17)
120Refactoring Main questions: What is refactoring OK Why refactoring? OK When refactoring? When not? OK How refactoring? OK Why people do not refactoring? OK XP and refactoring OK
121Refactoring – Summary Refactoring requires awareness! Main Message: We should not skip refactoring. Software development is a process that cannot beenvisioned in advance. Refactoring can be performed without XP but it gets itspower from its integration with the other XP practices. Refactoring may improve programming skills.
123Conferences XP 2004: Fifth International Conference on Extreme P, June 6-10, 2004, Garmisch-Partenkirchen,Germany Agile Development Conference, June 23-26, 2004,Salt Lake City, Utah. XP Agile Universe 2004, August 2004, Calgary,Alberta, CA.
124ReferencesBeck, K. (2000). Extreme Programming Explained: EmbraceChange, Addison Wesley.Ron Jeffries, What is Extreme Programming?:http://www.xprogramming.com/xpmag/whatisxp.htmeXtreme Programming at the TechnionRoleModel:http://www.rolemodelsoftware.com/process/whatIsXp.php
126Appendices XP and the CMM XP conception of failure and success
127Why XP? – XP is a Mature Method The Capability Maturity Model for Software (CMM orSW-CMM): a model for judging the maturity of thesoftware processes of an organization and foridentifying the key practices that are required toincrease the maturity of these processes. The Software CMM has become a de facto standardfor assessing and improving software processes.
128Why XP? – XP is a Mature Method The SW-CMM has been developed by the software communitywith stewardship by the SEI. past experiences in process improvement such as TQM academic business theories practical experiences of successful projects gained from companiessuch as IBM The CMM has five levels of process capability maturity.
129Why XP? – XP is a Mature Method The first – undisciplined: processes may be loosely defined and rarely understood. estimates of cost and schedule are poor and consequently projects haveserious problems meeting deadlines and functionality requirements withinbudgets. management generally is unaware that processes exist and often makesdecisions that hurt more than help.
130Why XP? – XP is a Mature Method Level 2 - Repeatable: puts project management practices such as requirements definition,configuration management, and quality assurance in place that aredocumented and can be repeated. Level 3 - Defined: graduates the best practices of individual projects to an organizationalprocess. adds concepts of organizational training, process management, andprogram management.
131Why XP? – XP is a Mature Method Levels 4 and 5: use information and measurements defined in levels 2and 3 to understand why the process behaves the wayit does so it can be improved. Level 5: the process is mature enough to prevent defectsinstead of reacting to them and to insert new technologyand process improvements knowing exactly how theorganizational process will be affected.
132Why XP? – XP is a Mature Method The CMM has become popular around the world becauseof its ability to be applied practically to any softwareenvironment. It describes what process components should be inplace (such as recording requirements, planning andtracking activities, estimating, etc.), but not how toimplement them. eXtreme Programming fits as a framework for “how toimplement the processes”.
133XP in practice:Success and failure3 Sep, 2002: XP - An interview with Kent BeckQ: What are the issues you see your clients struggling with?KB: One of the issues is redefining failure or redefiningsuccess. For example, you think that you have a greatidea for a project, and its going to take you nine months toreally have it ready for the market. You [may] discoverafter four weeks that you are going one-tenth the speedthat you thought you would, and you cancel the project. Isthat a failure or success? In many organizations, this isperceived as a failure.
134XP in practice:Success and failure3 Sep, 2002: XP: An interview with Kent BeckKB (cont’): In the XP world, providing information that allowsyou to constantly make that decision after four or eightweeks (out of a nine-month development cycle) is whatyoure there for. In the XP world, you call that a dramaticsuccess. Now you have this cultural mismatch between howoutsiders are going to view your outcome and how you viewit inside the team. A lot of people [clients] struggle with that.They think that canceling a project is a bad thing, but I thinkthat canceling a project is a good thing -- as long as youcancel the right one.