[deely3]

> The paper also talks about what happens when all the people who have a theory of a given program stop working on it. It dies. Yikes. It’s claimed that we can’t rebuild a theory from code and documentation.

In the text above word "theory" are used instead of "understanding". Not sure why. Anyway, what exactly the hell Im doing in the last 10 years supporting legacy system mostly without documentation...

[Supermancho]

> when all the people who have a theory of a given program stop working on it. It dies.

This is only true of software of a particular level of complexity. For the most part, it simply isn't true. Humans made it (who also would routinely forget details about their own project) and humans can understanding it enough to build a working theory. If you can perform tests for something, you can deduce what it's doing, although the business case of why or specific experience with other approaches resulting in failures is often not recoverable by deduction.

[deely3]

As I understand you mean that author used word "theory" instead of "intention"?

Why, why they used word "theory" in the first place?

[layer8]

The word "theory" is used because an essential aspect of this particular kind of understanding is that it lets you reason about the domain and the code's behavior. It's an apt term in that context.

[kmoser]

While it's true that systems tend to be documented poorly, I think the article downplays the value of good documentation. Good docs describe everything that went into the system, from business requirements to implementation details, including things that were tried and abandoned (either because they didn't work or because business requirements changed), including code changes (e.g. "changed from DB table to in-memory array for speed; may need to change back if array grows too large").

This historical documentation, including historical codebase (think Git repo), is highly valuable. True, a new developer without the institutional knowledge is at a disadvantage, but that's the entire point of good code and good docs: so the next devs can pick up as efficiently as possible if/when they're called in.

[evanmoran]

I’m not the author, but my sense was that the word theory was being used because it was it couldn’t be explained fully. An “understanding” would instead but potentially full known and documented or made into an API, etc. This theory idea is to hint that there are even bigger ideas than can’t be written and you have to feel them and learn them from the original team to use them well yourself.

I’d love to hear from the original author how they think theory compares to a mental model. The biggest different is theories are known to be wrong, which fascinates me as an idea!

I have seen many pieces of code only make sense for a moment in time. The theory was right then, but wrong as the business evolved. Or sometimes visa-versa where the business was wrong, but the code worked beautifully for it.

[throwaway14356]

I think he perhaps means the difference between your 10 years of building an understanding vs writing the entire thing yourself?

[nuancebydefault]

You've been re-building the theory in your mind for the last 10 years. A better word for theory (I would propose) is mental model. In fact, as soon as your mental model of the system is complete enough, you might as well re-implement it. It will be easier to understand and maintain.

[valand]

The author uses the general meaning of the word and not the now-popular subset meaning: scientific theory.