I feel privileged to live in an era where many pioneers of our field are still with us. I feel the passing of that era, and their loss, keenly.
I think that is oversimplification. I think that often program authors don't know what they are doing. Quite often somebody new who comes to the project has more insights about the project than original authors. Because:
1. the author can be biased (that's why we need code reviews)
2. the author can be less experienced has less programming skills, than a new person on the board.
3. the author simply lost his fresh eye for the program
If I understood correctly, TheoryBuilding is rather independent of method — TheoryBuilding is what a programmer would ultimately have to do to succeed, regardless of the exact steps they are asked to take. The exact method they follow is irrelevant in comparison.
I'm not sure mainstream still means the same thing he's talking about, but even in your example of "industrial production", I don't think it's that clear that that contradicts him. He seems to be just saying that whatever that means, it's not enough to fully describe software development. But perhaps competent engineers would end up doing so anyway — in fact, if they follow a similar set of ideas that they carry with them from project to project, they would then have a theory of other people's software that they didn't build themselves, just from being in the same environment.
On the other hand, he does directly say that under the TheoryBuildingView, when the theory of a program is lost, from people being replaced too much, it is really lost, and it is very expensive to reconstruct it. So it really depends on the details of how exactly that "component-based production" works out in practice.
[Note: maybe I misunderstood the paper or something, don't trust me.]
I think many IT firms nowadays have exactly this kind of approach: programmer has to deliver code according to specifications created by designers and stakeholders. Nobody cares what programmer knows and what theory programmer is building - the most important thing is to bring hot new features and to do it quickly.
Off course one can argue that "features", "stories" or "backlog" are needed from business point of view. Okay. But how to construct theory if there is no time for thinking?
He claims that theory cannot be expressed.
"(...)the knowledge held by someone who has the theory could not, in principle, be expressed in terms of rules"
Imagine that he is right and programming theory can't be expressed in words. Imagine if this was true.
Imagine there is no GoF book, no established design patterns (design patterns imo are just programming theories expressed in terms of rules...),
Imagine there is no Knuth books (if trees couldn't be expressed in terms of rules, then it would be pointless to write books about it).
Imagine there is no conferences about e.g. AngularJS or React architecture etc.
Because theory is in programmer head and "can't be expressed"
Maybe my thinking is flawed. Maybe Naur meant by "theory" something like "inner insight". If so I would agree with him. I see this quite often. People read books about design patterns and still don't understand underlying principles behind them. They just use them without deeper thinking (and they overengineer code often).
Although Naur wrote this article in context of one program but I think that programmer is building theory not only for current project but also for whole programming field. Programming skills are often independent of technology/project/language).
I'm pretty sure he means exactly that. A programmery "theory" about the subject is something that goes beyond blindly following documentation or rules. It is something that is taught (or self-taught) over time, rather than executed by following instructions.
The author even spent a whole section "Ryle's Notion of Theory" in the article to described precisely what he means by "theory". (More exactly, he describes Ryle's definition, which he is borrowing.)
It's an interpretation of Heidegger, but it's very clear and "analytical." He's even got interesting stuff in there about artificial intelligence, and he influenced several AI researchers. There was even a brief surge of interest in explicitly "Heideggerian AI" which seems to be an origin of the focus now on deep learning and emergent concepts and stuff (though I don't really know the history).
Anyway, Dreyfus says Heidegger means that most human knowledge can't be expressed in terms of rules.
That's most obviously true if you're talking about something like juggling three balls: you can write a guide, but the guide isn't possibly "exhaustive" enough to explain it so well that a person could simply follow the instructions.
And the more detailed instructions you write, the more the learner is just going to be confused. You will need meta-rules for deciding which rule to choose to apply.
To actually learn juggling, you just need a very primitive mental description, plus a little bit of coaching from someone who already knows, and a bunch of practice.
I'm just getting into Naur's writings a little bit now, and I notice one of his major interests was "programming as a human activity," so I think it makes sense to apply this same "Heideggerian" notion to programming.
Naur wants to describe the real knowledge, or let's call it skill, that actually functions in the programmer to understand and modify the program. Rules can only ever be a partial and abstracted "handbook" for aiding the learning of that skill.
It's not that rules are useless; it's more that the skill itself does not have the form of a collection of rules.
Skimming through Naur's "Antiphilosophical Dictionary,"  it's obvious that Naur was interested in this tradition of critical philosophy  that wants to dethrone the "cognitivist" view of thought. He cites Gilbert Ryle, another analytic postcognitivist philosopher who appreciated Heidegger:
> According to the legend, whenever an agent does anything intelligently, his act is preceded and steered by another internal act of considering a regulative proposition appropriate to his practical problem. But what makes him consider the one maxim which is appropriate rather than any of the thousands which are not? Why does the hero not find himself calling to mind a cooking-recipe, or a rule of Formal Logic? Perhaps he does, but then his intellectual process is silly and not sensible.
So I think this clarifies what Naur meant by a kind of "theory" not reducible to rules. And in the article itself, he explains that he uses the word "theory" with reference to Ryle.
Moreover, that one is now marked as "dupe", which I think is especially strange, since they were not only the first, but their version is more accessible than the PDF which I submitted.