Why is Software Engineering so Different from Other Types of Engineering?

1. Why is Software Engineering so Different from Other Types of Engineering? Some Ruminations on the Nature of Software Engineering Dr. M.S. Jaffe

2. Quick Map • What is so different about software? • What does that imply for the process by which it is engineered? • Does software engineering have anything in common with other forms of engineering?

3. Two Key Factors That Make Software Different • The extreme imbalance in the complexity of the functional requirements • The essentially infinite plasticity of the medium (software)

4. Functional Complexity Software artifacts Other artifacts Stimulus/response behavior is the only type of functional requirement* for software in any type of system Always include and are (usually? always?) driven by functional requirements that are not simply stimulus-response behavior† The number of discrete behavioral cases to be individually engineered is typically amazingly large Many (most? all?) characteristics specifiable as a small set of numbers† or via a (relatively) small set of continuous equations and some boundary conditions * Requirements that state the purpose of the system; what is it for, what is it supposed to do? † E.g., the required payload of an airplane

5. The Medium of Software • All other media used in engineered artifacts (e.g., steel, concrete, electrons) are material and subject to material laws, software is not material • There are very few statements about software in the abstract known with anything approaching the mathematical or scientific rigor of physical/material “laws” • E.g., the unsolvability of the halting problem

6. The Significance of Behavioral Complexity • The domain-specific set of conceptual abstractions by which software requirements are initially expressed is much larger and more diverse than the equivalent for other engineering projects; useful abstractions may not even be initially known • “Design a bridge to span the straits of Gibraltar that will carry eight lanes of highway traffic” vs • “Design an air traffic control system for the United States that will … … will what?” • As a result, the requirements are usually much less well understood at the beginning of a software project than for other types of engineered artifacts

7. The Significance of Behavioral Complexity (cont’d) • For other engineered artifacts, figuring out the requirements is often not even really considered part of the engineering process, or at least not one which requires special techniques, skills, and tools • For software, a large portion of the overall project’s time and effort is spent in the “softest” engineering phase (requirements specification) trying to figure out and unambiguously specify precisely what constitutes acceptable behavior for the final software artifact

8. The Significance of Plasticity • Other engineering is heavily oriented towards “satisficing” – a search for some way, almost any way, to combine known materials within various material constraints to solve the stated problem • The result is generally a reasonably small number of workable designs that are then evaluated with respect to other (non-functional) requirements/constraints (e.g., cost, reliability) • As a result of the plasticity of software, there are many fewer a priori constraints on any set of possible software designs applicable to a given project – the medium is essentially infinitely plastic (Brooks, 1972)

9. The Significance of Plasticity (cont’d) • For software, it is almost always possible to produce a virtually infinite set of workable designs, but there are few “measures of goodness” available to evaluate them • Many of the “standard” engineering constraints either don’t apply at all (e.g., availability) or won’t be useful discriminants early enough, if ever (e.g., cost)

10. Plasticity: Which ATC S/W Design is Better? global data global data track file track file design #1 (asynchronous) design #2 (synchronous) Radar Data Processing Radar Data Processing Display Processing Flight Data Processing Display Processing Flight Data Processing design #3 (asynchronous) design #4 (synchronous) Radar Data Processing Tactical Processing Radar Data Processing Display Processing Tactical Processing Strategic Processing Display Processing Strategic Processing

11. The Significance of Plasticity (cont’d) • As a result of plasticity, software designs are really not evaluated as much (as other types of engineering designs) on the question of “do they work?” or “how well do they work?” as on other, less well understood, less easily quantifiable attributes or constraints – e.g., maintainability, reliability, operability • Note: The terms appear the same (e.g., maintainability, reliability, operability) but they are no where near as well defined or as measurable (if at all) in the software domain as they are in any other engineering field.

12. The Overall Result • Software engineers spend far more of their time struggling to express or evaluate incompletely or poorly understood concepts (in requirements and design, both) • Indeed, in the requirements arena, the trend these days (OOA) is to view a significant portion of the effort as the synthesis of a comprehensible conceptual vocabulary (the classes) • Quantitative analysis of design is mostly confined to fairly late in the process and tend to be much heavier on discrete analysis than analogue