Someone (I don’t really like to mention a lot of specific names on my blog) asked me today what suggestions I might have to someone who’s about to start teaching a university course in programming in MIS. I had some fun hypothesizing about it; here’s what I wrote:
[I have to preface all my remarks with: I’ve never taught anything bigger than parts of a three-day course in the architecture of a specific application, and even then I didn’t try any of the blue-sky ideas I’m about to mention. But, if I did try to teach something like a college course, I would try them.]
My first thought is that the most important thing to emphasize is that programming is about structuring thinking and activity, and not really about the structure of computer programs, so I think a project-based approach seems like a good idea.
I’m going to just go full-hypothetical here and give a transcript of the first monologue I’d give :-). Hopefully people would interrupt me…
“Contrary to what you may have been told, programming is not really that much about languages and syntax and stringing together a series of canned solutions. Well, good programming is not about that. Mediocre programming is about that, and you can get by in the commercial sphere being a mediocre programmer, so if anyone is truly satisfied with that, we can have an independent study course where I assign you a textbook and you do problem sets and tests.
However, what I’d rather we all do is learn good programming, and by the method that I think makes most sense, which is to actually build something together and enjoy building it. Good programming is about structuring thinking and activity, both on your own and with others. It’s really just a particular discipline of problem-solving and communication, both of which I assume you all know a good deal about.
The project we’ll be doing is the software for a POS system. You might think “that’s boring”, which I hope to convince you doesn’t have to be true, and you might think “that’s quite practical”, which is true but not all that relevant.
What is relevant is that it’s something big enough that it will take the whole semester. Today is the last ‘lecture’ of the class. I mean, there’ll be plenty of opportunities to take notes if that’s your thing, but what I’ll be doing is not lecturing; I’ll be participating in the discussions that come naturally from the project, and bringing in whatever I can from my years of experience when the need arises. You’ll want to take notes on what you and your classmates say more than on what I say.
If you’re thinking about grades, and it’s OK to admit that you are, I think everyone will be graded by classmates. I won’t let you be too hard or too easy on one another, but other than that, you’ll be deciding grades. Inherent in the structure of a complete software system is some sort of assurance that what you’ve built is high-quality. So, for example, there’ll be people making test systems that will test modules that other people are making. It will be clear to both of those teams how well the other team did. You’ll be giving grades at the end of the second, fourth, eighth, and sixteenth weeks.
Speaking of teams, let’s start talking about the pieces of the system and the workflow for building them. I think we can accommodate everybody’s interests and talents somewhere in here.”…
[Some pieces of work/ideas I might bring up if they didn’t come up: user interface/ease of use, network protocols, language and coding style decisions, source control (use SourceForge and get the added effect that ‘anyone in the world might see your code’), error handling, exception handling, auditing, security, existing code and libraries, storage and redundancy, issue tracking, performance, testing, data formats (i.e. floating point is not necessarily good for financial data), customization/branding, data mining, what happens if the whole thing ‘crashes’, legacy system integration, self-check systems, …]
