

How to distinguish between tools and raw materials, and more importantly, why - chime
http://chir.ag/201009291830

======
8ren
Great questions.

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...](http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf)
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.

~~~
chime
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.

------
jorleif
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.

------
dasil003
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.

