Why Do Universities Fail Teaching Software Engineering?

 

(퍼옴) http://users.actcom.co.il/~choo/lupg/essays/software-engineering-and-uni.html

v1.0.2

Why Do Universities Fail Teaching Software Engineering?

Table Of Contents:

1. Abstract
2. What Is Software Engineering?
3. Software Engineering And Students
4. More On Students
5. More On Universities
6. How To Make It Work?
7. Financing Academic Software Projects

---

Abstract

Many universities and other institutions try to teach software engineering concepts to their students, either as part of their regular programming courses, in courses designed to teach just software engineering, or as a set of such courses.

In this short essay, I'll supply a loose definition of "Software Engineering", show why it is so hard (or impossible) teaching it to inexperienced programmers, and try to illustrate a few methods that may be used to still put some sense of engineering into inexperienced programmers.

---

What Is Software Engineering?

Software engineering is a methodological process of writing software, in a manner that can be repeated for various software projects in a high level of accuracy, and produce good software, under given time and budget constraints.

Lets explore this definition a bit. The methodology means that the software creation process is broken down into several steps, each of which is self-contained, and can be described easily, without using "magical" terms, as is common in the software industry ("i didn't know where to start, so i just hacked down something, and somehow it worked").

For example, one may break software creation into steps such as "requirements specification", "architectural design", "interface design", "detailed design", "implementation", "integration" and "testing". Each of these steps can be properly defined (e.g. "requirements specification is a step in which we define the set of functionalities our software will support, without defining yet how it will support them, or how any kind of user-interface would look like").

Good software would imply that the software does what it is supposed to do, that it has few bugs, that it can be easily maintained, and that it is relatively cheap to extend and add new features without introducing many new bugs.

The software doing what it is supposed to do might sound trivial, but in many cases the original requirements get massively cut down because the software fails to perform various operations properly. easy maintenance would mean that it would be easy for a new programmer to learn how the software works and how to fix bugs in it, and that fixing bugs does not require rewriting complete parts of the software. Easy extension would mean, for example, that the software can be easily ported to new platforms, can easily have its user interface replaced (text UI to graphical UI, or web UI) without rewriting the rest of the system, and so on.

Finally, every software development project has some limits on the amount of time until it has to be ready, and the amount of money that can be spent on the software. The engineering process should make it possible to supply a rather accurate forecast for the time and effort it will take to develop different modules of the software, using different designs. The time limits often come on expense of future maintainability and expend-ability of the software, and these issues need to be weighed against each other, and weighted appropriately, depending on the software requirements.

---

Software Engineering And Students

From the above description, one can see that software engineering introduces a lot of overhead to software development, and that this overhead might only be worthwhile for large software development. Using such process for small class exercises of few hundreds lines of code is an overkill and makes students despise or even ridicule the idea of software engineering.

Another problem with software engineering, is that it can't be practiced without understanding that small decisions have big implications on large programs. For example, suppose that a method of a communications class returns a pointer to an object it has allocated. Who should be in charge of freeing that memory? The caller of the method, or the object that initially allocated the memory? What happens if in one place its easier to have the caller free the memory, and in another place its easier to make the allocating object free the memory? an inexperienced programmer would most likely do the easier thing in each case, claiming that the simplicity of the code is important, and would overlook the importance of consistency. For a small program, it won't do much harm - since the program is written in a short time, the programmer can remember who should free the memory in each case. Even if they don't, and have a memory leak, they are not going to run this program long enough to notice - once it works, it gets dumped.

The same little decision would have a much bigger impact on a large software, that is supposed to last. A large software tends to have hundreds or thousands of classes, and not each one of them is used very often. If you had consistent rules (e.g. "the object allocating memory is always in charge of freeing it"), it will be easy to remember when to free allocated memory, and thus having less memory leaks and memory corruptions to chase.

---

More On Students

