Success is best explained by product x market. So you can have great novels that languish, and massive movies that are rubbish.
The idea of "what can be easily changed" is significant, and is the basis of Parnas' influential paper on information hiding: you hide the decisions that are likely to change, so when they are changed, their impact is isolated from the rest of the system. Decisions that are expected to change together are grouped together in modules: http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crite...
This is perhaps the most influential comp sci paper, and it's an interesting read; no maths IIRC, and pretty straightforward.
I think "raw materials vs. tools" is not as helpful as "what can be easily changed", because the materials/tools distinction can always be made arbitrary. eg: compiler vs. interpreter for the same language. One is a "tool", the other "raw material". A difference in performance (usually); but equal difficulty in changing them (you have to rewrite your code.)
A related question is: once you have modules, with fixed interfaces between them, what if you got it wrong (different decisions need to change) and you have to change the interfaces and modules? Because "what you think will change" is a prediction. It's a hunch, or if you like, guessing. Your hunches improve with experience, both in a specific domain, and in general; but you will always be guessing. Or you should be; because if you know the answer, you should have automated it, bought/reused a tool that automates it, or made a tool that automates it and started selling it/giving it away.
As I said: great questions. For learning, they really are more important than great answers.
I completely agree with you and dasil003 about there being a better dichotomy than material vs. tool. I was making an attempt to organize my thoughts in a structured way so I could better understand my own learning process. Too often I come across articles that say DO NOT USE X or YOU MUST USE Y. I can't use node.js, clojure, erlang, web sockets, and seaside while doing AOP, 10 must todos for startups, and learn what convertible notes mean. I come here everyday and I learn more about what I still don't know than I can keep up with. So I try to absorb what I can and write my understand of it all.
The module paper looks brilliant, partly why I love compsci - in 1970s they were writing about what I am slowly learning now. Thanks for the wonderful feedback.
I think this kind of thinking can easily be scaled also to more abstract parts of projects than the code and infrastructure itself. A core part of the design process of any app is to decide what it will and what it won't do, and these kinds of decisions also involve how easily the decision can be reversed. For example, if one needs to change Twitter to allow arbitrary message lengths, that would probably be completely trivial, if done ahead of time, but since it is part of the core of what Twitter is, the message length limit is probably assumed in a lot of places in the code.
I think the most difficult decisions to make in a project is what to make reversible and what to make easily changable. Abstraction often carries a cost, performance wise or otherwise.
The analogy is stretched too thin. The meaningful dichotomy outlined first is idea vs code. I think there are probably other meaningful dichotomies within the tech itself, but I don't think tools/materials is the right one.
Success is best explained by product x market. So you can have great novels that languish, and massive movies that are rubbish.
The idea of "what can be easily changed" is significant, and is the basis of Parnas' influential paper on information hiding: you hide the decisions that are likely to change, so when they are changed, their impact is isolated from the rest of the system. Decisions that are expected to change together are grouped together in modules: http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crite... This is perhaps the most influential comp sci paper, and it's an interesting read; no maths IIRC, and pretty straightforward.
I think "raw materials vs. tools" is not as helpful as "what can be easily changed", because the materials/tools distinction can always be made arbitrary. eg: compiler vs. interpreter for the same language. One is a "tool", the other "raw material". A difference in performance (usually); but equal difficulty in changing them (you have to rewrite your code.)
A related question is: once you have modules, with fixed interfaces between them, what if you got it wrong (different decisions need to change) and you have to change the interfaces and modules? Because "what you think will change" is a prediction. It's a hunch, or if you like, guessing. Your hunches improve with experience, both in a specific domain, and in general; but you will always be guessing. Or you should be; because if you know the answer, you should have automated it, bought/reused a tool that automates it, or made a tool that automates it and started selling it/giving it away.
As I said: great questions. For learning, they really are more important than great answers.