Certainly you can build a theory via reverse engineering. The question is whether the theory in your head matches the theory in the head of the person who wrote the code.
Naur's argument is first that there is a theory at all, and that the question of whether it can be transplanted to another person is really unanswerable. We can attempt to answer it, or build confidence towards an answer, by doing things like writing/reading design docs, having experience in the industry that shows us how other eng tend to think and design, talking to the person who wrote the code, testing our theory against the code, etc. But we can never be certain of what is in the mind of another person.
Anyone whose ever taught anything to a student, I think, has come to see this. It's hard enough to teach people how to do a thing in response to a known circumstance. The real trick is to teach them well enough to have them extend their knowledge on known circumstances to new and unforeseen ones.
And Naur, IIRC, also argues that churn is inherently bad, and that programmers are not replaceable cogs, because one of the valuable contributions they are making is holding, in their minds, the theory of how the code solves problems:
> More generally, much current discussion of programming seems to assume that programming is similar to industrial production, the programmer being regarded as a component of that production, a component that has to be controlled by rules of procedure and which can be replaced easily
Naur's argument is first that there is a theory at all, and that the question of whether it can be transplanted to another person is really unanswerable. We can attempt to answer it, or build confidence towards an answer, by doing things like writing/reading design docs, having experience in the industry that shows us how other eng tend to think and design, talking to the person who wrote the code, testing our theory against the code, etc. But we can never be certain of what is in the mind of another person.
Anyone whose ever taught anything to a student, I think, has come to see this. It's hard enough to teach people how to do a thing in response to a known circumstance. The real trick is to teach them well enough to have them extend their knowledge on known circumstances to new and unforeseen ones.
And Naur, IIRC, also argues that churn is inherently bad, and that programmers are not replaceable cogs, because one of the valuable contributions they are making is holding, in their minds, the theory of how the code solves problems:
> More generally, much current discussion of programming seems to assume that programming is similar to industrial production, the programmer being regarded as a component of that production, a component that has to be controlled by rules of procedure and which can be replaced easily