"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Kent Beck, "Refactoring: Improving the Design of Existing Code", 1999)
"Change is not necessarily slow. A team eager or desperate for improvement can progress quickly. It doesn't need to wait long to assimilate one change before moving on to the next practice. If you change too fast, though, you risk slipping back into old practices and values. When this happens, take time to regroup. Remind yourself of the values you want to hold. Review your practices and remind yourself why you chose them. New habits take time to solidify." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"Folk wisdom in software development teaches that interfaces shouldn't be unduly influenced by implementations. Writing a test first is a concrete way to achieve this separation." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"Given the choice between an extremely skilled loner and a competent-but-social programmer, XP teams consistently choose the more social candidate. The best interviewing technique is to have the candidate work with the team for a day. Pair programming provides an excellent test of technical and social skills." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"If there are forms of testing, like stress and load testing, that find defects after development is 'complete', bring them into the development cycle. Run load and stress tests continuously and automatically." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"In software development, 'perfect' is a verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, perfect your process, your design, and your stories." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"Inaccurate estimates are a failure of information, not of values or principles. If the numbers are wrong, fix the numbers and communicate the consequences." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"Pair programmers: Keep each other on task. Brainstorm refinements to the system. Clarify ideas. Take initiative when their partner is stuck, thus lowering frustration. Hold each other accountable to the team's practices." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"Responsibility cannot be assigned; it can only be accepted. If someone tries to give you responsibility, only you can decide if you are responsible or if you aren't." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"Simplicity only makes sense in context." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"The difference between what I think is valuable and what is really valuable creates waste." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"The XP philosophy is to start where you are now and move towards the ideal. From where you are now, could you improve a little bit?" (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"Often you'll see the same three or four data items together
in lots of places: fields in a couple of classes, parameters in many method
signatures. Bunches of data that hang around together really ought to be made
into their own object." (Kent Beck, "Refactoring: Improving the Design of
Existing Code", 1999)
"When you feel the need to write a comment, first try to
refactor the code so that any comment becomes superfluous."
"When you find you have to add a feature to a program, and
the program's code is not structured in a convenient way to add the feature,
first refactor the program to make it easy to add the feature, then add the
feature."
"Write contracts for software development that fix time, costs, and quality but call for an ongoing negotiation of the precise scope of the system. Reduce risk by signing a sequence of short contracts instead of one long one." (Kent Beck, "Extreme Programming Explained: Embrace Change", 1999)
"One of the purposes of planning is we always want to work on the most valuable thing possible at any given time. We can’t pick features at random and expect them to be most valuable. We have to begin development by taking a quick look at everything that might be valuable, putting all our cards on the table. At the beginning of each iteration the business (remember the balance of power) will pick the most valuable features for the next iteration." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"Optimism is an occupational hazard of programming: feedback is the treatment." (Kent Beck, "Extreme Programming Explained", 2000)
"Planning is not about predicting the future. When you make a plan for developing a piece of software, development is not going to go like that. Not ever. Your customers wouldn’t even be happy if it did, because by the time software gets there, the customers don’t want what was planned, they want something different." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"Projects sometimes fail long before they deliver anything. At some point they may be determined to be too expensive to continue. Or perhaps they took too long to develop and the business need evaporated. Or perhaps the requirements change so often that the developers can never finish one thing without having to stop and start all over on something new. Certainly these are planning failures." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"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." (Kent Beck, Extreme Programming Explained, 2000)
"The new concept of Extreme Programming (XP) is gaining more
and more acceptance, partially because it is controversial, but primarily
because it is particularly well-suited to help the small software development
team succeed. [...] XP is controversial, many software development sacred cows don't
make the cut in XP; it forces practitioners to take a fresh look at how
software is developed." (Kent Beck, "Abstract Extreme Programming Explained",
2000)
"There are two ways to approach prevention of these planning failures. We can plan not to lose, or we can plan to win. The two are not identical. Planning not to lose is defensive; while planning to win is aggressive.[...] the problem that planning is supposed to solve is simply, to build the right system at the right cost. If we take a defensive posture by planning not to lose, we will be able to hold people accountable for any failures; but at an enormous cost. If we take an aggressive posture and plan to win, we will be unafraid to make errors, and will continuously correct them to meet our goals." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"We plan because: We need to ensure that we are always working on the most important thing we need to do. We need to coordinate with other people. When unexpected events occur we need to understand the consequences for the first two." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
"When we plan to win we take direct steps to ensure that we are building the right system at the best possible cost. Every action we take goes towards that end. Instead of trying to plan everything up front, we plan just the next few steps; and then allow customer feedback to correct our trajectory. In this way, we get off the mark quickly, and then continuously correct our direction. Errors are unimportant because they will be corrected quickly." (Kent Beck & Martin Fowler, "Planning Extreme Programming", 2000)
No comments:
Post a Comment