As we saw, software engineering requires large projects to make sense. It also requires experience to make sense. In particular, bad experience - if you write software in the right way, you don't get to see how wrong badly written software can get, and thus don't learn to appreciate the right ways. Thus, part of learning software engineering is achieved by seeing how lack of it can hurt large software projects. For students "a large project" might be something they have written in one semester, in which they also studied a few other courses.
Given a software made of a few thousands lines of code, or a few tens of classes, inexperienced programmers consider the software to be a large project. Later on, when they get out to work in the industry, they will begin to realize those were in fact rather small projects. In such small projects, lack of proper engineering won't usually reveal the problems it causes, since those projects only need to work once or twice (when demonstrating them to the teacher) and don't get developed further afterwards.

Another aspect of software engineering is designing the software to be easy to maintain. Since most student projects don't get tested by end-users users, many of their bugs remain hidden, and thus the programmer isn't exposed to the amount of time it would take to debug and fix it until it becomes on the level of usable release software - something which often would take more than the amount of time it took to originally write the code and make it run. The original developer of the code tends not to stress-test their code in its weak spots, since they subconsciously know it'll cause the software to crash or malfunction - something which will require more work, that isn't really appreciated when the project is graded. Thus, the programmer cannot see how their software design affected the ability to isolate bugs in the code, and get the false impression that their design generated bug-free software.

Another aspect of learning about software engineering, is seeing how it affects the life cycle of a software project. Sometimes, experienced software engineers make decisions that look like small neat-peaking to the naked eye. Only after a while, as the project evolves to different directions, these original decisions begin to make sense to an inexperienced programmer. Some people will claim that this ability to see the need for those small decisions in advance comes with experience - and yet, this is what software engineering strives for - the ability to make these decisions using a methodological process, that generates repeated success.

Finally, there are students that understand the rules of thumb, and believe that they might be useful, but still prefer not using them for their exercises on the grounds that understanding is enough, and when they get involved in large projects, they will know how to deal with them. The problem is that by the time they get to working on large projects, they might gather bad habits and find it hard to free themselves of these bad habits. They also overlook the little things that can only be achieved with real practice, and thus will stay behind fellow students, who have spent a few years of their undergraduate studies to actually apply these rules, and gained some experience, and thus more insight.

So the conclusion we come to is that you need good familiarity and hands-on involvement in large and lasting software projects, both successful and failures, in order to grasp the essence of software engineering, and appreciate it. And in university environments (or various programming courses, for that matter) the ability to participate in such activities is rather limited.

---

More On Universities

What do universities do in order to try and teach software engineering? One thing they do is try to teach it as a set of rules of thumb, hoping that students will follow them, even if only because they are being enforced somehow when grading exercises and exams. The problem with this approach is that often the people who do the actual grading are graduate students, who themselves haven't had the chance to grab the concept of software engineering (especially if they entered graduate school directly after finishing undergraduate school).

Even if some of the teachers, or teaching assistants, do have experience with large and lasting software projects, often their students don't know about that, and hence don't trust them. When you don't trust someone, you don't listen to advise they give you if you cannot see an immediate benefit (and in software engineering, there is no benefit for very small exercises). Thus, the students actually tend to ignore their teachers' rules of thumb, seeing them as a burden, and this causes more damage than if those rules were never given in the first place.

At other times, there might be a good software engineering teacher, that indeed has experience in the field, and tries to show some real life examples to their students. These efforts, however, might be lost if the students don't get their own hands-on experience with such software. Learning software engineering on a theoretical bases, and using small code examples (since there is no time to really delve into large code examples) makes no sense, except for people who already understand software engineering in the first place - kind of a chicken-and-egg problem.

---

How To Make It Work?

