Kent Beck > Quotes

“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

“Write tests until fear is transformed into boredom”
― Kent Beck, Test-Driven Development: By Example

“If you're happy slamming some code together that more or less works and you're happy never looking at the result again, TDD is not for you. TDD rests on a charmingly naïve geekoid assumption that if you write better code, you'll be more successful. TDD helps you to pay attention to the right issues at the right time so you can make your designs cleaner, you can refine your designs as you learn.”
― Kent Beck, Test-Driven Development: By Example

“Brilliance in a scientist does not consist in being right more often but in being wrong about more interesting topics.”
― Kent Beck

“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

“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

“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

“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

“the XP strategy is "design always.”
― 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

“Beta testing is a symptom of weak testing practices and poor communication with customers.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“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

“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

“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

“Rather than apply minutes of suspect reasoning, we can just ask the computer by making the change and running the tests.”
― Kent Beck, Test-Driven Development: By Example

“Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“However, those whose souls are healed by the balm of elegance can find in TDD a way to do well by doing good. TDD is also good for geeks who form emotional attachments to code. One of the great frustrations of my young engineer's life was starting a project with great excitement, then watching the code base decay over time. A year later I wanted nothing more than to dump the now-smelly code and get on to the next project. TDD enables you to gain confidence in the code over time. As tests accumulate (and your testing improves), you gain confidence in the behavior of the system. As you refine the design, more and more changes become possible. My goal is to feel better about a project after a year than I did in the starry-eyed beginning, and TDD helps me achieve this.”
― Kent Beck, Test-Driven Development: By Example

“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

“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

“No matter the circumstance you can always improve. You can always start improving with yourself. You can always start improving today.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Readers need to understand programs in detail and in concept. Sometimes they move from detail to concept, sometimes from concept to detail.”
― Kent Beck, Implementation Patterns

“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

“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

“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.”
― Kent Beck, Test-Driven Development: By Example

“Actually this book is built on a rather fragile premise: that good code matters. I have seen too much ugly code make too much money to believe that quality of code is either necessary or sufficient for commercial success or widespread use.”
― Kent Beck, Implementation Patterns

“When objects first became popular, subclassing seemed like a magic pill. First, subclasses were used for classification—a Train was a subclass of Vehicle regardless of whether they shared any implementation. In time, some people saw that since what inheritance did was share implementation, it could most effectively be used to factor out common bits of implementation. Quickly, though, the limitations of subclassing became apparent.”
― Kent Beck, Implementation Patterns