Quotes from Kent Beck

The majority of the cost of software is incurred after the software has been first deployed. Thinking about my experience of modifying code, I see that I spend much more time reading the existing code than I do writing new code. If I want to make my code cheap, therefore, I should make it easy to read.

Sometimes I feel silly introducing methods "just" to satisfy an "aesthetic" urge like symmetry. Aesthetics go deeper than that. Aesthetics engage more of your brain than strictly linear logical thought. Once you have cultivated your sense of the aesthetics of code, the aesthetic impressions you receive of your code is valuable feedback about the quality of the code.

Some of the teams who read and applied the first edition of this book didn't get the part of the message about the last responsible moment. They piled story on story as quickly as possible with the least possible investment in design. Without daily attention to design, the cost of changes does skyrocket. The result is poorly designed, brittle, hard-to-change systems.

If I have the same logic in two places, I work with the design to understand how I can have only one copy. Designs without duplication tend to be easy to change.

Call-by-reference went out of fashion in language design a couple of decades ago because of the possibility for unintended consequences.

When we released JUnit 4 recently we spent nearly half of our engineering budget on reducing the cost of deployment for our clients. We tried to make sure that new-style tests would work with old tools and old-style tests would work with new tools. We also worked to make sure we had the freedom to make future changes to JUnit without breaking client code.

At some point, the cost of maintaining perfect compatibility outweighs the value to clients.

A framework with all protected fields would be more immediately usable but harder to evolve later.

Packages can provide a way to offer clients incremental access to upgrades. By introducing new classes in a new package, you can give them the same name as the old classes. For example, if I can upgrade org.junit.Assert in org.junit.newandimproved.Assert, then clients need only change the import statements to be using the new class. Changing imports is less risky and intrusive than changing code.

Versioned interfaces are a reasonable compromise when you absolutely must introduce new operations to an existing interface-based abstraction without affecting client code. They are not a long-term solution for frequently changing abstraction, because of the complexity they create both for client and framework developers.

The purposes of two constructors with different sets of parameters are not always obvious, but the name of the factory methods can suggest the reason clients might want to create an object each way.

It is the framework developer's job to ensure that clients can extend the framework to solve the remainder of their problems. It's tempting to try to solve a broad range of problems with a framework. The conflict is that the added functionality makes the framework that much more difficult to learn and use for all clients.

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.

First you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer

Don't make more versions of your source code. Rather than add more code bases, fix the underlying design problem that is preventing you from running from a single code base.

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.

If you want people to take your advice, you need to solve more problems than you create.

A team using the information provided by pay-per-use should be able to do a more effective job than a team relying for feedback only on license revenues.

Trust energizes participants. We feel good when things work smoothly. We need to be safe to experiment and make mistakes. We need testing to bring accountability to our experimentation so that we can be sure we are doing no harm.

Customers may have a good idea of the general behavior they want to see, but testers are good at looking at "happy paths" and asking what should happen if something goes wrong. "Okay, but what if login fails three times? What should happen then?" In this role testers amplify communication.

XP always keeps the system in deployable condition. Problems are not allowed to accumulate.

To achieve this his team had a sophisticated stress testing environment. When they wanted to improve the architecture they would first improve the stress tests until the system broke. Then they would improve the architecture just enough to run the tests. I suggested this strategy to an architect at another company. He complained of spending all of his time writing specifications and then explaining them to developers.

First a small team writes a small system. Then they find the natural fracture lines and divide the system into relatively independent parts for expansion. The architects help choose the most appropriate fracture lines and then follow the system as a whole, keeping the big picture in mind as the groups focus on their smaller section.

Are the teeny-tiny steps feeling restrictive? Take bigger steps. Are you feeling a little unsure? Take smaller steps. TDD is a steering process -- a little this way, a little that way.