TITLE: Agile Themes: Things Students Say AUTHOR: Eugene Wallingford DATE: December 22, 2009 2:57 PM DESC: ----- BODY: And now even the grading is done. I enjoyed reading my students' answers to exam questions about software engineering, especially agile approaches. Their views were shaped in part by things I said in class, in part by things I asked them to read, and in part by their own experiences writing code. The last of these included a small team project in class, for which two teams adopted many XP practices. Many people in the software industry have come to think of agile development as implying an incomplete specification. A couple of students inferred this as well, and so came to view one of the weaknesses of agile approaches as a high risk that the team will go in circles or, worse yet, produce an incomplete or otherwise unacceptable system because they did not spend enough time analyzing the problem. Perhaps I can be more careful in how I introduce requirements in the context of agile development. One exam question asked students to describe a key relationship between refactoring and testing. Several students responded with a variation of "Clean code is easier to test." I am not sure whether this was simply a guess, or this is what they think. It's certainly true that clean code is easier to test, and for teams practicing more traditional software engineering techniques this may be an important reason to refactor. For teams that are writing tests first or even using tests to drive development, this is not quite as important the answer I was hoping for: After you refactor, you need to be able to run the test suite to ensure that you have not broken any features. Another person wrote an answer that was similar to the one in the preceding paragraph, but I read it as potentially more interesting: "Sometimes you need to refactor in order to test a feature well." Perhaps this answer was meant in the same way as "clean code is easier to test". It could mean something else, though, related to an idea I mentioned last week, design for testability. In XP, refactoring and test-first programming work together to generate the system's design. The tests drive additions to the design, and refactoring ensures that the additions become part of a coherent whole. Sometimes, you need to refactor in order to test well a feature that you want to add in the next iteration. If this is what the student meant, then I think he or she picked up on something subtle that we didn't discuss explicitly in class. When asked what the hardest part of their project had been and what the team had done in response to the challenge, one student said, "We had difficulty writing code, so we looked for ways to break the story into parts." Hurray! I think this team got then idea. A question near the end of the exam asked students about Fred Brooks's No Silver Bullet paper. They read this paper early in the semester to get some perspective on software engineering and wrote a short essay about their thoughts on it. After having worked on a team project for ten weeks, I asked them to revisit the paper's themes in light of their experience. One student wrote, "A good programmer is the best solution to engineering software." A lot of the teams seem to have come to a common understanding that their design and programming skills and those of their teammates were often the biggest impediment to writing the software they envisioned. If they take nothing from this course than the desire and willingness to work hard to become better designers and programmers, then we will have achieved an outcome more important than anything try to measure with a test. I agree with Brooks and these students. Good programmers are the best solution to engineering software. The trick for us in computer science is how to grow, build, or find great designers and programmers. -----