Browse Prior Art Database

Splitting the Difference: The Historical Necessity of Synthesis in Software Engineering

IP.com Disclosure Number: IPCOM000129980D
Original Publication Date: 1997-Jan-01
Included in the Prior Art Database: 2005-Oct-07

Publishing Venue

Software Patent Institute

Related People

STUART SHAPIRO: AUTHOR [+2]

Abstract

By the end of the 1960s, it was becoming obvious to the computing community that software was a big problem and growing bigger. While the cost of hardware steadily declined even as hardware performance steadily increased, software seemed headed in the opposite direction. Large software projects were consistently late, over budget, and full of defects. Today, the complaints remain much the same. This is not to deny that the current situation represents a drastic improvement over the state of affairs that prompted the North Atlantic Treaty Organization (NATO) software engineering conferences of the late 1960s. What were problems then are still problems now, but they tend to be (but not always) relatively less frequent and less disastrous, especially in the context of the vastly expanded size and ambitions of much contemporary software. Indeed, Andrew Friedman has argued that while software was previously the key stumbling block for systems development, the focus has now shifted to user needs.l While Friedman is right to call attention to the current emphasis on user needs, though, his periodization based on successive bottlenecks is a little too tidy and belies the complexity and heterogeneity of the issues and arguments that have surrounded systems development from the early days to the present. Events of the late 1960s enhanced comprehension of the breadth and depth of the problems plaguing software development while only hinting at solutions. Still, the growing recognition that a collection of interrelated problems existed, together with an awareness of the importance of process, constituted a turning point in the history of software technology. The ";software crisis"; provided a context for the development of software technology in the 1970s and beyond. From the 1960s onward, many of the ailments plaguing software could be traced to one principal cause -- complexity engendered by software's abstract nature and by the fact that it constitutes a digital (discrete state) system based on mathematical logic rather than an analog system based on continuous functions. This latter characteristic not only increases the complexity of software artifacts but also severely vitiates the usefulness of traditional engineering techniques oriented toward analog systems.2 Although computer hardware, most notably integrated circuits, also involves great complexity (due to both scale and state factors), this tends to be highly patterned complexity that is much more amenable to the use of automated tools. Software, in contrast, is characterized by what Fred Brooks has labelled ";arbitrary complexity.";

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 2% of the total text.

Page 1 of 46

THIS DOCUMENT IS AN APPROXIMATE REPRESENTATION OF THE ORIGINAL.

Copyright ©; 1997 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Used with permission.

Splitting the Difference: The Historical Necessity of Synthesis in Software Engineering

STUART SHAPIRO

For the last quarter of a century. software technologists have worked to address the "software crisis" identified in the 1960s. Their efforts have focused on a number of different areas, but have often been marked by the search for singular "best" solutions. However, the fundamental nature of software -- involving basic and poorly understood problem-solving processes combined with unprecedented and multifaceted complexity -- weighs heavily against the utility of singular approaches. Examination of the discourse of software technologists in a number of key professional and trade journals over the last 25 years illuminates various disputes central to the development of software engineering and highlights the necessity of a more pluralistic mindset revolving around synthesis and trade-offs.

Introduction

By the end of the 1960s, it was becoming obvious to the computing community that software was a big problem and growing bigger. While the cost of hardware steadily declined even as hardware performance steadily increased, software seemed headed in the opposite direction. Large software projects were consistently late, over budget, and full of defects. Today, the complaints remain much the same. This is not to deny that the current situation represents a drastic improvement over the state of affairs that prompted the North Atlantic Treaty Organization (NATO) software engineering conferences of the late 1960s. What were problems then are still problems now, but they tend to be (but not always) relatively less frequent and less disastrous, especially in the context of the vastly expanded size and ambitions of much contemporary software. Indeed, Andrew Friedman has argued that while software was previously the key stumbling block for systems development, the focus has now shifted to user needs.l While Friedman is right to call attention to the current emphasis on user needs, though, his periodization based on successive bottlenecks is a little too tidy and belies the complexity and heterogeneity of the issues and arguments that have surrounded systems development from the early days to the present.

Events of the late 1960s enhanced comprehension of the breadth and depth of the problems plaguing software development while only hinting at solutions. Still, the growing recognition that a collection of interrelated problems existed, together with an awareness of the importance of process, constituted a turning point in the history of software technology. The "software crisis" provided a context for the development of software technology in the 1970s and beyond.

From the 1960s onward, many of the ailments plaguing software could be traced to one principal c...