Chapter 1: What is XP?

Excerpted from “Extreme Programming Explained” by Kent Beck. The author states that:

XP is focused on the excellent application of:

• Programming techniques
• Clear communication
• Teamwork

XP includes:

• A PHILOSOPHY of SW development based on the the VALUES of communication, feedback, simplicity, courage, and respect.

• A body of PRACTICES proven useful in improving SW development. The practices complement each other, amplifying their effects. They are chosen as expressions of the VALUES.

• A set of complementary PRINCIPLES, intellectual techniques for translating the VALUES into PRACTICE, useful when there isn’t a practice handy for your particular problem.

• A COMMUNITY that shares these VALUES and many of the same PRACTICES.

XP is a path to excellence for people coming together to develop SW. It is distinguished from other methodologies by:

• Short development cycles, resulting in early, concrete, and continuing feedback.

• An incremental planning approach, which quickly comes up with an overall plan that is expected to evolve through the life of the project.

• The ability to flexibly schedule the implementation of functionality, responding to changing business needs.

• Reliance on automated tests written by programmers, customers, and testers to monitor progress of development, to allow the system to evolve, and to catch defects (bugs) early.

• Reliance on oral communication, tests, and source code to communicate system structure and intent.

• Reliance on an evolutionary design process that lasts as long as the system lasts.

• Reliance on the close collaboration of actively engaged individuals with ordinary talent.

• Reliance on practices that work with both the short-term instincts of the team, and the long term interests of the project.

The author describes XP this way:

• XP is lightweight. In XP, you only do what you need to do to create value for the customer. You can’t carry a lot of baggage and move fast. However, there is no freeze-dried SW process. The body of technical knowledge required to be an outstanding team is large and growing.

• XP is a methodology based on addressing constraints on SW development. It does not address project portfolio management, financial justification of projects, operations, marketing, or sales. XP has implications in all of these areas, but does not address these practices directly. Methodology is often interpreted to mean “a set of rules to follow to guarantee success.” Methodologies don’t work like programs. People aren’t computers. Every team does XP differently with varying degrees of success.

• XP can work with teams of any size. XP has been put into use in a wide range of projects and has been successful for both large and small projects and teams. The values and principles behind XP are applicable at any scale. The practices need to be augmented and altered when many people get involved.

• XP adapts to vague or rapidly changing requirements. XP is still good for this situation, which is fortunate because requirements need to change to adapt to rapid shifts in the modern business world. However, teams have also successfully used XP where requirements don’t seem volatile, like porting projects.

The author claims that XP addresses risk at all levels of SW development:

• Schedule slips: XP calls for short release cycles, a few months at most, so the scope of any slip is limited. Within a release, XP uses one-week iterations of customer-requested features to create fine-grained feedback about progress. Within an iteration, XP plans with short tasks, so the team can solve problems during the cycle. Finally, XP calls for implementing the highest priority features first, so any features that slip past the release will be of a lower value.

• Project cancellation: XP asks the business-oriented part of the team to choose the smallest release that makes the most business sense, so there is less that can go wrong before deploying, and the value of the SW is greatest.

• System goes sour: XP creates and maintains a comprehensive suite of automated tests, which are run and rerun after every change (many times a day) to ensure a quality baseline. XP always keeps the system in a deployable condition. Problems are not allowed to accumulate.

• Defect rate: XP tests from the perspective of both programmers writing tests function-by-function and customers writing tests program-feature-by-program-feature.

• Business misunderstood: XP calls for business-oriented people to be first-class members of the team. The specification of the project is continuously refined during development, so learning by the customer and the team is reflected in the SW.

• Business changes: XP shortens the release cycle, so there is less change during the develpment of a single release. During a release, the customer is welcome to substitute new functionality for functionality not yet completed. The team doesn’t even notice if it is working on newly discovered functionality or features defined years ago.

• False feature rich: XP insists that only the highest priority tasks are addressed.

• Staff turnover: XP asks programmers to accept responsibility for estimating and completing their own work, gives them feedback about the actual time taken so their estimates can improve, and respects those estimates. The rules for who can make and change estimates are clear. Thus, there is less chance for a programmer to get frustrated by being asked to do the obviously impossible. XP also encourages human contact among the team, reducing the loneliness that is often at the heart of job dissatisfaction. Finally, XP incorporates an explicit model of staff turnover: new team members are encouraged to gradually accept more and more responsibility, and are assisted along the way by each other and by existing programmers.

The author then states a collection of assumptions that XP makes:

• XP assumes that you see yourself as part of a team, ideally one with clear goals and a plan of execution.
• XP assumes that you want to work together.
• XP assumes that change can be inexpensive using this method.
• XP assumes that you want to grow, to improve your skills,and to improve your relationships.
• XP assumes that you are willing to make changes to meet those goals.

