Software Carpentry

Helping scientists make better software since 1997

What Else for Software Carpentry?

16 lectures are now in place (more or less), which means I have 8 more to do. The syllabus shows what I’ve covered already; my current plans include:

  • unit testing
  • XML
  • SQL
  • more SQL
  • small-team development process

What do you think the other three should cover (keeping in mind that this is supposed to be a course on basic software engineering, rather than scientific programming)? Options include:

  1. Basic web programming, with much-revised versions of:
  2. Integration, including:
    • wrapping C code so that it can be called from Python
    • using popen() and its ilk to run external programs
    • (probably) something on refactoring to make code more testable (as per Feathers’ excellent Working Effectively with Legacy Code
  3. Three lecture-length examples, building very simple versions of core tools that haven’t been covered elsewhere:
    • data lineage
    • continuous integration
    • data consistency checking
  4. Give in, and do the scientific programming stuff anyway:
    • floating-point arithmetic
    • Python’s Numeric package
    • data visualization
  5. Scrap the single lecture on development process, and put in four full lectures on the subject
    • XP
    • UML-based processes (probably ICONIX)
    • something else (not entirely sure what)
  6. Something else entirely — suggestions would be very welcome.

Please let me know what you think.

Advertisements

Written by Greg Wilson

2006/02/21 at 14:18

Posted in Content, Version 3

5 Responses

Subscribe to comments with RSS.

  1. 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

    Adrian Popescu

    2006/02/21 at 18:16

  2. 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

    Rob

    2006/02/21 at 20:19

  3. 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.

    Ian Bicking

    2006/02/21 at 20:54

  4. 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.

    Donovan Baarda

    2006/02/22 at 04:54

  5. 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.

    Stephanie Ludi

    2006/03/16 at 09:27


Comments are closed.

%d bloggers like this: