The Third Bit

Greg,

The “unit testing” part is important. Also, some uncertainty analysis, sources of code uncertainties, or sensitivity analysis applied to numerical models can help – but this may be beyond the scope of the current course. [However if you are interested please see the following references: D.C. Cacuci, Sensitivity & Uncertainty Analysis, Volume 1: Theory, D.C. Cacuci, …, Sensitivity and Uncertainty Analysis, Volume II: Applications to Large-Scale Systems]

Regards,
Adrian

Greg,

I would personally like to see integration. I think this is an applicable and important area to delve into. I am also a proponent of the example lectures. Picking examples of your own to illustrate common programming errors gives more food for thought to the students. Also, being walked through examples allows people to voice concerns they otherwise wouldn’t encounter until later trying to apply the concepts of the course. And, as much as nobody wants to hear it, I think the scientific programming stuff is pedologically important to build applications properly. At least being exposed to it allows the student a jumping-off point if need should ever arise to dig deeper for solutions.

Regards,

Rob

From a practical point of view, if the programmer isn’t running the commands manually there’s a good chance that a web frontend will be the appropriate interface; besides the command-line there’s no simpler interface to implement. Plus it’s just a really useful skill to have, and is more likely to be immediately applicable outside of class than any other skill.

OTOH, it’s also relatively easy to pick up independently, though perhaps missing concepts like security.

I think development process can be a bit abstract, so I wouldn’t be inclined to extend that. It’s easier to address when tackling hard problems — e.g., to slip in with a discussion of integration techniques.

I actually think from a practical point of view, the development process is critical. It doesn’t matter what or how bad your tools are if your deveopment process is good. The development process is a systematic approach to tackling every problem, much like the “scientific method”.

The development process is only abstract if you aren’t using it. Even people who claim to not be interested in development methodologies have a process… it just might not be a very good one

On XP, there are lots of things in there that I was very sceptical about until I worked for a company that used them. It would point them to the XP URL in early lectures, then teach them the tools, then come back to it later before they start using the tools to solve problems.

Things like pair-programming would work well in a classroom lab environment… and make sure you rotate the pairs (they will learn more off each other than you can teach them).

And remember, more software projects fail because they screw up the requirements than from anything else… perhaps you can role-play the dumb customer and get them to wangle the requirements out of you for some of the excercises. I’m reminded of a dilbert;

customer: I’m thinking of the requirements… they are changing… steady… changing… steady. Of course I’m not going to tell you any of this.

dilbert: It’s OK, I’ll budget in for a few goons to beat it out of you.

Hi,

I don’t know if it is too late for this this offering, but if there is room I suggest either as a seperate topic or woven with the others some discussion of how to use the technologies in a manner that would secure systems. Even if you could have some discussion in the lectures for the scripting and legacy isssues that would be a nice idea.