The name "theory building" doesn't really resonate with me - I think effective design ("programming" if you will) is more about things like decomposition, factoring and representations.

The larger the project the more ways there are that you could decompose it, but only some of these are going to have good outcomes in terms of things like a concise flexible implementation, easy to read/write, debug and extend etc.

You are mentally exploring the alternatives trying to find the ideal factorization that minimizes complexity, keeps interfaces between parts simple and friction-free, and results in an implementation where the code almost reads like a high level description of the requirements, with additional levels of detail only exposed as you descend each level of the implementation.

I can't off the top of my head think of a super pithy way of expressing it, but optimizing the factorization and representations being exchanged between parts (the two go hand in hand) is the key. How do you reduce the requirements into a design with the fewest moving parts and simplest interfaces between parts. It's kind of co-evolution in a way.