TITLE: Multiple Iterations and Care for Programs AUTHOR: Eugene Wallingford DATE: August 19, 2004 1:50 PM DESC: how agility can make not thinking ahead okay ----- BODY: Fall semester is in the air. The students are beginning to arrive. As I prepare for my courses, I've been thinking about some issues at the intersection of agile development, programming style, thinking ahead, cognitive styles, and technology. Many computer science faculty pine for the good old days when students had to plan their programs with greater care. To this way of thinking, when students had to punch programs on cards and submit them for batch processing at the computer center, they had to really care about the quality of their code -- think through their approach ahead of time, write the code out by hand, and carefully desk-check it for correctness and typos. Then came the era of interactive computing at the university -- when I was an undergrad at Ball State, this era began with the wide availability of DEC Vax terminals -- and students no longer had to be careful. Professors love to tell stories from those Vax days of receiving student submissions that were Version 132 of the program. This meant that the student had saved the program 132 times and presumably compiled and run the program that many times as well, or close to it. What could be a worse sign of student attention to planning ahead, to getting their programs right before typing? I've never held this view in the extreme, but I used to lament the general phenomenon. But my view is now mixed, at best, and moving toward a more agile perspective. Under what conditions would I want my students to save, compile, and run a program 142 times? In agile development, we encourage taking small steps, getting frequent feedback from the program itself, and letting a program evolve in response to the requirements we implement. In test-driven development, we explicitly call for compiling and running a program even when we expect a failure -- and then adding functionality to the program to make the test pass. If my students program this way, then they will necessarily end up with many, many saves and compiles. But that would be a good thing, and at every step along the way they would have a program that deserves partial credit for a correct but incomplete solution. In order for this approach to be desirable, though, students need to do more than just code, compile, and run. They will need to add individual features to their programs in a thoughtful, disciplined way. They will need to do some testing at each step, to ensure that the new feature works and that all older features still work. They will need to continuously re-work the design of their program -- refactor! -- as the design of the program evolves. And all of these take time. Not the frenzied iterations of a student whose program is due tomorrow morning, but the intentional iterations of a programmer in control. To me, this is the biggest difficulty in getting students to program in an agile style. Students are so used to procrastinating, to doing triage on their to-do lists in order to get the most urgent project done first. Unfortunately, many also give higher priority to non-school activities all too often. I am always on the look-out for new ways to help students see how important time is in creating good programs, whether by planning carefully ahead or by going through many planned iterations. Please share any ideas you have. So, many iterations isn't a problem in itself, but rather a style in which those iterations are the result of the seemingly random modify-and-compile approach that many students seem to fall into when a program gets tough. Part of our job as teachers is helping students learn discipline in attacking a problem -- more so than teaching them any particular discipline itself. Why the mention of cognitive styles above? A blog entry by Clive Stephenson brought this topic to the front of my mind a few weeks ago, and it wasn't about programming at all, but about writing more generally:
... Is there any difference between our cognitive styles when we write longhand, versus typing on a keyboard?

Since I type about 70 words per minute, I can type practically as fast as I can compose sentences in my head. So does the much-slower pace of handwriting actually create a different way not just of writing, but of thinking? Does the buffer buildup between my brain and my arm affect things?

What I mean is this: When I'm typing, because I can generate text so fast, I'll toss lots of stuff out on the page -- and then quickly edit or change it. But when I'm writing by hand, because it's so much slower I'll try to compose the sentence in my head before trying to write it. With a keyboard, I sort of offload some of my mental-sorting onto the page, where I can look at the words I've written, meditate on them, and manipulate them. With writing, that manipulation happens before the output. Clearly this would lead to some cognitive difference between the two modes ... but I can't quite figure out what it would be.

Changes in technology have made it easier for us to get ideas out of our heads and onto paper, or into a computer file. That's true of good ideas and bad, well-formed and inchoate. For many writers, this is a *good* thing, because it allows them to get over the fear of writing by getting something down. That's one of the things I like about having my students use more agile techniques to program: Many students in introductory courses are intimidated by the problems they face, are afraid of not being able to get the Right Answer. But if they approach the problem with a series of small steps, perhaps each small step will seem doable. After a few small steps, they will find themselves well on the way to creating a complete program. (This was also one of my early motivations for structuring my courses around patterns -- reducing fear.) Used inappropriately, the technology is simply a way to do a poor job faster. For people whose cognitive style is more attuned to up-front planning, newer technologies can be a trap that draws them away from the way they work best. In retrospect, a large number of compiles may be a bad sign, if they were done for the wrong reason. Multiple iterations is not the issue; the process that leads to them is. With a disciplined approach, 142 compiles is the agile way! -----