Reading John Harrison’s blog of November 3 got me thinking about what I am trying to teach my students in my third-semester (university) course about the development of large software systems. They seem to have a good handle on the nuts and bolts of software. Down in the weeds, one statement at a time, they do ok. It’s the bigger picture that is harder to explain. I have a cartoon clipped from the newspaper years ago of a guy in a lab coat pacing back and forth in his office. In the last frame of the cartoon, “Writing,” he says, “is nature’s way of showing you how fuzzy your thinking is.”
A large part of the business of writing software is getting one’s thoughts organized, and then transforming into software those organized thoughts about the management of the information at hand. Human beings are fallible organisms, so their software objects need to be made as simple as possible to minimize the chance that mistakes will be made. We encapsulate information into instances of objects so that all the data handling for a certain “thing” is done in one place, and no code except the local code in the object can manhandle that data. Just as a naval officer expects commands to be repeated back to verify that they have been understood, we expect software modules to report both success and failure, and we organize software so that we trust no part to be “obviously correct” unless we have tested it and found it correct.
But with programs, it is indeed hard in a school setting to give students real problems. The sorts of things that can be dealt with in a class setting are naturally going to be smaller, less complicated, and designed so that most students can actually finish them. Real code is not usually like this. It’s big, it’s messy, and (unfortunately) it can often be as unorganized and unmaintainable as we try to teach students not to be.
Perhaps the answer is that we must bring students to the edge of failure by having them read and understand some large programs that are well written, and having them read and understand some programs that are not so well written. We hope that they will learn how to write by reading literature. We can’t expect them to write software to solve large problems, but perhaps they will learn about solving problems with software by seeing how it’s done and analyzing that code. If they see how others have reduced the fuzziness in their thinking as they organize software to solve a problem, perhaps they will learn how to do it themselves.
Duncan Buell
CSTA Board of Directors