Preparation: A Critical Component for Software Productivity
Raman Kannan
{kannan@moncol.monmouth.edu} {http://www.monmouth.edu/monmouth/academic/dna}
Software Engineering Department
Monmouth University,
West Long Branch, NJ 07764
Judging by the unabated rise in software related woes it is not very difficult to conclude that engineering software artifacts is really a myth. Because by definition engineering is "the application of mathematical and scientific principles to practical ends, as the design, construction, and operation of economical and efficient structures, equipment, and systems" [1]. And yet in the last few decades: (1) several new technologies and methods have been introduced in an unrelenting progression; (2) software infrastructures have been augmented -- and in some cases completely replaced -- with more power and capacity. In particular these were introduced to stem the S/W(oes)! May be there is some truth to the recent observation in [2] that S/W is a dismal science. And verifiably a poorer engineering discipline. This grim reality begs the question "What really is missing?". Most definitely it is not the lack of technology. It is the lack of understanding of technology (how to use, when to use, what is it). Furthermore, having worked in the industry and now as a member of the academic community, I posit it that the root cause is the lack of "holistic" preparation of our software professionals. Perhaps, that --our educational system (pertaining to S/E) is astray-- is not an isolated opinion, as evidenced by recent articles on effective teaching. For example, in [3] the authors identify that (1) Teaching (as we know it) OOP stops with communicating the features of a particular PL, and suggest that to teach programming skills effectively, we need examples of interesting problems solved in a step by step manner and focusing on the design consideration that a skilled programmer applies. In [4] Susan Lilly recommends that as fundamentally different technologies emerge we ought to teach them in fundamentally new ways. In [5] Caper Jones [summarily rejects] argues that universities as a class have not faired well in [for] software professional training. And, finally in [6] Bruce Weide reminds that "Educator's contributions to the muddle [software in perennial state of crisis] should not be overlooked."
Starting from first principles, a standard dictionary definition of Education is "teaching a body of knowledge and skills to deal with situations and solves problems not yet determined." We can reason either about how we teach or about what we teach. In this short report the subject is what should we teach and my emphasis is on "holistic" understanding and appreciation of software and all related processes as shown in Figure 1.
Figure 1: N-Dimensions of Software Engineering
Strange as it may seem for us in the software engineering community, "holistic" approach (elaborated by Blum in [7]) is anything but new in the traditional engineering disciplines and is known as "Concurrent Engineering" [8]. In engineering domains, for efficiency and expediency, solutions are devised by addressing the problem from three orthogonal but inter-connected perspectives: (1) people {consumers and producers}; (2) processes (the how); and (3) product (the "what" technology, includes both end products that we create as well as enabling products that help us create).
Because, the S/W discipline is still evolving and frequently undergoes violent changes (migration to client/server, graphical user interface, object orientation etc.) Figure 1 is by no means complete but there is a purpose to Figure 1. Before someone can claim to be a software professional one must develop an understanding and appreciation of the various facets of S/E and how they relate to each other. Depth in an isolated specialization is not enough. There is much too common between "medicine" and S/E. Imagine doctors specializing in cardio-surgery before they understand how the body fits well together, as in anatomy. Thus, specializations--as in Programming/Designer/Tester and others--must come after holistic preparation. Just as doctors in the medical profession undergo "Residency", software professionals must also undergo industrial residency so that they understand how the n-dimensions of S/E merge and mesh in the real world. Without this residency, our graduates shall remain "programmers", "designers", "project managers", and so on. But not "Software Professionals" in the real world.
Here in, during the residency period, they will learn, that:
In summary we like to part with the venerable adage "every coin has two sides". Thus while the producers (places of learning) can attempt to improve and be effective in training S/W professionals, the consumers (industry/government employing our graduates) must also learn not to ride hype-waves. More precisely, control the urge to use the latest and greatest tool just because it is fashionable without proper training. Such haste will certainly result in disappointment and S/Woes. A specific case in point is, "Designing Objects like Functions" as reported by David Taylor in [10]. More of this coming in the form of "Pattern hatchers", "Java Brewers", "Me Too on the internet", etc. Such cultural barriers also have to be addressed before we can really engineer software artifacts.
[1] WEBSTER's II New Riverside University Dictionary.
[2] Ted Lewis, "The Next 10,000 Years: Part II", IEEE Computer, May 1996.
[3] K.V. Viswanathan, "Teaching OO Programming", JOOP, May 1996.
[4] Susan Lilly, "In Search of the philosopher's stone and the silver bullet", Object Magazine, 81-82, March-April 1994.
[5] Capers Jones, "How software professionals learn new skills?", IEEE Computer, December 1995.
[6] Bruce W. Weide, "Challenges of Software Design and the Undergraduate computing curriculum", IEEE Computer, 31-32, August 1995.
[7] Bruce Blum, "Software Engineering: A Holistic View", Oxford University Press, 1992.
[8] Product, Process, Organizational (PPO) Modeling, In the "Red Book of Functional Specifications for the DICE Architecture", Editors: Joseph Cleetus and Wayne Uejio, CERC, West Virginia University, 1989.
[9] Patricia J. Douglas, George M. Alliger and Robert Goldberg, "Refining the Curriculum Client-Server and Object Oriented Training", IEEE Computer, June 1996.
[10] David Taylor, "The use and abuse of reuse", Object Magazine, 1996, April.