Notes from "Extreme Programming Explained"

Summarized chapters and sections from my reading of Kent Beck's "Extreme Programming Explained". Sentiments from one a nd two-star Amazon reviews of the book. Some of my thoughts about X P as well.

keywords

software development soft-skills reviews

2021-02-02

Notes from the book
Criticism from Readers
My thoughts (as a "Joe-Schmoe")

Chapter 1 - What is XP?

Distinguishing features:

Short development cycles, early feedback
Overall plan expected to evolve over the life of the project
Reliance on automated tests, oral communication, and source code to communicate system details
Close collaboration of team members
Only do the minimum required thing to deliver value
Understand and accept that people are imperfect
A high level of technique is required to build trust
Always keep the system in a deployable state

Beck says that success comes out of both good relationships as well as technique.

Chapter 2 - Learning to Drive

Everything involved in software development is constantly changing. Change is not the problem, the real problem is the inability to cope with all of the different things that will change.

Stay aware of the ever-changing project requirements and be able to adapt your work to meet the needs.

Customers don’t usually have a clear idea of what the software should do.

Chapter 3 - Values, Principles, and Practices

Practices are the things that programmers do daily (eg. pair programming).

Values are defined as “the roots of the things we like and don’t like in a situation.”

Values give purpose to the practices (eg. well-being, work-life balance, communication).

Principles are the guidelines that connect practices with values (eg. quality work, rapid feedback).

Chapter 4 - Values

People have different ideas and views about what things are important when it comes to building software. What matters most is that the people involved come to an agreement about what things to follow. So, it’s not any one person’s individual ideas and views that are important, but that everyone is focused on the same values.

XP suggests at least five values that teams can focus on. Each team or organization may have a few more.

Communication

Communication is kind of self-explanatory to me.

Simplicity

It is difficult to find simple solutions to problems. Bias your thinking toward eliminating wasted complexity. Less communication is needed when simple solutions are preferred.

Feedback

The goal should be more about steady improvement than instant perfection. The perfect solution is almost always an unachievable goal.

Strive to generate feedback early and often. Feedback comes from peers, customers, and project stakeholders.

Respect

All of the previously mentioned values point to respect and care for each other and for the success of the project.

Courage

I don’t really understand what this one means.

Chapter 5 - Principles

Software development practices should be guided by underlying principles. Principles clarify what practices are intended to accomplish.

The following principles are likely to be applicable to all software development projects.

Humanity

Good developers need these basic things in the work environment:

Sense of basic safety
Sense of accomplishment
Sense of belonging
Ability to grow
Ability to be understood by peers and vice versa

Economics

Prioritize solving the highest priority business needs first. Doing so will avoid achieving just a mere “technical success” at the end of a project.

Software that can be easily reused carries more economic value than software that can only be used for the original purpose.

Mutual Benefit

Beware of solutions and practices that are only beneficial at the cost of others. Strive for practices that benefit all three groups:

Yourself
The team
The customer

Beck provides an example of a not-so-good practice, which is writing extensive internal documentation:

“I am supposed to slow down my development considerably so some unknown person in a potential future will have an easier time maintaining this code. I can see a possible benefit to the future person should the documentation still happen to be valid, but no benefit now.”

Beck suggests a better solution, which is to write an automated test instead. The author of the test benefits from the practice, as does the team, both at the present time, as well as in the future. The test also serves as reliable documentation.

Improvement

Do the best work that you can do right now, and then gradually improve upon it as time goes on.

Diversity

Diversity fosters healthy conflict within teams. It surfaces more options to consider when problem solving.

Team members must know how to handle conflict productively, and how to treat each other with respect.

Reflection

Take time to ask how and why things are (or are not) going well.

Analytical data can help with reflection, but senses and emotions are also valid things to consider.

Good teams are open to sharing their mistakes so that they can learn from them.

Flow / Baby Steps

Try to deliver features frequently, and at a steady interval.

Too much change taken at once is dangerous for the project. Team members should instead work in baby steps. There is overhead to working in baby steps, but it’s worth it.

Opportunity / Failure

Failure is not wasted so long as it results in knowledge. Try to fail fast when possible.

Approach problems or struggles as learning opportunities.

Redundancy

It’s not wise to try to solve certain problems in software development with one solution alone. For certain problems, it’s better to have multiple practices in place.

Quality

Individuals need to do work that they can be proud of.

It’s wrong to think that a project will move faster if the quality is decreased. Project scope, not quality, should be leveraged as a control variable.

Accepted Responsibility

