Software -- Engineering or Craft?

When software developers thoroughly understand the processes they're modeling, then software development lends itself to well-engineered processes. On the other hand, where it's hard to define software requirements, then the challenge of specifying a formal, universal process for consistently creating high-quality software is exceedingly difficult.

Software engineering arose out of a traditional approach for dealing with clearly defined problems and needs. Issues of management, cost, and robustness are paramount -- not how to define problems. Software engineering methods, such as SEI's CMM (Carnegie-Mellon's Software Engineering Institute Capability Maturity Model), were patterned primarily after domains described according to physical laws and defined parameters -- not dynamic evolving systems.

Agile software development methods emerged from within programmer communities where solutions to problems tend to unfold over time. Craft-based approaches highlight the centrality of individual producers. A transparent open-ended process is best suited to situations where software requirements are not well understood, or needs are poorly articulated.

Generally, software developers will only agree on pragmatic methods that work. These are usually just simple rules of thumb, such as:

• test early and test often
• perform daily builds
• focus lots of resources on getting requirements correctly understood up front

Most attempts by software developers to draw upon and apply quantitative methods from other disciplines -- like manufacturing's Total Quality Management (TQM) or engineering's Statistical Quality Control (SQC) -- have resulted in less than stellar success. For example, while TQM is an important tool for manufacturing, it is far less effective when applied to design -- and software development is a pure design activity. Moreover, questions of design, especially domain knowledge specification, don't generally lend themselves easily to pure statistical analysis.

Software development will never be manufacturing, except to the extent that manufacturing is a design activity. Design is an inherently buggy process. The nature of design means that mistakes and unforeseen/unintended consequences will occur.

The key to software development is translating knowledge into execution. Formalizing this process has thus far proven to be all but impossible. Whereas most people can almost instantly describe a car's overall design, asking someone to describe a factory process for making cars is more difficult. Asking someone to define the process of designing a factory for making cars poses an even greater challenge.

---

Software as Construction

Construction can serve as a helpful model to highlight key questions and assumptions about software methodologies.

Building takes a variety of final forms -- from individual housing to large-scale urban commercial projects. Do-it-yourself amateurs, independent local contractors, large construction firms, and global engineering companies do the actual building.

A division of labor exists between architects, developers, and builders. The line between these activities is often unclear, as the knowledge of actual construction involves a set of skills covering each aspect. However, individual licensing practices exist for most of these levels, often controlled by government or practitioners themselves. Each project reflects local laws, customs, and resources, merging them with the final consumer's demands and limits.

Overall, construction presents a complex organizational problem that draws on experience rather than predefined rules or methods. Translating consumer demands into workable end projects that account for local limits and resources is an intensely intellectual activity. A building's architecture must reflect often uncodified functional and form demands. Designers must also consider how the people who will use the building live, work, and play, even if they have no direct knowledge of the architecture.

Quantifying a building's success is difficult, subjective, and most likely individualized. Some projects are mass-produced, focusing on meeting average needs and demands, and thus requiring only average building skills and materials. Other projects are one-off developments that require innovative designs and materials and highly skilled labor. The more unusual a project, the more likely it will encounter cost and time overruns, although all construction projects generally face this risk.

---

Software as Hollywood

On an industry level, Hollywood's film studios closely resemble software.

Film production requires highly skilled teams. These teams normally form for individual projects, with members individually judged by overall reputation and experience within the industry. People receive training both formally, through film schools, and informally, through apprenticeships or self-learning.

Product quality is hard to evaluate, let alone quantify, prior to market release. The industry defines success critically by peer review and publicly through box office sales, with no guarantee that these evaluations will match. Critical success does not guarantee longevity.

The nonlinear and multistaged production process often leaves the ultimate product undetermined until the final stages. Production is highly susceptible to cost overruns and missed deadlines. Large budgets and film crews provide no guarantee of timely production or the final product's actual success.

The industry allows for a range of large-scale studio production and small independent projects, producing a variety of products from one-off masterpieces to long-running television shows.

Hollywood's limitation as an analogy with software lies in the noninteractivity of the final product, which is designed to entertain passively. However, the software gaming industry, with revenues already equaling if not exceeding Hollywood's, presents an interesting example of interactive -- yet very Hollywood-like -- entertainment.

---

Software as University

A university combines highly independent and creative professionals in an overall structure that can be quite bureaucratic. Many IT firms already formally follow a campus model that places a high value on innovation, communication, and creativity. Research is structured around peer review, with dominant ideas evolving and emerging over time. Teaching and research resist rationalization, remaining highly subjective and individually centered.

Issues of productivity and quality always contain a mix of qualitative and quantitative factors. Candidates gain admission to the profession only through a long apprenticeship, guided by senior faculty. The training process responds slowly to demand, creating a cyclical pattern of under- and oversupplying academics. Guaranteeing that candidates will exhibit a standard quality when they exit the training process remains difficult.

---

Please note: The above edited excerpts, plus many of the ideas expressed in this posting, were taken from the article Software Development: An Outsider's View, Kyle Eischen, p36--44, Computer 35(5), May 2002, IEEE. (see also Rationalizing Software)

---