Some who have read my recent rambling thoughts after my software methodologies class may have the impression that I don’t like it. I can see that. And while it’s true that I would be very happy to be less bored, sometimes I can be . . . um . . . overly critical and exacting. (I blame all those critical thinking exercises from the decades I was in school.)

I think not being bored is one of the challenges of life-long learning. Unlike when we were young Turks entering our university days, we actually bring a fair bit of experience and knowledge to our studies. (To the people in my class who are old enough to have worked in the heyday of the Commonwealth’s computing industry and are taking classes to help merge back into an industry that increasingly values youthful adaptability and faddishness, I salute you and the wealth of cynicism and despair you bring to the classroom.) When I was an undergrad, I probably believed more of what my professors said as fact than I ought; after all, Alan Schrift may well be America’s preeminent Nietzsche scholar, and Arnold Adelberg had running conversations with the author of our abstract algebra textbook. I felt lucky that at the time I left Grinnell I was able to talk to some of my professors as an actual peer (albeit on a limited number of subjects).

But now I have almost a decade of industry experience to filter new information through. I appreciate that I’m in school precisely because I don’t know much about important topics and that I wouldn’t be well-served by dismissing out of hand things that run contrary to my experience. But at the same time, I’m in a graduate program to learn things that will actually help me do my job. So information that seems speculative or out-of-date — such as the trend of disparaging iterative development practices without actually having done them — strikes me as contrary to the goals of a software engineering program.

This was the current of thought that flowed beneath the surface of my notes. The Greek and the Hindi were there just to keep me awake in the more languorous moments. As was the picture of the Taj Mahal and the map of the United States a couple weeks ago. (I tend to work eastward, and it always seems to fall apart around Kentucky or Pennsylvania.) The rest of the notes were more to the point. If I had the power to edit my own classroom experience — that is, if I were going to teach the course — how would I change the presentation of the information? How would I distill the important parts of other people’s workplace experiences?

The software development methodologies course (like last semester’s testing course and my future course in project management) is difficult because engineers exists in different development mileius that encompass process activity models, testing beliefs, and project tracking methods. Picking the right model and practices is difficult (perhaps arbitrary) since each has benefits and drawbacks. And we live in a very non-dogmatic age. But most of our development organizations don’t have good practices, and we could use reasonable guidance. I’m in school to learn how to do all of these better and to learn some good construction and design techniques, yet I’m starting to see that the company where I work does most of the meta-activities better than most of my colleagues’ software houses and that we have more experience than some of the instructors.

(In my less generous moments, I suspect that I might ultimately learn as much by studying all of the really good practices we have at The MathWorks and reading the course texts to see where we could be better and how I can improve my own development practices.)

I am also trying to find the right balance between sharing potentially useful information and being a boring know-it-all who fails to see the big picture while knowing certain facts. Wouldn’t it be fun and devastatingly instructive if you could evaluate not only a course’s instructors but also its students?

Anyway, enough rambling. On to reading about “requirements engineering processes,” a topic I know very little about and a skill I need to improve.

Update — 10 Feb. 2007: If you want to know more about requirements engineering, the paper “Requirements Engineering: A Roadmap” would be a good place to start. Or perhaps you like the high-level hieroglyphics of Powerpoint slides to all those words and footnotes.