Goodreads helps you follow your favorite authors. Be the first to learn about new releases!
Start by following Kent Beck.

Kent Beck Kent Beck > Quotes


Kent Beck quotes Showing 1-30 of 35

“I'm not a great programmer; I'm just a good programmer with great habits.”
Kent Beck
“Do The Simplest Thing That Could Possibly Work”
Kent Beck
“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
“Saying that programmers should just accomplish twice as much doesn't work. They can gain skills and effectiveness, but they cannot get more done on demand. More time at the desk does not equal increased productivity for creative work.”
Kent Beck, Extreme Programming Explained: Embrace Change
“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
“McConnell writes, "In ten years the pendulum has swung from 'design everything' to 'design nothing.' But the alternative to BDUF [Big Design Up Front] isn't no design up front, it's a Little Design Up Front (LDUF) or Enough Design Up Front (ENUF)." This is a strawman argument. The alternative to designing before implementing is designing after implementing.”
Kent Beck, Extreme Programming Explained: Embrace Change
“Without planning, we are individuals with haphazard connections and effectiveness. We are a team when we plan and work in harmony.”
Kent Beck, Extreme Programming Explained: Embrace Change
“Beta testing is a symptom of weak testing practices and poor communication with customers.”
Kent Beck, Extreme Programming Explained: Embrace Change
“the XP strategy is "design always.”
Kent Beck, Extreme Programming Explained: Embrace Change
“Brilliance in a scientist does not consist in being right more often but in being wrong about more interesting topics.”
Kent Beck
“Without the adjustment, you are working under a lie. Everyone knows it and has to hide to protect themselves. This is no way to get good software done and deployed;”
Kent Beck, Extreme Programming Explained: Embrace Change
“Cards on a wall is a way of practicing transparency, valuing and respecting the input of each team member. The project manager has the task of translating the cards into whatever format is expected by the rest of the organization.”
Kent Beck, Extreme Programming Explained: Embrace Change
“However, most defects end up costing more than it would have cost to prevent them. Defects are expensive when they occur, both the direct costs of fixing the defects and the indirect costs because of damaged relationships, lost business, and lost development time.”
Kent Beck, Extreme Programming Explained: Embrace Change
“Used Pluggable Adaptor, which we promise not to use again for four months, minimum, because it makes code hard to statically analyze.”
Kent Beck, Test Driven Development: By Example
“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
“If you have a month to plan a project in detail, spend it on four one-week iterations developing while you improve your estimates. If you have a week to plan a project, hold five one-day iterations. Feedback cycles give you information and the experience to make accurate estimates.”
Kent Beck, Extreme Programming Explained: Embrace Change
“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
“The constraint has shifted out of software development. Here's a sad but repeated story: a development team begins applying XP, dramatically improves quality and productivity, but then is disbanded, its leaders fired and the rest of the team scattered.”
Kent Beck, Extreme Programming Explained: Embrace Change
“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.”
Kent Beck, Extreme Programming Explained: Embrace Change
“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.”
Kent Beck, Extreme Programming Explained: Embrace Change
“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. Pairing”
Kent Beck, Extreme Programming Explained: Embrace Change
“Sit Together Develop in an open space big enough for the whole team. Meet the need for privacy and "owned" space by having small private spaces nearby or by limiting work hours so team members can get their privacy needs met elsewhere.”
Kent Beck, Extreme Programming Explained: Embrace Change
“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
“Change always starts at home. The only person you can actually change is yourself. No matter how functional or dysfunctional your organization, you can begin applying XP for yourself. Anyone on the team can begin changing his own behavior. Programmers can start writing tests first. Testers can automate their tests. Customers can write stories and set clear priorities. Executives can expect transparency. Dictating practices to a team destroys trust and creates resentment. Executives can encourage team responsibility and accountability. Whether the team produces these with XP, a better waterfall, or utter chaos is up to them. Using XP, teams can produce dramatic improvements in the areas of defects, estimation, and productivity.”
Kent Beck, Extreme Programming Explained: Embrace Change
“I've sat through far too many "crying in the beer" sessions where all the energy for change was dissipated in the intensity of the complaining. Once you see an idea for improvement that makes sense to you, do it.”
Kent Beck, Extreme Programming Explained: Embrace Change
“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.”
Kent Beck, Extreme Programming Explained: Embrace Change
“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
“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.”
Kent Beck, Extreme Programming Explained: Embrace Change
“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.”
Kent Beck, Extreme Programming Explained: Embrace Change
“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.”
Kent Beck, Extreme Programming Explained: Embrace Change

« previous 1

All Quotes | Add A Quote
Play The 'Guess That Quote' Game

Test Driven Development: By Example Test Driven Development
2,885 ratings
Extreme Programming Explained: Embrace Change (The XP Series) Extreme Programming Explained
2,679 ratings
Open Preview
Implementation Patterns Implementation Patterns
388 ratings
Open Preview