|
Ryle’s use of the term “theory,” which Naur adopts here, is a bit counter-intuitive; it’s really referring to a kind of operational knowledge. One of Ryle’s central points is that there’s a categorical difference between being able to perform a skill yourself and knowing facts about how that skill is performed. Books, language, and observing other practitioners can only provide the latter kind of knowledge, but the former is what’s actually valuable. Learning how to do something can only be achieved through practice. This practice can be guided and improved by rote learning, but cannot be replaced by it. Also, no two practitioners approach a skill in exactly the same way: As only rote knowledge can be transferred between people, each person builds their own structure of operational knowledge based on their particular experiences. Naur’s argument here, then, is that this operational knowledge is dominated not by knowledge of building software in general, but instead by the understanding of how a particular piece of software functions internally and interacts with external factors. These external factors are both concrete, like protocol specifications, and abstract, like the competitive landscape the company is operating in. Further, Naur argues that the primary value in developing a piece of software isn’t the software itself, but the expertise that the programming team had to develop in order to produce it. In this view, dismissing the programmers and keeping the software is a grave mistake that will surface when one of the external factors changes and there is noone qualified to update the software. |