October 30, 2007
Five Questions With Kent Beck
Kent Beck is likely a familiar name to you, especially if you are at all familiar with Agile development. I first heard about him in the context of Extreme Programming, which concept blew my mind. Then I read Test-Driven Development and Refactoring, which radically changed the way I wrote software. (You mean there are processes I can follow whereby all this code I write is highly likely to write the first time, and all these changes I make to remove code smells are much less likely to break something? Sign me up!) Long time readers of DDJ may remember Kent's articles on the care and feeding of Smalltalk.
Today Kent runs his Three River Institute, where he teaches people about everything I've mentioned and more. Here is what Kent has to say:
DDJ: What was your first introduction to testing? What did that leave you thinking about the act and/or concept of testing?
KB: I first saw real testing when I worked at MasPar Computer with Christopher Glaeser (the person behind the Nullstone compiler optimization tests). He wrote five lines of test code for every line of compiler he wrote. His code was rock solid but he was also very productive. I had never seen a programmer write extensive tests before, so it was a real eye opener for me.
DDJ: What has most surprised you as you have learned about testing/in your experiences with testing?
KB: When I went to school, testers were looked down on as second class citizens. I think what surprised me most about testing was how interesting, challenging, and productive an activity it was.
DDJ: What do you see as the biggest challenge for testers/the test discipline for the next five years?
KB: The key is to make testing more and more part of the inner loop of development, so architecture, design, implementation, and performance decisions can be subjected to immediate experiment. All the feedback we're currently willing to wait for needs to be available sooner.
DDJ: What do you think is the most important thing for a tester to know? To do? For developers to know and do about testing?
KB: In both cases the most important thing to know and do is communicate with people, even when those people have very different perspectives. Testing is a form of unambiguous communication: "The system should do this." However, around that unambiguous communication are all sorts of typically human communications, with all the ambiguity, contradiction, and emotion that implies.
DDJ: Is there something which is typically emphasized as important regarding testing that you think can be ignored, is unimportant?
KB: Perfection was emphasized when I learned about testing in school. The intractability of exhaustive testing was held up as an excuse not to test at all. I think that's misguided. Organizations can function just fine in the presence of software defects. Getting to that level of defects economically is the challenge (hence the emphasis in XP on identifying and fixing defects within minutes or hours). That said, I think a fairly simple set of technical and social practices can eliminate the majority of current defects. When software runs ten times more reliably, organizations will begin to count on that, which will create the platform to improve software quality further.
[See my Table Of Contents post for more details about this interview series.]
Posted by The Braidy Tester at 07:30 AM Permalink
|