[clug] Question: FOSS and Teaching Software Engineering

steve jenkin sjenkin at canb.auug.org.au
Sun Jun 29 06:40:36 GMT 2008


David Tulloh wrote on 29/6/08 4:05 PM:

You seemed to refer to 'programming' and 'software engineering'
interchangeably. The mess in the codebases you refer to is the result of
'only programming', documented system designs, walk-throughs,
inspections, QA etc are what distinguishes 'software engineering'.

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

Same in the Real World.
Learning to "Come up to speed" is a real skill and requires Confidence
in your abilities. It can only be learnt by doing.And also knowing the
limit of your abilities - saying & sticking with, "No, I can't do this
job" is essential for a Professional.
"Don't take on a job you can't do".


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

So the 3rd years are instructed to bother the 4th years (or
faculty/tutors), not the gurus of the project - unless it really is a
hard question. Simple.


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

Ummm, NO.

According to Alan Kay, the inventor of overlapping windows and Object
Oriented Programming (smalltalk), the central problem of Programming is
*Scale*.  Anyone with {timber, hammer, saw, nails} can construct a
dog-house. It actually takes real skill, knowledge and artistry to scale
that up to Chartres Cathedral. Architecture is literally 'the science of
arches' - getting it right was not easy.  Chartres contains the same
amount of material as the Parthenon in Rome - but encloses a volume many
times the size.  [Kay goes onto say that many software projects
'implode' and you end up with a heap - unlike a badly constructed
pyramid. The creators then sell the mess as "what it was meant to be".]

There are many reasons why scale dominates the construction of Big
Software - complexity, entropy and unexpected emergent properties of
complex systems.  There are more dimensions that I won't go into here.

If "Programming in the Large" were the same as writing a bunch of small
programs, but more of them, then why did the best & brightest academics
and practitioners rail against and eventually defeat Ronald Reagan's
"Star Wars" proposal?? [A software controlled missile defence system for
 Continental USA]

Large scale systems are just too hard to get right...
What works for 10KLOC doesn't work for 1-10MLOC.


> 
> 
> David
> 
> 


-- 
Steve Jenkin, Info Tech, Systems and Design Specialist.
0412 786 915 (+61 412 786 915)
PO Box 48, Kippax ACT 2615, AUSTRALIA

sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin


More information about the linux mailing list