[clug] Question: FOSS and Teaching Software Engineering

David Tulloh david at tulloh.id.au
Sun Jun 29 06:05:56 GMT 2008


steve jenkin wrote:
> Here's something I Just Don't Get, and wanted to hear Comments or Good
> News from this community...
>
> 'Software Engineering' is different from Computer Science because, in
> part, it is about "Programming In The Large".
>
> Beautiful New Algorithms and insightful new approaches are CS.
> The problem of producing Big Software is pure SE.
>
> Has anyone seen/heard of an SE course that comprises a chunk of real
> work on some large (>>100KLOC) bit of code?
> [Versus the usual 'final year group project' of knocking up something
> from scratch. At best 1-5KLOC]
> i.e some actual P-i-t-L experience.
>
> There are any number of *definitive* FOSS projects out there that are
> open-ended and ideal candidates for this.
> Off the top of my head:
> - gcc and other compilers [e.g. port to a new platform or O/S]
> - linux, *BSD kernels
> - PERL, TCL, Python, Ruby, PHP, SWIG - modules/objects, porting,
> features, ...
> - Apache
> - SAMBA
> - Mozilla, Thunderbird, ...
> - WINE
> - OOo
>   

I think there are a number of problems with your view on this.

The first thing that you have to realize is that a programming course 
isn't really about teaching you how to churn out code, at least the good 
ones aren't.  For example I went through the ANU and our final year 
group project was a document writing course.  Sure a few people wrote 
some code but the aim of the process was how to do a project and writing 
all sorts of documentation pretending that you are part of a far larger 
team.  The majority of people in a group (marking was a bit weird) could 
have gotten in the realms of 70% without there being any code written at 
all.  Personally I think that teaching the group roles, their 
interactions and general teamwork was far more important than hacking 
away at a chunk of code for a year.

When they do a course the aim is to teach you a bunch of different 
things.  This is generally best done by lots of small projects aimed at 
each component.  It's very difficult to teach a pile of different things 
by hacking on a chunk of code.

I've played with a few of those projects that you listed and they all 
have a fairly steep learning curve before you can start playing with 
their code base.  Linux is poorly documented, a pain to debug and 
there's all sorts of special things you need to do for memory management 
etc.  PHP is full of fantastic macros, you have PHP macros, Zend macros, 
thread safety macros and type manipulation macros; you need know them 
all.  Gcc has a whole host of black magic behind it, I've not dug deeply 
into the code base but I have messed with the optimizer a bit and it's 
scared me off.  Mozilla has a reputation for having a very complicated 
code base.  What I'm trying to get at is that these aren't simple 
projects, they all have their own unique structure and ways of doing 
things and they all require at least a week to get familiar with.  
That's a week before the student even thinks about how to do the project 
assigned, essentially it's time lost.

I'm not sure that an open source project would be very happy with 60-100 
students descending on their project, asking for help and generally 
getting in the way.  They're not going to contribute much to the 
community, as students the quality of their code is generally pretty 
poor and they will all be implementing the same thing anyway.

Finally I'm not sure what you would be looking at achieving.  Working on 
a large code base is basically the same as working on a small one with 
more annoyances thrown in.  The programming techniques are the same and 
the extra stuff like source control can be taught in a pretend manner 
with a small amount of code easier than trying to interact with an open 
source group.


David


More information about the linux mailing list