Well it's a noble goal and I certainly don't want to discourage you, however you go about it! Perhaps you will learn something new and useful. But just to make

Well it's a noble goal and I certainly don't want to discourage you, however you go about it! Perhaps you will learn something new and useful. But just to make my meaning clear, by “existing programs in existing languages”, I meant doing it in a way that does not require effecting change at all. What understanding is it is possible to deliver for an existing, complicated, messy codebase? For example, you correctly noted that early versions tend to be easier to understand, and code tends to accumulate complexity that makes the global structure less clear. This is true and something I use often: use "blame" to look at where a particular chunk of code was introduced, and look at the corresponding change, along with its description/commit message, which is often simpler. (And I see you've written a tool (http://akkartik.name/post/wart-layers http://akkartik.name/post/wart-layers) for those who choose to stay conscious of this and write code in a particular way.) But most software today is available with version history. So, what if this were easier? E.g. imagine if when you view code there's a slider that you can move back and forth to see older or newer versions, while the changes fade out. Or, imagine highlighting the “base” of the code versus the less important changes. Or something; experimentation will reveal what tends to be useful for existing codebases. (And if people find the tools useful, that may even effect change in how code is written, as authors get feedback on what the tool thinks versus their mental understanding, and tweak until there's a match. I've seen Typescript being sold not for some putative benefits of typing on code correctness but simply for enabling IDE autocomplete for instance.) The broader point is that, to me it seems that your writing and efforts have the implied assumption that understanding of global structure is hard to acquire because everyone is making mistakes, and if everyone is just careful to do things differently, the difficulties will disappear and understandable programs will magically emerge. That is something worth investigating, but I think there's a good chance that perhaps not everyone is making mistakes (as even programs written by the best programmers tends to become hard to understand eventually), and/or that it's not feasible for everyone to be super careful when trying to get things done. (Rather, they're making tradeoffs, and are likely to make similar tradeoffs in future.) Not all the accumulated complexity may be accidental; some is inherent in the fact that the problem in the real world does have messy corner cases (as Spolsky said: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...). Similarly most of the causes you identified (backwards compatibility considerations, churn in personnel, vestigial features) (and those identified elsewhere, e.g. in “out of the tar pit”) can be real and unavoidable: there may be features that are needed only for (say) users of old systems but still cannot simply be removed. The best that can be hoped for is to make this fact clearer, not to make them go away. Finally, there's also the fact that “understanding” is not a property inherent in the system (code, program, whatever) itself, but something that grows in the head of the reader. (Perhaps trying to influence the writer is not the best way...) And different readers come with different questions and goals, and at least as far as the first paragraph of your http://akkartik.name/about http://akkartik.name/about goes, may need different sorts of help in different contexts. It's unlikely a fixed organization of the program is going to satisfy everybody. An example: error handling. We've all seen functions that spend only a few lines doing their “main” job and many more lines checking for errors and dealing with them. This can obscure what the main job of the function is, and make it appear as though error-handling is the main part. (Aside: Knuth observes this causes a psychological barrier against writing too much error handling, while with his literate programming one shunts off the error-handling to a different section/module, and one tends to write better error-handling there.) But consider https://danluu.com/postmortem-lessons/ https://danluu.com/postmortem-lessons/ which says “If you care about building robust systems, the error checking code is the main code!” So depending what kind of understanding a reader is looking for at a certain time, sometimes they may want to understand the “happy” path and sometimes the error handling. Similarly in general: given a program, sometimes we want to understand roughly how it's organized / what its major components are, sometimes we want to understand the precise boundaries/interfaces between these components, sometimes we want to understand the sequence of operations the program performs and sometimes the frequency, sometimes we want to understand what it does in the “steady state” and sometimes what it does at startup or shutdown or some corner case. And in fact not always the global structure of a program but sometimes only enough to understand how it solves a specific problem — if I want to make a change to (say) Firefox in an afternoon, I may just want to know how it does (say) font fallback. All that said, yours is an interesting project, and for the reasons you mentioned, and I look forward to what comes out of it. Apologies for a verbose comment; I'll stop here :-)