Defining a Stable Core

Knowledge that helps developers deal with what Brooks calls the "essential difficulties" of software development is what I think of as "software engineering principles," which make up software engineering's core body of knowledge. In 1968, NATO held the first conference on software engineering. Using the term "software engineering" to describe the body of knowledge that existed at that time was premature, and it was intended to be provocative.

Exactly how small was the stable core in 1968? Consider that the first fully correct binary search algorithm was published in 1962, only six years before the NATO conference.[3] C. Böhm and G. Jacopini published the paper that established the theoretical foundation for eliminating the goto and the creation of structured programming only two years before the conference.[4] Edsger Dijkstra wrote his famous letter to the editor, "GoTo Statement Considered Harmful," in 1968.[5] At the time the conference was held, subroutines were a fairly new idea, and programmers regularly debated whether they were really useful. Larry Constantine, Glenford Myers, and Wayne Stevens didn't publish the first paper on structured design until six years after the conference in 1974.[6] Tom Gilb published the first book on software metrics in 1977,[7] and Tom DeMarco published the first book on software requirements analysis in 1979.[8] Anyone who tried to identify a stable core of knowledge in 1968 would have had their work cut out for them.

From an analysis of the SWEBOK project's Body of Knowledge areas (which I'll discuss later in this chapter), I estimate that the half-life of software engineering's body of knowledge in 1968 was only about 10 years. As Figure 5-1 illustrates, the stable core was relatively small, and I estimate that only about 10 to 20 percent of software engineering knowledge from 1968 is still in use today.

Figure 5-1. As of the 1968 NATO Conference on Software Engineering, only about 10 to 20 percent of the software engineering body of knowledge was stable (i.e., would still be relevant 30 years later). The half-life of the software engineering body of knowledge at that time was about 10 years.

graphics/05fig01.gif

Software engineering has made significant progress since 1968. Hundreds of thousands of pages have been written about software engineering. Professional societies host hundreds of conferences and workshops every year. Knowledge has been codified into more than 2,000 pages of IEEE software engineering standards. Dozens of universities across North America offer graduate education in software engineering, and dozens more have recently begun to offer undergraduate programs.

The fact that we do not have perfectly stable knowledge of software engineering practices hardly makes software engineering unique. In the 1930s, the medical profession did not yet know about penicillin, the structure of DNA, or the genetic basis of many diseases, and it did not have technologies such as heart-lung machines and magnetic resonance imaging. And yet there was a profession of medicine.

As Figure 5-2 suggests, based on my SWEBOK knowledge-area analysis, I estimate that as of 2003 the stable core now makes up about 50 percent of the knowledge needed to develop a software system. That might not seem like a dramatic change from the 10 to 20 percent of 1968, but it implies that the body of knowledge's half-life has improved from about 10 years to about 30 years. That means that the educational investment a person makes at the beginning of a career in software will remain largely relevant throughout that person's career.

Figure 5-2. As of 2003, about 50 percent of the software engineering body of knowledge is stable and will still be relevant 30 years from now.

graphics/05fig02.gif

Stabilization of software engineering's body of knowledge puts software engineering on an educational footing similar to other engineering disciplines. As David Parnas points out, the content of a physics class can remain unchanged even if the lab gets a new oscilloscope. Most of the content of software engineering courses can be independent of specific, relatively short-lived technologies like C++ and Java. Students will have to learn those technologies in the lab, but in the classroom they can focus on more lasting knowledge.



Professional Software Development(c) Shorter Schedules, Higher Quality Products, More Successful Projects, [... ]reers
Professional Software Development(c) Shorter Schedules, Higher Quality Products, More Successful Projects, [... ]reers
ISBN: N/A
EAN: N/A
Year: 2005
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net