e-Talk Radio: Pettichord, Bret, 8 February 2001

that actually a lot of the bugs are actually caused by communication errors between people on different teams. So, everyone's part of the program works the way they thought it was supposed to work but they had different ideas about how the different parts of the program were going to be communicating with each other. I find that is actually a big source of problems anyway. You do not want to start saying, "Well, you did it wrong or you did it wrong." Let's just try to find a way to make this all work together.

Carol: James Boddie wrote a book called The Information Asset a number of years ago. One of the things that I thought was very, very powerful in what he said in his book, was that you should look at software, at system development, that developers should look at the software as a tool. As a tool to help the users do their jobs better, rather than an end product. So, if developers looked at it, that they are delivering a tool. They are delivering a hammer. They are delivering a screwdriver that will enable the users to work better. Then if the screwdriver doesn't just quite work because it is too big or too small for the screws, you go back and you fix it until it will work. And that is a different way of looking at things as opposed to this is an artistic creation, look at what I have done, feast your eyes on it, and be happy. Look at how great this software is that I built to meet your needs. It is a different way of looking at it.

Bret: It is.

Carol: I think that part of it - I did a use cases course and we talked a little bit about this at break. One of my clients was very, very astute, Nielsen Media Research, and they were so astute, that I hold them up as a shinning example. What they did, is that they realized that use cases are a developer's tool but they are also a user tool. So that if you just teach it to developers, and you have the developers go in and write the use cases and present them to users, that they are going to be in technical language. Well, we did separate workshops, one for users and one for developers and then brought the two together at the end. We had QA people and testers who were part of the project team who took these use cases courses. One of the most insightful things that one of the testers said was "You know what, we get to be involved a little bit. We get to watch the requirements process, and then we are told what the requirements are and we are supposed to go off and write all of our tests, as the developers go into this artistic mode. And they said often times when there are changes, which there inevitably are, we do not find out the changes until after we have tested the wrong things or we have gotten unexpected results." Do you find that this happens? That testers are not part of an integrated team to start with?

Bret: Well, I think that is something that many teams are struggling with in trying to find ways in which to get the testers in to know more about what is happening with the day to day development and where things are going on. I always find that it helps to have that. I find that part of it,