//about quality
Quality is another strange variable. Often, by insisting on better quality you can get projects done
sooner, or you can get more done in a given amount of time. This happened to me when I started
writing unit tests (as described in Chapter 2, A Development Episode, page 7). As soon as I had
my tests, I had so much more confidence in my code that I wrote faster, without stress. I could
clean up my system more easily, which made further development easier. I've also seen this
happen with teams. As soon as they start testing, or as soon as they agree on coding standards,
they start going faster.

//Interactions Between the Variables
There is a human effect from quality. Everybody wants to do a good job, and they work much
better if they feel they are doing good work. If you deliberately downgrade quality, your team might
go faster at first, but soon the demoralization of producing crap will overwhelm any gains you
temporarily made from not testing, or not reviewing, or not sticking to standards.

//Learning to drive
I jerked back to attention as the car hit the gravel. My mom (her courage now amazes me) gently
got the car back straight on the road. Then she actually taught me about driving. "Driving is not
about getting the car going in the right direction. Driving is about constantly paying attention,
making a little correction this way, a little correction that way."
//ejemplo coche iba centrao en ir recto y su madre le dijo que es ir arreglando las cosas poco a poco
This is the paradigm for XP. There is no such thing as straight and level. Even if things seem to be
going perfectly, you don't take your eyes off the road. Change is the only constant. Always be
prepared to move a little this way, a little that way. Sometimes maybe you have to move in a
completely different direction. That's life as a programmer
Everything in software 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, per se, because change is going to happen; the problem, rather, is the inability to
cope with change when it comes.

//4values
//Communication

The first value of XP is communication. Problems with projects can invariably be traced back to
somebody not talking to somebody else about something important. Sometimes a programmer
doesn't tell someone else about a critical change in the design. Sometimes a programmer doesn't
ask the customer the right question, so a critical domain decision is blown. Sometimes a manager
doesn't ask a programmer the right question, and project progress is misreported.

//Simplicity

XP is making a bet. It is betting that it is better to do a simple thing today and pay a little more
tomorrow to change it if it needs it, than to do a more complicated thing today that may never be
used anyway.
Simplicity and communication have a wonderful mutually supporting relationship. The more you
communicate, the clearer you can see exactly what needs to be done and the more confidence
you have about what really doesn't need to be done. The simpler your system is, the less you have
to communicate about, which leads to more complete communication, especially if you can
simplify the system enough to require fewer programmers.

//Feedback

Most projects seem to have exactly the opposite strategy. The thinking seems to go, "As soon as
the system is in production, you can no longer make 'interesting' changes, so keep the system in
development as long as possible."
This is exactly backwards. "In development" is a temporary state, one that the system will only be
in for a small percentage of its life. Far better to give the system independent life, to make it stand
and breathe on its own. You are going to have to live with supporting production and developing
new functionality simultaneously. Better to get used to juggling production and development
sooner rather than later.


Concrete feedback works together with communication and simplicity. The more feedback you
have, the easier it is to communicate. If someone has an objection to some code you have written
and they hand you a test case that breaks it, that is worth a thousand hours of discussion about
design aesthetics.

//Courage

Another courageous move is throwing code away. You know how sometimes you work all day on
something, and it isn't going very well, and the machine crashes? And how the next morning you
come in and in half an hour reconstruct all of the previous day's work but clean and simple this
time?
Use this. If the end of the day is coming and the code is a little out of control, toss it. Maybe save
the test cases, if you like the interface you've designed, but maybe not. Maybe just start over from
scratch.

//the values in practice
The Values in Practice
I asked the C3 team (that first big XP project I mentioned earlier) to tell me stories about their
proudest moment on the project. I was hoping to get stories about big refactorings, or being saved
by tests, or a happy customer. Instead, I got this:
The moment I was proudest of was when Eddie moved to a job closer to home,
avoiding a two-hour daily commute, so he could spend more time with his family.
The team gave him total respect. Nobody said a word against him leaving.
Everybody just asked what they could do to help.
This points to a deeper value, one that lies below the surface of the other four—respect. If
members of a team don't care about each other and what they are doing, XP is doomed.

//basic principles
Assume simplicity—Treat every problem as if it can be solved with ridiculous simplicity. The time
you save on the 98% of problems for which this is true will give you ridiculous resources to apply
to the other 2%. In many ways, this is the hardest principle for programmers to swallow. We are
traditionally told to plan for the future, to design for reuse. Instead, XP says to do a good job (tests,
refactoring, communication) of solving today's job today and trust your ability to add complexity in
the future where you need it. The economics of software as options favor this approach.