After seeing what is needed to make students appreciate software engineering, we might as well spell out a few things that will make teaching it possible. First, we need to have accredited teachers. These teachers may either be people with past or current experience in the industry, that can use it to back their claims to students. They could also be people who participated in large academic projects, that got enough credit for being large and lasting. A good example would be the work done in the MIT university, and their Athena project (see also A review of - MIT project Athena: a model for distributed campus computing). Another good example is the work done at the Washington university in Seattle, by the Distributed Object Computing (DOC) group. There exist various other such examples. The important factor is that they are large projects, involve quite a few staff members (including graduate students), and last for quite a few years, and thus carry a scope similar to that of large industrial projects.

It is also important that the students will know that their teachers have that experience. This is not to be used as a method of bragging, but rather to assure the students that their teacher is not just talking about theoretical software engineering methods; That the teacher has actually applied them, and can show them good, real-life examples, of why these methods are useful, and should be practiced even for smaller projects.

Carrying out large projects by university staff members is also good as it allows graduate students to participate in such projects, and thus be more credible to serve as teaching assistants in software engineering related courses. With good project management, it is also possible to allow undergraduate students to take part in such projects, and witness, from first hand, the complexity of such a project. When they have to delve into code created by other programmers, possibly code that is 2-3 years old, they will learn to appreciate how hard it is to get into code parts that weren't properly engineered, and how relatively easy it is to get into parts that were properly engineered. And having specific parts of the code that are badly engineered on purpose, would serve the teaching goal quite well.

Of-course, getting students involved in large software projects should be done gradually. At first, they may be introduced to small modules, learn them, and be guided in making small changes to them. It is a very useful quality to be able to delve into existing source bases, and inexperienced programmers often find it hard to do. At later phases, these students will be able to write new classes or modules. Getting credit for such projects will be more desirable than letting these students design their own software in a software project course, that will turn out to be small (they don't have enough time to work on it, and usually only 2-3 of them work on the code of such project) and having to create software that will most likely not last, and not be a part of a lasting project.

---

Financing Academic Software Projects

One of the major problems with carrying large software projects in universities is financing them. You need more equipment than with theoretical research, more system management staff, and more researchers than for a theoretical research.

The equipment needed is often not so hard to get as a donation from large hardware manufacturers and resellers. They already have such donation relationship with universities, sometimes donating full labs for students to work on, in a hope that these students will get used to their development environments, and endorse them when they get some influence in their future working place.

Another option is carrying software research projects that are useful for large industrial companies. Showing these companies how this research can help them, it is possible to convince them to sponsor such projects. The fact that financing a project in which graduate students and undergraduate students perform large parts of the work, would be cheaper than financing it inside the industry, it might look appealing to industrial companies. The TAO project carried by the DOC group at the Washington university and university of California, is a good example of such a relationship.

Another major problem is attracting good software engineers that both wish to carry out research work in their field, and have the skills to manage large projects at the same time. The success of such a project in fact often relies on one or more such enthusiast leaders, that carries a good reputation in the academic field, as well as in the industry. It would be easier to attract such people to the academy, if they know they will get a supportive environment, and financing to projects that will seem feasible and are personally appealing to them. Sometimes, it does not require paying them better than in the industry. The fact that they get more freedom, and without the pressure of marketing personnel, would be enough to attract a few of them to moving to the academic world.

---

[LUPG Home] [Tutorials] [Related Material] [Essays] [Project Ideas] [Send Comments]

This document is copyright (c) 2001-2002 by guy keren.

The material in this document is provided AS IS, without any expressed or implied warranty, or claim of fitness for a particular purpose. Neither the author nor any contributers shell be liable for any damages incured directly or indirectly by using the material contained in this document.

permission to copy this document (electronically or on paper, for personal or organization internal use) or publish it on-line is hereby granted, provided that the document is copied as-is, this copyright notice is preserved, and a link to the original document is written in the document's body, or in the page linking to the copy of this document.

Permission to make translations of this document is also granted, under these terms - assuming the translation preserves the meaning of the text, the copyright notice is preserved as-is, and a link to the original document is written in the document's body, or in the page linking to the copy of this document.

For any questions about the document and its license, please contact the author.