Dealing With Complexity

I had an interesting conversation with two teachers last week. One the chair of the computer science of a large state university and the other a teacher in a career/technical high school. We were talking about how beginning programming students worked on their programs. I said that time and again I’d seen students trying to fix nested loops by adding end loop constructs in random places until they got a clean compile. Then they were often surprised that the code didn’t work as they expected. The others responded that a lot of those sorts of problems came from students trying to write too much code at once rather than working more iteratively.

For example, one teacher is using Alice which is a great tool. But many students start by adding all the characters they think they need all at once and then have trouble getting them to all work the way they want. The college professor related students trying to write all the methods and functions in a project at once and before testing any of them. The end result was code that was all but impossible to debug because finding where there heart of the error was is so difficult.

Students want instant results though. They think that they can keep many more details in their head then they actually can. Perhaps it comes from multi-tasking so much. Perhaps it is just youthful vanity. or perhaps it is because they see others keep large amounts of details in their head (perhaps their teacher) and assume that it is easy. Lots of students assume they are smarter or more knowledgeable than their teachers. Usually they’re wrong. What they fail to realize is that years of practice and experience gives their teachers an edge that only time and practice will let them catch up to.

I  think we all try to get students to break problems down into small pieces. We emphasize modular coding with small methods and functions. We talk a lot about top down design where we break a large problem down in to progressively smaller pieces. I wonder if we don’t always talk enough about getting each small piece to work right before moving on to the next one. Do we talk enough about unit testing? Do we talk enough about keeping it simple?

I think this is a point that goes far beyond programming BTW. In English class I remember being told to start with an outline and then fill in the outline. One didn’t try to write the whole paper as one run-on sentence. Rather one planned out each section and wrote them in order. Well maybe not exactly in order but one typically made sure one section was in good shape before moving on to another section. Or at least that is always what worked for me. Many problems work better if one focuses on one piece of the project at a time. That is the most efficient way to do things.

Software is getting more and more complex all the time. Student projects are generally fairly simple compared to professional software development. that just means that it is more, not less, important that they learn to keep it simple, work in phases, and deal with complexity from the very beginning.