> That mental model can only be learned by having worked on the project while it grew or by working alongside somebody who did, who can help you absorb the theory.
Maybe it's because I've done so much reverse-engineering, but I reject that claim. It's quite possible to start with a binary ROM dump and build up the theory of the code. If you have source code that's even better. And the whole point of design documents is to explain the theory.
Curiously, the book quoted at the top of the article gets this correct: "Revival of a program is the rebuilding of its theory by a new programmer team." But the article says that the only way to rebuild the theory is by writing new code.
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
Development as theory-building is intended as a metaphor to understand the impact of the collaborative mental model that is created as part of any complex system, and the losses incurred when this mechanism is not appreciated.
Having worked on reverse engineering complicated proprietary network protocols (but not for a long time), this is true to an extent. The “mental model” developed may not match the original authors in the exact way intended, but a working model can be constructed none the less.
We were often able to make better models than the assumed original authors (at least the software that used said protocols was much more performant due to better packing algorithms), so I’m unconvinced that reverse engineering puts you in a worse state.
Fully agree that the cost of reverse engineering is large, requires exceptionally skilled people, and no company should ever willingly put itself in the position where it becomes necessary for their own software.
Yes exactly. It’s reverse engineering. That doesn’t mean it will be easy, but once the reverse engineering is done you are back to where you were.
Anecdote: Worked for a company that had a large software component (graphical design tool) that had been written in C with a very complicated object model/macro layer, file system format etc. Zero documentation, hadn’t been updated in a decade and not a single person remained who understood it or had done more than simple bug fixes. Couldn’t rewrite as customers had huge investments in assets built from the tool.
One principal dev and maybe 1-2 months? And we had the theory of mind back, explained to everyone else and a new team of 5-6 devs working productively. Component was brought into the 21st century, and this time some documentation was written.
The paper's conclusion is stronger: a new person on a still existing team is rebuilding the theory. Albeit much quicker and with much higher confidence, since they can talk to the existing devs and learn directly from them, but they're still having to build their own theory, separate from the original. (As we don't have SFTP between brains, yet.)
> A very important consequence of the Theory Building View is that program revival, that is reestablishing the theory of a program merely from the documentation, is strictly impossible
> […]
> Similar problems are likely to arise even when a program is kept continuously alive by an evolving team of programmers, as a result of the differences of competence and background experience of the individual programmers, particularly as the team is being kept operational by inevitable replacements of the individual members.
Reading documentation & talking to the original dev are inherently the same thing: we're using some medium (written docs, spoken word) to attempt to convey information.
Maybe it's because I've done so much reverse-engineering, but I reject that claim. It's quite possible to start with a binary ROM dump and build up the theory of the code. If you have source code that's even better. And the whole point of design documents is to explain the theory.
Curiously, the book quoted at the top of the article gets this correct: "Revival of a program is the rebuilding of its theory by a new programmer team." But the article says that the only way to rebuild the theory is by writing new code.