Finally, the author summarizes XP this way:

• XP is giving up old, ineffective technical and social habits in favor of new ones that work.
• XP is fully appreciating yourself for total effort today.
• XP is striving to do better tomorrow.
• XP is evaluating yourself by your contributions to the team’s shared goals.
• XP is asking you to get some of your human needs met through SW development.

We will first discuss XP (as described above) in relation to the Waterfall Model example to be presented in the previous lecture, assuming that XP could be applied to that project.

The author makes a lot of claims about XP, as well as states many qualities that XP possesses, including addressing human factors. He makes it sound like a lifestyle. Discuss your reaction to what the author has to say in the first chapter about XP?

The author makes this statement about estimates and expectations, “If you have six weeks to get a project done, the only thing you control is your own behavior. Will you get six weeks’ worth of work done, or less? You can’t control others’ expectation. You can tell them what you know about the project so that their expectations have a chance of matching reality. My terror of deadlines vanished when I learned this lesson. It’s not my job to “manage” someone else’s expectations. It’s their job to manage their own expectations. It’s my job to do my best and to communicate clearly.”

Who determines how much work is “six weeks’ worth of work”? What if your manager (or your professor) imposes unreasonable/impossible deadlines on you (and/or your team)? How do you put the author’s statement into practice? There is an inherent conflict here, and imbalance of “power”, skewed far to side of the manager. What do you do to deal with it? How should a team that is responsible for setting its own estimates deal with the rejection of those estimates?

Chapter 2: Learning to Drive

Chapter 2 is all about accepting and adapting to change. The author states, “everything in SW changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn’t change, because change is going to happen; the problem, rather, is our inability to cope with change.”

XP follows the premise that customers, internal or external, drive change, and that they should not only be “allowed” to drive change, but should be encouraged to drive change, and that they are an integral part of the XP team.

CHAPTER 3: Values, Principles, and Practices

The author treats programming as a social skill, at times. He discusses how principles are the bridge between values and practices.

What does he mean by “values”, “principles”, and “practices”?

CHAPTER 4: Values

The author states that XP embraces the following 5 values:

• Communication
• Simplicity
• Feedback
• Courage
• Respect

How do you portray those values in your SW development, or other coursework?

COMMUNICATION: I’ll give an example from my work experience.

How do you see communication being used in your group project development?

SIMPLICITY: I’ll give an example from my work experience.

How do you go about simplifying your code (your solution to the problem)?

FEEDBACK: The author states that XP strives to generate as much feedback as possible.

What constitutes feedback? How do you encourage/generate feedback?

COURAGE: The author states that “courage” is effective action in the face of fear.

Give some examples of courage that you have exhibited during you collegiate career - times when you have confronted and conquered your anxiety/fear.

RESPECT: I’ll give an example from my work experience.

Identify instances of respect and disrespect that you’ve encountered during your collegiate career. This could be from students, professors, or from a coop experience. Please don’t use real names.

OTHERS:

Are there any other values you think are essential to successful SW development in a team environment?

CHAPTER 5: PRINCIPLES

The author states that XP is guided by the following principles:

• Humanity
• Economics
• Mutual Benefit
• Self-Similarity
• Improvement
• Diversity
• Reflection
• Flow
• Opportunity
• Redundancy
• Failure
• Quality
• Baby Steps
• Accepted Responsibility

From a team-oriented SW development standpoint, order those from highest to lowest in terms of importance.

HUMANITY: The author states the following as being essential in order to be a good developer:

• Basic Safety - freedom from hunger, physical harm,and threats to loved ones. Fear of job loss threatens this need.

• Accomplishment - the opportunity and ability to contribute to their society.

• Belonging - the ability to identify with a group from which they receive validation and accountability and contribute to its shared goals.

• Growth - the opportunity to expand their skills and perspective.

• Intimacy - the ability to understand and be understood deeply by others.

What has your developmental environment been like while you’ve been at York College - collaboration, socialization, friendships, partnerships? In what ways do you expect those areas to carry over into your career. What is essential to you for a happy, successful, and fulfilling career?

The author clearly states what he feels should and shouldn’t be discussed/shared with team members. He says that private matters should remain private and not revealed to the team. On the other hand, you will spend a lot of time working closely with the people on your team - many will become friends, and even close/lifelong friends. What is your reaction to what the author has to say about those types of discussions?

ECONOMICS: Essentially, all commercial SW development comes down to money - how much the ROI (return on investment) will be.

How do you perceive that statement will affect/drive your career decisions?

MUTUAL BENEFIT: The author implies that it is generally not worthwhile to invest time in documenting for the future - future team members, future features, future releases That the documentation should be implicit in the code, the tests, the comments, the names.

What is your reaction to that? Can you think of examples that would require more explicit documentation - for instance, how do you convey information to members of an XP team who aren’t developers? How do you keep record of team decisions - how do you pass on designs to new team members?

SELF-SIMILARITY: The author states that the team should always be on the lookout for code and processes that are similar - and can be used at different scales. If you can abstract functionality from different parts of your design into common code - then only one instance of the code must be maintained and tested.

IMPROVEMENT: The author states that the team should always be seeking ways to improve the code. It is not possible to come up with a perfect design, or perfect processes - but it is possible to continue to perfect the design, the code, and the process. XP calls for excellence through improvement.

If the team is constrained for time, but comes across an improvement, how does it decide whether to spend time refactoring the code, implementing the improvement? How do they justify that?

How do you feel about the phrase, “best is the enemy of good enough”? Under what circumstances is “good enough” sufficient - meaning that even an obvious improvement should not be implemented?

DIVERSITY: With a diversity of knowledge, skills, and experience, comes a diversity of opinion on approaches and solutions.

How can this diversity be utilized in a positive way? How do you propose to reach a common approach/solution?

REFLECTION: Honest reflection (review) of one’s individual work (successes and failures) as well as that of the team, leads to improvement - both by sharing what has worked, and by recognizing and sharing mistakes, rather than hiding them (learning from one’s own mistakes, as well as the mistakes of others).

FLOW: The author states that more smaller chunks of development are better than fewer large chunks of development. The team see a steady flow of progress towards success. Flow would be when you finally understand the assignment, have assembled it in your head, and can make steady, uninterrupted progress towards it - think Mandelbrot in CS201.

How do you feel at the beginning of an assignment, and how does that change over time as you finally understand the problem and know how to make progress? How have you felt when you have just completed a tough assignment, and then had to start on a new and completely different assignment right away? Would you prefer more smaller assignments, or fewer bigger assignments?

OPPORTUNITY: The author states that you should learn to see problems as opportunities for change - continue learning beyond just enough to get by with solving the problem. Problems should be used as opportunities for learning and improvement, rather than viewed only as “survival”.

How do you identify opportunity in a problem? Think about the upcoming group and individual projects.

REDUNDANCY: The author states that critical problems in SW development should be solved in multiple ways.

I also emphasized that approach in CS201. Why continue looking for solutions after one is identified?

FAILURE: We learn from our failures until we reach success.

How have you learned from failure in CS201, or some other engineering course?

QUALITY: The author states that projects don’t go faster by accepting lower quality - a poor design, more “acceptable” defects, less testing. This is also my experience - that lack of quality comes back to haunt you late in the project, or sucks time away from you after a release.

Define quality in terms of you own SW development experience. What does quality mean to you?

BABY STEPS: Take many small steps in development, rather than a few larger steps. Complete small chunks more quickly and integrate them into the code base.

Reflect on your SW development efforts in CS101 and CS201. Did you ever experience writing too much code, and then struggling to get it to work? When you worked on Klondike, it was a large, complex project, but was broken into small testable pieces. How did that development go for you?

ACCEPTED RESPONSIBILITY: The author states that no one can assign responsibility to you - it is up to you to accept responsibility. He gives an example that if a team member signs up for a task, they also accept for responsibility for estimating it.

The author’s premise is that you sign up for the work you are going to do. What if work is assigned to you? Does the author’s point still hold?

Excerpted from “Extreme Programming Explained” by Kent Beck.

Chapter 6: Practices

The author breaks up the various practices of XP into Primary and Corollary Practices. Practices are the application of the principles of XP. We are going to discuss the Primary Practices.

Chapter 7: Primary Practices

SIT TOGETHER: Frequent (constant) communication is a primary component of XP. Th author proposes that teams must be co-located, in an open space, to foster communication and collaboration. But he also recognizes that everyone needs a certain amount of privacy - either by providing small private spaces nearby, or by limiting work hours.

The author also suggests that this kind of work environment should be eased into - rather than having it suddenly thrust upon people who are used to having a sense of privacy and ownership of a space.

My experience is only with private offices and cube “farms”. Corporate HQ for my previous employer was looking at mandating this kind of layout - open collaborative spaces, with small private areas, but with low cube walls that did not provide the privacy that we were all used to. Many people raised a big uproar over having this kind of layout thrust upon us. Fortunately, our local management solicited our input, recognized the issues, and the transition was shelved for the immediate future.

Have you done school work in this kind of environment - labs and assignments in CS101 and CS201, or other classes? Which do you prefer, working alone, or working in a group? Which do you find to be more productive?

WHOLE TEAM: The author discusses identifying with the team, rather than with the function. Teams should be comprised of people with a diversity of skills that covers the needs of the project. The team may need to be dynamic, as requirements change and as tasks are completed, and new ones started. But the author does emphasize that team members should be dedicated to the team - not splitting their time between multiple teams or functions.

