Why is Software Engineering a Must?

Software engineering is a very rich knowledge field, that expands each day. Different proposals, different paradigms, different representation languages are proposed over and over. Some of them are incremental progress, some of them are just brand new ideas and some are just old stuff with new clothes. It is hard to separate the wheat from the chaff. That is exactly where a sound knowledge in software engineering will come into play.

Teaching software engineering for undergraduate students is considered, by several, a challenge, since at this level of maturity it is hard to convince people that producing software is not just hacking. Worse is the task of communicating to society, what is the role of software engineering and why is it a must.

Usual motivation found in books, special interest groups (see Risks) and in tech-transfer courses are stories from previous projects that somehow failed and that the failure can be traced back to software.

Most of this literature is anedoctal, since it does not provide the details of exactly where the failured ocurred and the reason for it. One of the exceptions, is the London Ambulance inquiry report. I and my co-authors have used this report to gain more insight on failures related to requirements. There are other reports, but mostly of the accounts are of anedoctal nature. This is not a criticism, since all reports that help clarifiying the complexity of software production are more than welcomed.

Software is pervasive, it is everywhere, and its use is increasing at an astonishing rate. However, do you know of a software product that gives warranties about its correct behaviour? Well, if you do, let me know.

My master thesis, back in 1979, was on software costs. I have proposed, at that time, a cost accounting strategy to help software developers keep annotations about work being developed according to cost centers. Well, it was an academic exercise, but I believed it could have helped software engineers. Maintaining a history of annotations would provide a repository for future cost estimation. Well ... I could not convince companies to adopt my proposal, and it took several years that such proposals started to become popular in organizations. An excelent example of this kind of maturity, is its enactament in the micro -- Humphrey´s PSP, which helps the build up of the human resources for mature software organizations. However, it is not trivial to have a process to keep track of workhours and cost centers in sofware organizations.

More and more, we listen to speakers and read writers that tell us of the complex social web of producing software. It is a fact that the technological approach is just part of the picture.

Well, what is the point of this post, "why is software engineering a must?". The point is that we, software practioners, software educators and software researchers must try to make software engineering more transparent to the society at large. Only, by understanding how complex is software production, will society value software engineering.

Well, like most posts, this is a first draft on my thoughts on that subject. What did trigger this writing? I found, in delicious, a tag pointing to a IEEE Spectrum article on the September, 2005 issue. Nothing new to software engineers, but this is the kind of anedoctal report that helps society understand why is software engineering a must.