Programming Is an Act of Design



Programming Is an Act of Design

Einar Landre

KRiSTEn nygAARd, FATHER oF oBjECT-oRiEnTEd pRogRAMMing and the Simula programming language, used to say programming is learning. Accepting the fact that programming—or more precisely, software develop- ment—is a processes of discovery and learning, not a process of engineer- ing and construction, is fundamental to bringing software practices forward. Applying the concepts of traditional engineering and construction on software development does not work. The problems have been documented and com- mented upon by leading software thinkers for more than 30 years. As an exam- ple, in 1987 Fredric Brooks, Jr., stated in the “Report of the Defense Science Board Task Force on Military Software” that the document-driven, specify- then-build approach lies at the heart of many software problems.

So where should the software industry look to improve its practices? What about the industries involved in production of sophisticated mass-market products such as cars, pharmaceutical drugs, or semiconductors?

Let’s take a look at the car industry. When planning a new model, the first thing is to choose a concept or archetype. It’s primarily an architectural positioning mechanism. The BMW X6 is an example of a new concept that combines the properties of an SUV and a coupe into what BMW calls a sports activity coupe. Before you can purchase a new X6, BMW has invested thousands of hours and millions of dollars in both its vehicle and manufacturing design. When BMW receives your order, one of its assembly lines will kick in and produce your customized version of the X6.



So what can we learn from this car-maker scenario? The important lesson is that the making of a new car involves two processes: the first process is the cre- ative design process, including establishing the required assembly lines. The second process is the manufacturing of cars in line with customer specifica- tions. In many ways these are the processes we find in the software industry as well. The challenge is what we put into the terms.

In the article “What is software design?”, Jack Reeves suggests that the only artifact of software engineering that satisfies the criteria for a design docu- ment, as such a document is understood and used in classical engineering, is the source code. The manufacturing of the software is automated and taken care of by the compiler, build, and test scripts.

By accepting that carving out source code is an act of design, not an act of con- struction, we are in a position to adopt useful management practices that are proven to work. Those are the practices used to manage creative and unpre- dictable work such as developing a new car, a new medical drug, or a new computer game. We talk about the practices of agile product management and lean production such as SCRUM. These practices focus on maximizing return on investment in terms of customer value.

For the software industry to capitalize on these practices, we must remember this: programming is an act of design, not an act of construction.