Responsibility cannot realistically be given out – it’s only accepted or not accepted.

The practices one follows tends to indicate which responsibilities they have accepted.

Chapters 6 & 7 - Practices

Practices are the things programmers likely do every day.

They don’t amount to anything without being tied to values and principles.

Sit Together

Sitting together has potential to enhance communication.

Whole Team

This practice can also be considered cross-functional teams. People should be grouped into teams based on the skills needed for a project to succeed.

Energized Work

Working more hours does not usually result in more value added to a project. Choose to work more efficiently, and with more focus, rather than working more hours.

A rested and relaxed mind will produce software that is more valuable.

Pair Programming

Write code in pairs to see benefits such as:

Staying on task easier
Quick brainstorming and idea clarification
Less frustration from getting stuck on a problem
Encouragement to follow the team’s practices

Stories

Plan work that relates directly to customer-visible functionality.

Weekly Cycle

Main goals of sprint planning meeting includes:

Review the previous week’s progress
Pick stories to implement
Break stories into tasks, and let team members sign up for them and estimate them.

Try to reduce the amount of time spent planning as the project progresses.

Quarterly Cycle

Spend time reflecting as a team. Find and discuss any bottlenecks. Pick some goals to focus on during the quarter.

Slack

Not Slack the app 🙃.

Don’t commit to unrealistic goals.

Ten-Minute Build

The ideal goal is to have:

Automatic builds…
which cover the whole system…
and take no more than 10 minutes to run.

Continuous Integration

Writing software as a team isn’t strictly a “divide and conquer” problem. It is more like “divide, conquer, and integrate”.

Integration can often be unpredictable and take longer than expected.

Test-First Programming

Write a failing test before changing or adding code. It will help solve problems such as:

Scope creep, because the test passing is your primary indicator to help you know when you are finished.
Code coupling / cohesion, because a test that is a pain to write may be a sign that the code is too coupled or not cohesive enough.
Trust, because it becomes clear to see that the code indeed works.
Rhythm, because the pattern of, “Write a test, make it pass”, makes programming more of a step-by-step process.

Incremental Design

Refactor and design the system system on a daily basis to avoid creating something that is devastatingly difficult to change.

Chapter 8 - Getting Started

Begin XP by being aware of the need for change. Awareness comes via feelings, and metrics (trends in data).

The best way to start doing XP is one practice at a time. Choose practices based on which values and goals you want to realize.

Team leaders should not dictate XP practices. XP won’t be effective unless team members choose to be “on board”.

Mapping the Practices

An exercise for discovering what various practices mean to the team is to:

Write down the practice.
List the purpose of following the practice.
List the factors that go into the practice.
List “waste” or negative things that will be expelled by following the practice.

Example:

Chapter 9 - Corollary Practices

These are secondary practices to follow, once the primary ones are implemented.

Real Customer Involvement

Involve end-users in the design and development of the system you’re working on.

Incremental Deployment

Whenever possible, find a way to deploy functionality incrementally rather than all at once.

Root-Cause Analysis

Respond to defects by putting tests in place such that it’s not likely to happen again. Once resolved, try to figure out the root cause.

A proposed method for doing so is to first ask why a defect occurred. Then ask why again based on the response. Do this five-levels deep to discover the root-level cause.

Shared Code

Avoid having people that only work on certain parts of the system. Each programmer on the team should be comfortable enough to improve any part of the system.

Single Code Base

It’s better to have just one main branch. Feature branches, where programmers introduce change, should be very short-lived.

If there’s an underlying design problem that is causing you to have multiple code bases, fix that issue instead.

Chapter 10 - The Whole XP Team

Prioritize stories based on business value, and not for technical reasons.

Chapter 11 - The Theory of Constraints

See the Wikipedia entry.

Chapter 12 - Planning: Managing Scope

Planning is like buying groceries.

Items are stories
Prices are estimates
Your budget is the amount of time you have available

Chapter 13 - Testing: Early, Often, and Automated

Software defects destroy trust. Testing software is an investment into healthy teamwork. Testing is as important as programming.

Both defects as well as time spent planning can be considered a cost. There are two principles in XP that can help increase the effectiveness of removing defects.

Double-checking
Defect Cost Increase

Double-checking refers to the idea that if you approach a problem from two different ways, reaching the same result for both cases, then it’s all the more likely that the solution is correct.

This idea can be applied to software by writing tests, which is a lot different than writing the code. Writing tests and writing code are two distinct ways to double-check that the code is doing what you expect it to do.

