[clug] Question: FOSS and Teaching Software Engineering

Jacinta Richardson jarich at perltraining.com.au
Sun Jun 29 13:30:42 GMT 2008


steve jenkin wrote:

> I've puzzled over non-teaching of P-i-t-L- for years - I got to learn
> about O/S's at Uni by reading *the source*, and wondered why it isn't
> now the norm, but even worse - why academe seems to have regressed and
> moved away from it.

I can't answer why academe has regressed and moved towards making getting the
degree much easier than it used to be.  I think it has something to do with the
comparative difference between government funding and income from paying
students (international or otherwise) and the need to keep those who are paying
(it isn't the government) happy (ie: passing their subjects).


I can suggest that the answer to your question is pretty easy though.  Teaching
software engineering via "real work" on open source projects is too hard.  Or at
least it's much harder than the current task of getting a group of 20 to work
through the SDLC and implement a project where the project academics have access
to all the revision history, email, documentation etc etc.

Real projects have mailing lists that are not hosted inside the university,
revision control systems that might not be the one the university teaches -
again not hosted inside the university etc.  They have non-university project
managers who can reject features despite the team providing an SRS, SDD, STP and
SQAP all related to those features.  They have other non-university project
members who might rewrite parts of the student code while they're working on it,
throwing the team into confusion.  They have in-fighting and other distractions.
 Also the university certainly can't guarantee that mailing list, irc and other
interactions will all be appropriate and professional.

It's much harder than a software engineering lecturer needs it to be.  Since
most academics are overworked, I can't imagine any of them volunteering to make
their projects harder to run and assess, for something which could end up being
a disaster.


I'm fairly certain that I didn't have the skills to do what you're suggesting
when I started my final year software engineering project.  I was a fairly
diligent student, I also tutored and ran labs for first and second years, worked
in the first year learning centre (lunch time assistance for first (and
occasionally second) year students) and did a bunch of related volunteer work.
I could understand the code of my peers very well (sometimes better than they
did - more eyeballs do help find bugs).  But all of my learning that far had
never involved learning how a massive project works.

My third and final year projects involved learning how to work in a team (of
more than 3), write documentation (SRS, SDD, STP etc), work on a bigger project
than I'd ever worked on before, manage a small team etc.  A lot of it was
completely contrived and bore no resemblance to the real world.  On the other
hand, the knowledge sunk in and I use it regularly.

You are assuming that the students have enough time, motivation and smarts to
learn how to work with the assigned project and actually produce something.  I
agree that people need to learn how to pick up projects and see how things
interact, but - it's weird to say - I'm not actually sure this is something
that's easily *teachable*.  Adding this as an extra level of complexity
(especially if it's the student's first experience of it) on top of an already
hard project will be unpopular.  The university probably wouldn't like that.



All the best,

	J

-- 
   ("`-''-/").___..--''"`-._          |  Jacinta Richardson         |
    `6_ 6  )   `-.  (     ).`-.__.`)  |  Perl Training Australia    |
    (_Y_.)'  ._   )  `._ `. ``-..-'   |      +61 3 9354 6001        |
  _..`--'_..-_/  /--'_.' ,'           | contact at perltraining.com.au |
 (il),-''  (li),'  ((!.-'             |   www.perltraining.com.au   |


More information about the linux mailing list