What experience do you have with being a member of a team - whether it is a sports team, a robotics team, or a team of developers?

Do you like to concentrate on one thing exclusively, or do like to mix things up, and have a diversity of problems to solve?

INFORMATIVE WORKSPACE: The author proposes a layout for team workspaces, including posting regular information on the status of the project in visual form - contributing to team identity and cohesion.

When you look at the suggest workspace layout, how would you feel about your privacy, with the collaborative workstations sitting directly behind your private space?

What expectations do you have for privacy when you enter the workforce?

ENERGIZED WORK: At least three times, the author mentions limiting work hours as a way to foster productivity. He mentions a penchant for working long hours in this profession, but also states that SW development is a game of insight, and insight takes a prepared, rested, relaxed mind.

When you are solving problems, working on a SW assignment, or an engineering project, how do you like to work - in long stretches, or in smaller chunks with breaks in between?

How do you think a manager will react to the author’s limited work hours suggestion?

How would you feel about working 40, 60, or even 80 hours per week, when your co-workers/teammates are putting in less hours than that?

What are your expectations for the length of a work week?

PAIR PROGRAMMING: The author states, “Write all production programs with two people sitting at one machine.” The author also talks about how intense and tiring pair programming can be, and also mentions that pairs should rotate partners every couple of hours, to as frequently as every 30 minutes for difficult problems.

What are the advantages of this approach?

What disadvantages do you see?

How do you think this practice would work for you?

STORIES: Stories describe customer-visible functionality, i.e., functionality the customer expects to see. They do not describe what goes on in the background, or any level of implementation. The author eschews the term “requirement” - estimating that as little as 5% of requirements are really necessary for acceptable operation of the system. Stories can also be used to break up the problem into its essential pieces, and then can be used to estimate and prioritize the work.

What stories will you come up with for your project?

How will you come up with a complete enough set of stories that adequately describe the work you need to do, and how will you prioritize them?

WEEKLY CYCLE: The author suggests planning work a week at a time. Have the customer pick a week’s worth of stories - thus, the customer is providing the priority list for the work to be done that week. The author also suggests creating a stack of stories for that week, preferably small stories that require only a single developer - or pair of developers for pair programming - and have people pull from the top of the stack so that they get a variety of tasks.

How will you decide which stories to implement each week, and how will you assign those tasks to the members of your team?

How will you recognize if you are behind schedule, and what will you do to compensate if your schedule slips?

SLACK: The author suggests building slack into the schedule - including some minor tasks that can be dropped if the team falls behind. He discusses having team members only sign up for what they feel they can truly deliver, rather than overcommit to tasks, which can result in inefficient and wasteful development practices.

How will you prioritize your tasks, in case you overcommit (which is almost inevitable for a project like this)?

How would you deal with a manager (or management culture) that fosters overcommitment, thus requiring long working hours?

TEN-MINUTE BUILD: The author suggest building frequently, to receive timely feedback on the state of the system for all team members. He suggests that the build be maintained at ten minutes, since a build that takes a long time will be used less frequently, resulting is less feedback. He gives suggestions on how to limit the time of the build, but also states that the build time must also include automated unit tests.

Your project will likely not take anywhere near 10 minutes to build and test. But, how often will you decide to execute a build and run your automated tests?

CONTINUOUS INTEGRATION: The author suggests that integration and testing of changes should occur no more than every couple of hours. Integration of new code can be difficult and time-consuming. The larger the chunk of code, the more problematic it can be to integrate - introducing a large defect load to correct before moving forward. Individual team members (or pair programmers) generally work with their own local copy of the code, and then integrate by merging it into the master repository for the project, which is then followed soon after by a build.

As each member of your team works on their own tasks, how often will you integrate their code, build, and test the system?

TEST-FIRST PROGRAMMING: The author suggests writing automated tests that will fail, before changing any code. You saw this with Klondike in CS201, and with the programming questions on the CS201 exams. He lists several benefits of test-first programming, including limiting scope creep and coupling and cohesion of the code.

What advantages do you see to test-first programming?

Do you plan to use it in your project, given your experience with CS201?

INCREMENTAL DESIGN: The author suggests investing in the design of the system every day. The primary point of this section is that “design is necessary, the question is when to design, and how much?” The orthodox view, for decades, has been to design as much as possible up front, before any coding starts. The idea has been to fully understand the system before coding it, and minimize/eliminate the need for changes after the design is created. History and experience have shown that this goal is basically unattainable, and is inherently wasteful. Design done close to use is more efficient, as there is a better understanding of the system, as it has come to exist at that time.

The author talks about the need to refactor code as part of incremental design. What is refactoring? What are its benefits? What are its costs?

How do you identify when to design, and how much to design?

---

---