Subject: OT?: essay: software engineering and uni's

From: guy keren <[email-masked]>
Date: Sat, 12 May 2001 06:37:36 +0300 (EET DST)

hi,

i've recently written an essay on "Why Do Universities Fail Teaching
Software Engineering?", and today i've placed it on the LUPG (Little unix
Programmers Group) site. comments are welcome.

http://www.actcom.co.il/~choo/lupg/essays/software-engineering-and-uni.html

--
guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy

---

From: "Nadav Har'El" <[email-masked]>
Date: Sat, 12 May 2001 12:24:03 +0300

> Programmers Group) site. comments are welcome.

I think that Software "Engineering" should be compared to other types of
engineering (say, Civil Engineering, Mechanical Engineering, etc.). I
have two points on such a comparison:

1. Do Civil Engineering students also get "big" experience during their
   BA studies? I'm sure they do small projects like building something
   small which doesn't break under the load, etc. (and I'm just guessing
   here - I have no experience in Civil Engineering studies), but do they,
   say, participate in the building of a real bridge (requiring the
   cooperation of many engineers, builders, etc.) during their studies?
   I think (and again, I don't know) that the idea is that a student
   wouldn't have time or opportunity (in his or her very short 3 year
   studies) to participate in a huge, real, project (be it bridge building
   or big software development. The nature of such "big" projects is that
   they can't be a useless exercise - they need to be something useful
   (it's hard to justify a huge, but useless, project) and these don't
   come along very often. So the student comes out of the university with
   a lot of knowledge but little experience in big real-life projects.
   His (or her) first project will probably be something small (e.g.,
   make structural plans for a one-floor villa) or a tiny detail in a huge
   project (some small part of a bridge), and certainly not running a
   big project like designing the overall structure of a 5-km suspension
   bridge.
   So why can't software engineering be the same? A student out of college
   will be able to program, but will not be capable yet of designing a new
   1-million line program on his own. He will learn these skills later
   (actually, he already learned these skills at the university, but only
   theoretically and now he will have to learn how to apply these rules
   in the field).

2. I think that "Engineering" should not be confused with "Management". 
   Someone can be a wonderful Civil-Engineer but would not be hired to
   build a new billion-dollar bridge because running such a project entails
   much more than actually "engineering" (deciding how the structure needs
   to be built to face gravity, weather and earthquakes, etc.) - it requires
   hiring other people (of many different types and professions), telling
   them what to do, when somebody quits a replacement needs to be found and
   told what his predecessor did, you need to oversee the entire thing and
   see it's going according to plans and the parts fit together, etc. You
   surely don't expect that to be taught in Civil-Engineering BA, do you?
   I think the case of Software-Engineering is similar. In large projects,
   many of the aspects you describe in your essay have to do more with
   management than Engineering. When you're not the manager, the stages in
   software creation you describe is something your manager tells you (as you
   said, when you work alone on a small project, they don't matter much),
   and you just follow. Your manager will also oversee everyone's design
   suggestions in the design phase, and integrate them into something
   consistent and coherent. Your responsibility, as a "boreg katan" in a
   big software development project, in merely to do the part you're assigned
   to well. A civil engineer being told to design the suspension bridge's
   cables needs to know them and their properties (from his studies), how to
   use them safely (how thick they need to be to carry some weight, how
   effected they are by corrosion) and efficiently (extra-thick cables cost
   more money, and weigh more putting more stress on the beams), and so on.
   Similarly, a software engineer needs to know the programming language he's
   working on, how to use it safely (minimizing bugs) and efficiently (e.g.,
   know common algorithms and datastructures and when to use each of them),
   and so on - these are the things that MUST be taught in the university,
   because these are not things a person usually invents on his own (e.g.,
   most people will not be able to write a decent compiler if they never
   learned compiler theory).

Anyway, I think that your suggestion, that universities should have "pet
software projects" that staff and students (graduate, and some of the
undergraduate, in my opinion) are working on is a very good one. Just
think of Berkeley's BSD and Sprite projects (bringing us many Unix innovations,
Tcl/Tk, the idea of NFS, etc.), MIT's Athena project (giving birth to X11)
and many other now-forgotten projects that predated Unix, and so on. A more
local (and small) example is Prof. Barak from HUJI, who is developing with
several graduate students (who've changed through the years) and
undergraduate students, the Mosix system (see www.mosix.org).

Students should be allowed, and even encouraged, to take part in such
projects, sometimes for course credit or graduate research, and sometimes
for small monetary compensation (professors have research grants for that,
and can get other forms of funding), and sometimes even for the fun of it
(this is most relevant to graduate students who get a generous scholarship
and don't need to work for a living). Spending a few months working on
such a project will surely give the student some experience, and give them
a better insight about what their future profession is all about (and
hopefully make them more enthusiastic about it), but it will not replace
the *years* of experience that will follow.

Another possibility is for the students to get involved in projects like
free-software projects that are not specific to their university. Again,
this makes more sense for graduate students which have more free time and
less need to work for a living (besides their work at the university).

P.S. you used the phrase "neat peaking" somewhere in the essay. What is that?
Did you mean "nit-picking"? The latter phrase exists, but I fail to see its
relevance to the sentence - maybe you should rephrase that sentence.

-- 
Nadav Har'El                        |     Saturday, May 12 2001, 19 Iyyar 5761
[email-masked]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Ways to Relieve Stress #10: Make up a
http://nadav.harel.org.il           |language and ask people for directions.

---

From: Omer Zak <[email-masked]>
Date: Sat, 12 May 2001 15:04:44 +0300 (IDT)

I am replying only to Hackers-IL mailing list, as I am tired of getting
the same E-mail messages 2-3 times (especially in the long Linux BiDi
thread), because people post them to both Linux-IL, Hackers-IL and Ivrix
mailing lists...

Now, to the subject.

In other engineering disciplines, students learn only the theory in
academic institutions.  They learn how to compute stresses, to design
filters, to specify chemical reactors, and to select the right graph
theoretical algorithm for the task.

Then they go to work for companies (usually big corporations), and during
the first few years of their employment they learn the practical aspects
of their profession, including the project management aspect of it (and as
already pointed out, every engineering discipline has its own project
management challenge).

This is probably the way software engineering management and software
engineering should be taught.

By the way, it may be that the case of software is very special in that
software engineering management and software engineering are very related
to each other.  When designing a bridge, the way you compute stresses does
not have much influence upon the project management methodology used.  But
when you select a software development practice, this may have huge impact
upon the entire project management. 

> http://www.actcom.co.il/~choo/lupg/essays/software-engineering-and-uni.html

                                             --- Omer
WARNING TO SPAMMERS:  see at http://www.zak.co.il/spamwarning.html