Thursday, March 23, 2006

What has software engineering learned from the Y2K problem?

In my lectures I mention the y2k problem and year by year more and more students have not heard about it.

Back in 1999 I was certain that the y2k event and all the media it was generating would be important to the dissemination of software engineering. I am not certain that this was the case.

I remember listening to a talk by Ed Yourdon where he mentioned that cars could have problems, elevators, … and so on. I remember a page at Vassar College where students were advised to have flash-lights, cash and food! Anyway, the hype about the problem had generated massive media, as well as huge investments on avoiding the crisis.

The 2000 started and no big event did happen regarding the y2k. Was it a victory of software engineering? I doubt it. I strongly recommend the reading of a report by Prof. Finkelstein. He was one of the few, at the time, that were questioning all the hype about the y2k.

Anyway, back to 2006. In trying to remember what did happen I decided to use my “memory”. I could not find the page at Vassar, but found a page at NC State where there was a list of y2k links. I decided to follow two links that I had visited last century: the U.S. President's Council on Y2k and the U.S. Senate Special Committee on the Year 2000 Technology Problem. Both of them were unreachable. However, the way back machine (as suggested by Finkelstein) did come handy.

The archive on the U.S. President Council has a list of lessons learned, but, using the last entrance on the archive, there are several missing links. Fortunately the U.S. DOD report is still available.

Well … we should think about it: what have software engineering learned from the y2k?

Wednesday, March 08, 2006

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.