Agile Software Development
Автор: Alistair Cockburn /
APPENDIX B: Naur, Ehn, Musashi Peter Naur, Programming as Theory Building
-
Часть 1
-
Peter Naur and Pelle Ehn wrote the two most compelling and accurate accounts of software development I have yet seen:
Peter Naur's "Programming as Theory Building" neatly describes the mental activity of creating software, and explains Extreme Programming's "metaphor" activity.
Pelle Ehn wrote the wonderful book Work-Oriented Design of Software Artifacts, in which he considers how Wittgenstein's idea of language games informs our development of software.
Naur's article is not nearly as well known as it needs to be, and Ehn's book is out of print. I am happy, therefore, to present extracts from their two works here, for wider readership.
Miyamoto Musashi, the 17th century samurai champion, never wrote software. The competing schools of swordfighting in his day sound painfully like today's schools of methodology, though. His admonishes people to avoid getting infatuated with tools and schools, to use different tools and strokes for different moments, and to just "cut off your opponent's arm. " His admonitions apply directly to software development -- if you realize the opponent is the problem, and not your office-mate.
Peter Naur is widely known as one of the authors of the "Backus-Baur Form" (BNF) notation, used to describe programming language syntax.
His 1985 article, "Programming as Theory Building" was reprinted in his collection of works, Computing: A Human Activity. This article is, to my mind, the most accurate rendition of what goes on in designing and programming. I regularly refer to it when discussing how much documentation to create, how to pass along tacit knowledge, and the value of the XP's metaphor-setting exercise. Understanding programming as theory building also illuminates the economic structure of methdologies.
In the following article, note the idea that the quality of the first programmer's work is related to the match between his theory of the problem and his theory of the solution. Note, even more, the idea that the quality of the later programmer's work is a function of the match between his theories and the first programmer's theories.
These ideas convert the task of passing along "the design" to the more useful appropriate task of passing along "the theories. " This latter task captures the need to pass along both tacit and external knowledge, and shows that the knowledged is clearly tacit in the owning. Look for the different ways in which Naur covers the idea of "tacit knowledge. "
Here is his text:.
"Programming as Theory Building"
The present discussion is a contribution to the understanding of what programming is. It suggests that programming should be regarded as an activity by which the programmers form or achieve a certain kind on insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.
Some of the background of the views presented here is to be found in certain observations of what actually happens to programs and the teams of programmers dealing with them, particularly in situations arising from unexpected and perhaps erroneous program executions or reactions, and on the occasion of modifications of programs. The difficulty of accommodating such observations in a production view of programming suggests that this view is misleading. The theory building view is presented as an alternative.
A more general background of the presentation is a conviction that it is important to have an appropriate understanding of what programming is. If our understanding is inappropriate we will misunderstand the difficulties that arise in the activity and our attempts to overcome them will give rise to conflicts and frustrations.
In the present discussion some of the crucial background experience will first be outlined. This is followed by an explanation of a theory of what programming is, denoted the Theory Building View. The subsequent sections enter into some of the consequences of the Theory Building View.
I shall use the word programming to denote the whole activity of design and implementation of programmed solutions. What I am concerned with is the activity of matching some significant part and aspect of an activity in the real world to the formal symbol manipulation that can be done by a program running on a computer. With such a notion it follows directly that the programming activity I am talking about must include the development in time corresponding to the changes taking place in the real world activity being matched by the program execution, in other words program modifications.
One way of stating the main point I want to make is that programming in this sense primarily must be the programmers' building up knowledge of a certain kind, knowledge taken to be basically the programmers' immediate possession, any documentation being an auxiliary, secondary product.
As a background of the further elaboration of this view given in the following sections, the remainder of the present section will describe some real experience of dealing with large programs that has seemed to me more and more significant as I have pondered over the problems. In either case the experience is my own or has been communicated to me by persons having first hand contact with the activity in question.
Case 1 concerns a compiler. It has been developed by a group A for a language L and worked very well on computer X. Now another group B has the task to write a compiler for a language L + M, a modest extension of L, for computer Y. Group B decides that the compiler for L developed by group A will be a good starting point for their design, and get a contract with group A that they will get support in the form of full documentation, including annotated program texts and much additional written design discussion, and also personal advice. The arrangement was effective and group B managed to develop the compiler they wanted. In the present context the significant issue is the importance of the personal advice from group A in the matters that concerned how to implement the extensions M to the language. During the design phase group B made suggestions for the manner in which the extensions should be accommodated and submitted them to group A for review. In several major cases it turned out that the solutions suggested by group B were found by group A to make no use of the facilities that were not only inherent in the structure of the existing compiler but were discussed at length in its documentation, and to be based instead on additions to that structure in the form of patches that effectively destroyed its power and simplicity. The members of group A were able to
spot these cases instantly and could propose simple an effective solutions, framed entirely within the existing structure. This is an example of how the full program text and additional documentation is insufficient in conveying to even the highly motivated group B the deeper insight into the design, that theory which is immediately present to the members of group A.
-
Навигация [ Часть 1. Глава 32. ]
Закладки
The group of 17 quickly agreed on those value choices.…
Walk around your place of work. Notice · The convection…
The industry is littered with projects whose sponsors…
Agility implies maneuverability, a characteristic that…
Accepting program modifications demanded by changing external…
Figure 4-1. Elements of a methodology. Roles. Who you employ,…
The surprising thing about human success modes is how nebulous…
For us as designers, it was possible to express both propositional…
The complete discussion about when and where to apply concurrent…
1. Project name, job of person interviewed (the interviewee…
Crystal Clear is the most tolerant, low-ceremony small-team…
The third problem is absence of feedback from the downstream…
Games are not just for children, although children also…
The main question is, if you were funding this project,…
Types of Methodologies Rechtin (1997) categorizes methodologies…
On a new project, I would use Crystal Orange as a base methodology…
While writing, reading, typing, or talking, we pick up traces…
It follows that on the Theory Building View, for the primary…