Defect Cost Increase says that it’s much easier to fix defects sooner than later. That’s because it’s difficult to dig up the history and context of the code in question when defects are discovered later on.

Chapter 14 - Designing: The Value of Time

“Design always”, is the XP motto.

Designing is intended to be a daily practice in XP.

Designing software is often compared to constructing buildings - but that’s not a very good comparison. Software needs to continue running as usual while it’s continuously being modified and updated.

Designing is a continuous feedback cycle. Design in small iterations so that feedback can be collected and utilized to continue designing further.

Good software designers must balance several different factors to determine when to design:

It may be better to design upfront (sooner) when “pure thought creates most of the value without feedback”.
It may be better to design “just enough” when it’s experience and feedback that creates most of the value.

Design ties into trust. Weekly delivery of requested functionality is almost always the most important priority to the customer. So, remember that “the perfect design” is lower on the priority list than maintaining trust and good relationships within the team.

Chapter 15 - Scaling XP

Scaling doesn’t always have to refer to the amount of people. Other ways projects can scale include:

Time
Investment
Complexity

Steps suggested to approach a big problem:

Break into smaller problems.
Implement simple solutions.
Implement complex solutions if there are remaining problems to solve.

Integrate the solutions to the smaller problems often to reduce the risks of two solutions not working well together.

Chapter 18 - Taylorism and Software

Separation of QA and development sends the message that developers cannot be trusted to uphold the quality of their own work, or that it’s not the job of the developers to do quality work.

Chapter 20 - Applying XP

Seeing results from applying XP can take a long time.

Adopting XP as a style of software development will not automatically eliminate your problems. It will, however, provide a new way to go about solving them.

Leading by example is a powerful way to start applying XP.

Quick adoption of XP is more likely to happen if the team members are all willing to accept the changes.

Chapter 21 - Purity

It’s wrong to consider a team or organization is doing enough to truly be considered as “Extreme”, as if it’s some kind of club membership that you need a high enough score to get into.

The question or goal should be more along the lines of, Are our relationships and projects satisfying and successful?

Chapter 25 - Conclusion

Integrity is key to XP. Figure out what your values are, and act in harmony with them.

Criticism from Readers

These are some criticisms, taken from one and two-star reviews of the book.

The book is based on opinions and theories and lacks research.
The book reads like a gossip magazine fad diet plan.
The book presents a lot of ideas, but lacks clear explanation of how to implement them.
Many readers claim that there are better books out there which present some of the same ideas (“The Pragmatic Programmer”, “Rapid Development”, “Code Complete”, “After the Gold Rush”).

My Thoughts About XP (as a “Joe-Schmoe”)

I agree with most of the values, principles, and practices defined by the XP methodology, but with a grain of salt.

I love the idea of having clearly defined values, principles, and practices in place. Simply having those kind of things, whether defined by XP or not, is important for software development teams and organizations.

I think the extent to which XP should be applied is highly situational. As Kent Beck states in the book, adapting XP should be something that the team actually believes in and wants to do in order to be successful. Also, I think that the type of product that the team is working on can make a difference in how effective XP is.

At the time of writing this, I am doing some of the practices which are outlined in the book, but not always to the full extent.

I definitely identify as an introvert, yet I enjoy pair programming. I pair with each member of my team for at least two hours each week. This totals up to about eight hours of pair programming for me. I wouldn’t mind doing it more often.

I like to learn from other people’s approach to solving problems. My team members benefit from talking through ideas and figuring out solutions together. I find that it’s easier to stay on task.

I agree that tests are just as important as production code, however I’ve yet to live up to the standard that a test should be written first if I’m being completely honest. There are times when I can effectively do it, but it’s not often.

I find that simply having a test (the right kind of test) is more important than focusing on how it is written. I can appreciate tests for three main reasons:

Gives me confidence to refactor.
Provides a little more documentation about the intent of the code.
Demonstrates that the application does the thing that it was intended to do.

One thing I strongly agree with hits on a few different principles mentioned in the book: Flow, Baby Steps, and Improvement. I see these principles manifest in things like:

Small pull requests that change or add one thing.
Clearly defined tasks that describe one thing.
Simple code that does that does the bare minimum to satisfy requirements.

The reason I agree with these principles is because it makes teamwork easier and provides opportunity for feedback more regularly. It’s easier to review small changes to the code. Small, well-defined tasks are easier to complete.

To wrap my thoughts up, I generally think XP has a lot of valuable advice to consider. It’s important to figure out what values and principles matter the most to you and your team. I will be applying more of the principles into my life to form some stronger opinions.