Kent Beck Quotes

I'm not a great programmer; I'm just a good programmer with great habits.

I think it's a combination of technical and social factors that leads to all the defects in deployed software.

Developer testing is an important step towards accountability. It gives developers a way to demonstrate the quality of the software they produce.

Without planning, we are individuals with haphazard connections and effectiveness. We are a team when we plan and work in harmony.

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

I used Agitator on some code I had unit-tested, and it made me a better tester. As an Agitar Fellow, I look forward to the leverage of working with an outstanding organization as together we continue to improve the value of developer testing.

Used Pluggable Adaptor, which we promise not to use again for four months, minimum, because it makes code hard to statically analyze.

We could talk, act, and dress funny. We were excused for socially inappropriate behavior: 'Oh, he's a programmer'. It was all because we knew this technology stuff that other people found completely mystifying.

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?

When Pandora doesn't pay, and bars don't pay, and weddings don't pay, and nobody buys CDs or shirts or concert tickets or lessons, then the musician can't make a living making music.

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.

Responsible Development shares many practices with XP but the roots are different. Responsible Development's values are honesty, transparency, accountability and responsibility. These lead me to pairing, test-first, incremental design, continuous integration and so on because they support the values.

Brilliance in a scientist does not consist in being right more often but in being wrong about more interesting topics.

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;

The problem is, in software design, often the consequences of your decisions don't become apparent for years.

There are musicians who want to make a living making music. There are listeners who want to listen to music. Complicating this relationship is a whole bunch of history: some of the music I want to listen to was made a while ago in a different economy. Some of the models of making a living making music are no longer valid but persist.

A rational model of software is to design it quickly - the economic pressure to improvise presents an interesting challenge.

Optimism is an occupational hazard of programming; feedback is the treatment.

Agitator and the Agitar Management Dashboard lower the barriers to accountability in software development and increase the value of developer testing.

If you're having trouble succeeding, fail.

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.

The world is changing, and I believe that, if I want to stay employed as a programmer, I'm going to have to change with it.

Learning research tells us that the time lag from experiment to feedback is critical ...

One of the advantages of having to live with JUnit for 8 years is now we can look back and see which decisions we made worked nicely and which we would have done differently.

Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something.

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.

I tell people to start implementing when they are pretty sure there aren't more important stories out there. An iteration's worth of data is worth months of speculation.

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.

There is a strong movement towards increased accountability for software developers and software development organizations.

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.

Organizations want small changes in functionality on a more regular basis. An organization like Flickr deploys a new version of its software every half hour. This is a cycle that feeds on itself.

Sometimes the problem has to mature before the solution can mature.

There's a huge latent market for software development that's just flat-out honest.

I lived near Santa Cruz for ten years, and the whole time, it bothered me what an exclusionary definition of 'inclusion' was in force. Social censure was applied to those who expressed unpopular or uncomfortable ideas.

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.

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.

I found out that most programmers don't like to test their software as intensely as I do.

Code wants to be simple ... I had to give up the idea that I had the perfect vision of the system to which the system had to conform. Instead, I had to accept that I was only the vehicle for the system expressing its own desire for simplicity. My vision could shape initial direction, and my attention to the desires of the code could affect how quickly and how well the system found its desired shape, but the system is riding me much more than I am riding the system.

Design should be easy in the sense that every step should be obviously and clearly identifiable. Simplify elements to make change simple so you can manage the technical risk.

the XP strategy is "design always.

Responsible Development is the style of development I aspire to now. It can be summarized by answering the question, How would I develop if it were my money? I'm amazed how many theoretical arguments evaporate when faced with this question.

I don't like the feeling, but I've got to say that a little fear makes me a more focused, more responsible programmer.

Testing is not the point. The point is about responsibility.

Make it work, make it right, make it fast.