Open, honest communication—This is such a motherhood statement that I almost left it out. Who
wouldn't want to communicate openly and honestly? Everybody I visit, it seems. Programmers
have to be able to explain the consequences of other people's decisions, "You violated
encapsulation here and it really messed me up." They have to be able to tell each other where
there are problems in the code. They have to be free to express their fears, and get support. They
have to be free to deliver bad news to customers and management, to deliver it early, and not be
punished

//back to basics
I remember when I first learned to program in BASIC. I had a couple of workbooks covering the
fundamentals of programming. I went through them pretty quickly. When I had done that, I wanted
to tackle a more challenging problem than the little exercises in the books. I decided I would write
a Star Trek game, kind of like one I had played at the Lawrence Hall of Science in Berkeley, but
cooler.
My process for writing the programs to solve the workbook exercises had been to stare at the
problem for a few minutes, type in the code to solve it, then deal with whatever problems arose. So
I sat confidently down to write my game. Nothing came. I had no idea how to write an application
bigger than 20 lines. So I stepped away and I tried to write down the whole program on paper
before typing it in. I got three lines written before I got stuck again.

When you code something up, you also have an opportunity to understand the best structure for
the code. There are certain signs in the code that tell you that you don't yet understand the
necessary structure.
Code also gives you a chance to communicate clearly and concisely. If you have an idea and
explain it to me, I can easily misunderstand. If we code it together, though, I can see in the logic
you write the precise shape of your ideas. Again, I see the shape of your ideas not as you see
them in your head, but as they find expression to the outside world.
This communication easily turns into learning. I see your idea and I get one of my own. I have
trouble expressing it to you, so I turn to code, also. Since it is a related idea, we use related code.
You see that idea and have another.

Fortunately, there is a short-term reason to write tests. Programming when you have the tests is
more fun than programming when you don't. You code with so much more confidence. You never
have to entertain those nagging thoughts of "Well, this is the right thing to do right now, but I
wonder what I broke." Push the button. Run all the tests. If the light turns green, you are ready to
go to the next thing with renewed confidence.
I caught myself doing this in a public programming demonstration. Every time I would turn from the
audience to begin programming again, I would push my testing button. I hadn't changed any code.
Nothing in the environment had changed. I just wanted a little jolt of confidence. Seeing that the
tests still ran gave me that

//quick overview
 The Planning Game—Quickly determine the scope of the next release by combining
business priorities and technical estimates. As reality overtakes the plan, update the plan.
● Small releases—Put a simple system into production quickly, then release new versions on
a very short cycle.
● Metaphor—Guide all development with a simple shared story of how the whole system
works.
● Simple design—The system should be designed as simply as possible at any given
moment. Extra complexity is removed as soon as it is discovered.
● Testing—Programmers continually write unit tests, which must run flawlessly for
development to continue. Customers write tests demonstrating that features are finished.
● Refactoring—Programmers restructure the system without changing its behavior to remove
duplication, improve communication, simplify, or add flexibility.
● Pair programming—All production code is written with two programmers at one machine.
● Collective ownership—Anyone can change any code anywhere in the system at any time.
● Continuous integration—Integrate and build the system many times a day, every time a
task is completed.
● 40 hour week—Work no more than 40 hours a week as a rule. Never work overtime a
second week in a row.
● On-site customer—Include a real, live user on the team, available full-time to answer
questions.
● Coding standards—Programmers write all code in accordance with rules emphasizing
communication through the code.
//testing
Any program feature without an automated test simply doesn't exist. Programmers write unit tests
so that their confidence in the operation of the program can become part of the program itself
//refactoring
Note that this means that sometimes you do more work than absolutely necessary to get a feature
running. But in working this way, you ensure that you can add the next feature with a reasonable
amount of effort, and the next, and the next. You don't refactor on speculation, though; you
refactor when the system asks you to. When the system requires that you duplicate code, it is
asking for refactoring.
//Pair Programming
All production code is written with two people looking at one machine, with one keyboard and one
mouse.
There are two roles in each pair. One partner, the one with the keyboard and the mouse, is
thinking about the best way to implement this method right here. The other partner is thinking more
strategically:
● 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?
Pairing is dynamic. If two people pair in the morning, in the afternoon they might easily be paired
with other folks. If you have responsibility for a task in an area that is unfamiliar to you, you might
ask someone with recent experience to pair with you. More often, anyone on the team will do as a
partner.