Learning Software Engineering

There is a difference between the computer skills taught at university and the skills that are needed by the software industry. The difference seems to be the way academic view of how computer theories must be taught to students and the experiences of the professors. The academia view of teaching is focusing in a series of lectures about computing theories and practice using programming assignments. While this is a reasonable approach, such lectures and class assignments often lack an “in-depth knowledge” of what happened in real software projects. That is why many students who are very good in school have difficulty to apply their theories into practices when working in software industry. Following are some differences:

The academic approach emphasizes:

  1. The construction of small programs, about few hundred lines of code.
  2. The use of few programming languages such as Pascal or C.
  3. Everything always “start new” for each assignment.
  4. School rarely teaches the use of software tools or Commercial-off-the-shelves (COTS) products.
  5. Programming in isolation or in small groups.
  6. The belief that if a program “works”, it is good.
  7. An informal development approach (Mostly coding) rather than rigorous that requires more skills.

Practicing software developer in industry must have to deal with:

  1. Software systems that are large, often hundred thousands or millions lines of code.
  2. Several programming languages, Pascal and C are NOT used anymore, to be replaced by Java, C++, C # and Ajax;
  3. Existing systems remain important and have to be maintained and continuously updated. Rarely you start something new;
  4. Most companies have hundreds of software tools and extensive use of Commercial-Off-The Shelves Products
  5. Most development efforts that are undertaken by large teams, no one works alone.
  6. There are many cost performance trade-offs in business contexts. A program that “Work” may not be good enough;
  7. Every development must follow a well-defined processes and standards.

Clearly, these two approaches are NOT in line with each other, that is why so many computer science students suffered in the software industry and have to be retrained before they can be productive.

Another major issue is the identification of knowledge and skills. Knowledge refers to what student “know” but skills indicate things that students should be able to “do”. Furthermore the skills can be specified with a “depth” (Familiarity, Practice, and Mastery) based on experiences and length of practice. Unfortunately, most university professors never work in software industry or have been exposed to these practices so they only focus on teaching theories but not practices so students never have a chance to develop an in-depth knowledge of some subjects.

Today, most top universities in the world are replacing traditional assignments with “simulated scenarios” where students must apply what they learn in solving “real problems”. With this approach, students can develop their skills by applying the knowledge they learned in class and receive feedbacks from professors. This is the main reason why most software engineering programs is focusing on “the process” or the sequence of activities that software engineering must follow rather than learning abstract theories. In traditional lectures method, software process is difficult to teach because unless the professor have actual industry experiences, it would be difficult to explain the concept of process to students who are simply sitting and listening to the instructions. To learn “process” they must “do it”.  (The Learning by Doing method).

For example, in the simulated scenario approach, there are multiple events happen at the same time; so students must frequently interrupt their activities to work on others just like in real project. They learn how to prioritize their works because doing the same way every time will not lead to the same results. In scenario approach, there are several random factors such as requirements changes, team member change, customers change and schedules change just like in real project so student learn that there are conflicting goals that sometimes interfere with each other that they must solve. Students’ actions are to identify certain goals as more important than others, and some goals that can be attained when others can be postponed or partially fulfilled. Students will learn that for every project, there are multiple users and customers that each try to satisfy their own needs so they learn how to negotiate and compromise just as they will do in real projects.

I believe this new approach is far superior than the traditional approach, especially in teaching software engineering or other technology fields.

Sources

  • Blogs of Prof. John Vu, Carnegie Mellon University
"Like" us to know more!