I agree on the human friction part... I like this idea and yet I struggle to implement it in my own projects. I think the reason is that there's no good languag

I agree on the human friction part... I like this idea and yet I struggle to implement it in my own projects. I think the reason is that there's no good language yet to write that metadata. Even advanced type systems mainly focus on guiding how components connect, but they don't explain _why_ a program behaves a certain way or how the data is supposed to flow. Documentation is often unreliable as it becomes stale easily. As developers we spend and order of magnitude more time building a graph of data flow in our heads than actually writing code. Could we reify that graph? IMO that crucial metadata would answer the questions we would ask the Senior developer in our team when we need to work in the codebase: * When dealing with feature X, what are the involved software components Y and Z, how do we create instances of those? * What are the actual features the system implements? Is this the correct behavior? Is this what the system was intended to do? * If I point to a specific file and line in the project, what features does that code support? Why is that file there? Expressing the answers in a machine-readable format, in a language agnostic way, could look something like: System { Dependencies - Database depends on Logging - UI depends on Database - ... Feature A - Subtopic 1 - Subtopic 2 Feature B - ... } Feature A { requires database queries X if (database has data) produces Y, Z else doTheThing(X, "blah") } This is a broad idea, and the devil is in the details... This would not replace type systems or traditional languages. I'm thinking this spec-lang would have the minimum amount of flowchart-like constructs, and everything even slightly more complicated would rely on an interface. The system would implement all boilerplate and layout the project entirely. It would be amazing if we could also express state machines or even statecharts. Teams could use off-the shelf generators, or create a custom one, to produce the interfaces and boilerplate implementation. Since the system has a lot of information we could query it to answer questions like "give me all code of feature A", or even ask it to create symlinks so we can focus our attention in a single folder of files. Also different generators could create the structure that is more appropriate for different programming languages. It could be a good tool to assist rewrites, if needed for whatever reason. Tests/specs could be generated automatically, to a certain extent. I'm sure some people here will have PTSD about 4th gen languages and BPEL/UML nightmares :-). But even though BPEL is horrible I think the core of the idea is good and worth revisiting.