Software and Society: What it Means to Be Professional

						
							

						
Man's achievements rest upon the use of symbols. - Alfred Korzybski

						
Why is our field struggling in its efforts to become and engineering discipline?  The answers lies in our heritiage as symbol processors and the patterns of evolution from craft to science.

						
“Higher order abstractions of lower order referents.” This is not recognized as a sentence. If fact, it is not recognized at all! This is something we learn to do as soon as we learn to speak. When we utter our first "Ma-Ma", we're not really referring to the organism that conceived, nurtured and gave us birth (although all of this is true). We refer instead to this object that floats into view when we cry, feeds us when we're hungry, and changes us when we need it. It even makes funny faces and keeps uttering the incoherent phrase "Ma-Ma". And whatever it is, it gets obvious delight when we form and utter "Ma-Ma" back to it. We are clueless about what a symbol is, but we know how to use it to our advantage.

						
The process of abstraction (in language) was introduced by Alfred Korzybski, and is demonstrated by the abstraction ladder[3]. The abstraction ladder can be used to show how we progress from the physical (atom/molecule level known as process level) through various abstractions layers to the actual use in language. For example, a "cow" ladder may include the following layers:

						

							

								
8. Wealth - The word "wealth" is at an extremely high level of abstraction, omitting almost all reference to the characteristics of Bessie.
								
 
								
7. Asset - When Bessie is referred to as an "asset," still more of her characteristics are left out.
								
 
								
6. Farm Asset - When Bessie is included among "farm assets," reference is made only to what she has in common with all other salable items on the farm.
								
 
								
5. When Bessie is referred to as "livestock," only those characteristics she has in common with pigs, chickens, goats, etc., are referred to.
								
 
								
4. The word "cow" stands for the characteristics we have abstracted as common to cow1, cow2, cow3, . . . cown. Characteristics peculiar to specific cows are left out.
								
 
								
3. The word "Bessie" (cow1) is the name we give to the object of perception of level 2. The name is not the object; it merely stands for the object and omits reference to many of the characteristics of the object.
								
 
								
2. The cow we perceive is not the word, but the object of experience, that which our nervous system abstracts (selects) from the totality that, constitutes the process-cow. Many of the characteristics of the process cow are left out.
								
 
								
1. The cow known to science ultimately consists of atoms, electrons, etc., according to present-day scientific inference. Characteristics (represented by circles) are infinite at this level and ever-changing. This is the process level.
							

						

						
In most cases, if we work diligently, we can work our way back down the abstraction ladder to "what the user 'really' means". If we step back though, and look at the higher order abstraction "software", what do we find when we get to the bottom of the ladder?

						
Even though I've wrestled with this question, in relation to software I still keep getting the same answer, “Nothing!” There is no lower order referent at the ladder's lowest rung. There is no object, no "atoms, electrons, etc., according to present-day scientific inference". Representations of the software exist, but I've never seen a "handful" of software.

						
Any sufficiently advanced technology is indistinguishable from magic. -- Arthur C. Clarke

						
This leads me to the conclusion that software is the "brain stuff" which executes on a computer, doing something useful for somebody. This brain stuff has no mass, no energy, nothing. Yet it transforms inputs into outputs, as if magic.

						
This is not the first time we've come upon things that we didn't quite understand. Physical phenomena have been observed for centuries before the underlying principles were divined. After a couple more centuries of scientific inquiry, the principles were organized and engineering became possible.

						
Perhaps this then is the start of the confusion about software being part of engineering. Both activities lack low order referents. Both activities involve "brain stuff". Both activities involve mathematical proofs, explanations and derivations.

						
To say however that creating software should fall under the engineering profession makes no more sense than to say accounting, or the actuarial mathematics should be part of the engineering profession. Some day when we better understand what this is all about, we may find that engineering and software are simply two branches of "brain stuff". A better analogy is to say that software is like engineering in that there are many branches sharing a common trunk.[1]

						
The discussion about adding software to the (professional) engineering disciplines is understandable, if misguided. No other technology has become as pervasive as fast, or has the impact on our lives that software has. The stuff is everywhere after only 40 years.

						
Similar to the evening news, it seems the bad news gets the majority of the air time. For every Denver Airport Luggage System, there are successes that never get air time, yet we take for granted. In my kitchen, only the can opener and toaster don't have keypads and readouts. My car's anti-lock brakes depend on software. In fact, if the main processor goes out, my car won't even run. I've never heard a story about these (or similar successes) on the news. Is it a wonder society is nervous about the quality of the software that pervades their life?

						
In her report, "Prospects for an Engineering Discipline of Software"[2], Mary Shaw makes several key points.

						
1. Activities generally start as crafts.

						
2. When there is sufficient experience and demand, the steps of the craft become more formalized, and the production/commercial phase of the activity is entered.

						
3. As science foundations are determined for the activity, professional engineering becomes possible.

						
4. Professional engineering and science exist in a symbiotic relationship with engineering providing new problems for science, and science providing new techniques for solving the engineer's problems.

						
5. As for software engineering "Unfortunately, the term is now most often used to refer to life cycle models, routine methodologies, cost estimation techniques, documentation frameworks, configuration management tools, quality assurance techniques, and other techniques for standardizing production activities. These technologies are characteristic of the commercial stage of evolution; software management would be a much more appropriate term."[2]

						
Software management issues are addressed by the Software Engineering Institute's "Capability Maturity Model" and the ISO9000 series of standards.

						
The Journey of a single step begins with a thousand miles.

						
So what should we do? To include software as a professional engineering discipline is doomed to failure since:

						
1. Creating software is still in the craft/production stage. As the primary resource is "brain stuff", I'm not convinced we'll ever move beyond this stage.

						
2. Finding a common core of knowledge applicable to all branches of software will result in abstracting up a step and result in those activities that Mary Shaw refers to (correctly in my opinion) as "software management", not software engineering.

						
3. Education in the field at this time seems somewhat disjoint from science and current practice.

						
At this point in time, it looks like the next step is one of education.

						
1. We need to teach software creators about best practices, models, and algorithms (and here might lie the eventual basis for engineering activities in software).

						
2. We need to teach software managers that "brain stuff" is:

						
· Not compressible in time. (Most late software is the result of bad date scheduling, not bad programming).

							
· Not necessarily easy to rework. Changing the structure of a program or system may be very costly. (as in time and dollars)

						
· Quality must be built in from the start, not inspected in at the end.

						
3. We need to teach society what are reasonable expectations with regard to software.

						
4. We need to teach ourselves what it means to be professional, and then start acting that way. [4]

						
Notes

						
[1] Check "Will There Ever Be Software Engineering", Michael Jackson IEEE Software, Jan/Feb 1998

							
[2] Prospects for an Engineering Discipline of Software, Mary Shaw SEI-90-TR-20

							
[3 ] Language In Thought & Action, Fourth Edition, S.I. Hayakawa, page 155

							
The "Abstraction Ladder" is based on "The Structural Differential," a diagram originated by Alfred Korzybski to explain the process of abstracting. For a fuller explanation both of the diagram and of the process it illustrates, see his Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics ( 1933 ), especially Chapter 25

							
[4] Three organizations I'm aware of that are involved in the issue of professionalism are:

							
Association of Computing Machinery

							
Independent Computer Consultant's Association (www.icca.org)

							
IEEE (www.ieee.org)

                

        
 Email this article to a friend.

        

        
Comments to: