Programming, an act of design
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 development is a processes of discovery and learning and not a process of engineering and construction are fundamental to bring software practices forward. Applying the concepts of traditional engineering and construction on software development does not work. The problems have been documented and commented upon by leading software thinkers for more than 30 years. As an example, 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 so many software problems.
So where should the software industry go an look for improving their practices? What about the industries involved in production of sophisticated mass market products such as cars, pharmaceutical drugs or semiconductors?
Lets take a look at the car industry. When planning a new model, the first thing is to choose a concept. Examples of concepts are Coupe, Sedan and SUV. The role of concepts is to create new or address existing needs in the market. The concept work as a bearer of requirements and solutions. BMW X6 is an example of a new concept that combines the properties of a SUV and a Coupe and its called Sports Activity Coupe (SAC). Before you can place an order for your new X6, BMW has invested thousands of hours and millions of dollars in its design, transmission systems, power plant and the assembly lines required to build your copy. When BMW receives your order, one of their assembly line's will kick in and produce your version of the X6, though within the variability offered by the X6 architecture.
So from 30.000 feet we can claim that the making of a new car involves two processes: 1) The creative design process, including establishing the required assembly lines. 2) Manufacturing of cars in line with customer specification. These are the processes we find in the software industry as well.
Back in 1992 an article called What is software design? was published in the C++ Journal. Here Jack Reeves suggested that the only artifact of software engineering that satisfied the criteria for a design document, as such 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 construction we are in a position to adopt useful management practices that will work. Those are the practices we find used to manage creative work as architechting a new building, developing a new car, a new medical drug or a new computer game. The practices of agile product management such as Scrum. These practices focuses on maximizing return-on-investment in terms of customer value.
For our industry to capitalize on these practices just remember: Programming is an act of design, not an act of construction and take actions thereafter.
By Einar Landre
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Software Architect Should Know home page