On Monday I posted a link to An idiots guide to really bad programming. It is an interesting list but as I read though it I realized that most of what is lists are ways people take shortcuts. They are trying to do things quickly to save time. Most of these things do not save time in the long run. This is a battle we fight with students but even professional developers fall victim to it. It’s one of those things I worry about with the new methods of software development that people are recommending and which appear to be working well for some people. But I’m old school so … Well anyway, I worry a lot.
There is a saying that “Days worth of coding can save you hours worth of planning” and that is an attitude I see many students fall into. I used to call it the “Ready Fire Aim” school of software development. I was reminded of this over the weekend. I was relying on my GPS device to get me to some places I had never gone before. Now what happens is that sometimes it takes a few minutes for the GPS to get enough signals to know where it is. So the tendency (for me at least) is to start driving in what I think is the right direction while I wait (if you can call it waiting) for the GPS to get a signal lock. The theory is that if I go in the right direction I will save time. Some theory.
In practice two things happen. One is that sometimes I guess wrong. When I am leaving from home I guess right a lot but in strange states or cities I guess wrong a lot. Secondly, it seems to take the GPS longer to get good triangulation when I am moving than when I am sitting still. So sometimes doing this costs me time – usually more time than I save by guessing right. I’d be better off waiting a bit and letting the GPS get set up. But I am impatient. Students get the same way with programming. They start throwing code together in hopes that they are going in the right direction and that they can do mid course corrections easily. Like me they often guess incorrectly.
Years ago I was part of an operating system development group (RSTS/E if you want to know) and the team I was part of was assigned the task of rewriting the print and batch subsystem from scratch. We started off our planning and were the very last group to finish the planning and start coding. I know this isn’t the way people do things anymore but it sure did work for us. We finished on time and over the following several years not a single coding related bug was found in our code. One build error, fixed quickly, was it. A pretty good record I think and planning has a lot to do with it.
How do we get students to plan though? They hear a lot about agile development and “throw away code” and think they are ready for it. What they don’t understand is that what works for professionals does not always work for beginners. They don’t understand that what professionals bring to the table is a depth of knowledge and experience that lets them do things apparently without thinking about it that beginners have yet to learn let alone internalize. I really do think that students need to think a bit before they start.
I often say that “reading the documentation is the shortcut” and I really believe that. I believe that starting off right, be it reading the documentation, designing your algorithm, planning your methods and variables, and even waiting for the GPS to get settled is the fast way in the long run. Running off without a plan (or GPS signal) may seem faster and it may seem like making haste but in the long run what looks like a slow start leads to a faster and better conclusion. Now if we can communicate this to students …
I think for a really novice programmer it might not be possible to do the planning without interleaving with a lot of coding. This because the lack of experience makes it nearly impossible to predict how a solution will turn out in practice.
That might be one reason to use agile methods, if you have too many just out of school programmers and not enough experienced people to guide them.
The goal then being to make something really quick, fail miserably, try again , fail and repeat until you know what you're up against.
It might be a good idea, as a final step, to rewrite everything from scratch to get rid of all the redundant code from the failures :)
On the other hand I have found, like in you case with the print and batch subsystem, that when you know your problem domain, have experienced developers and there is little unknowns you can plan it all on the whiteboard, let it take a couple of weeks, and when the planning is done you just code it and it works. If there is bugs they are usually minor, one line or one character to fix.