

Do your tools support production or complexity? - jmount
http://www.win-vector.com/blog/2011/04/do-your-tools-support-production-or-complexity/

======
idle_processor
"Complexity vs production" is a false dichotomy.

Abstraction, which is fundamental to programming, is a means of managing
complexity. The complexity isn't eliminated; irrelevant parts of the problem
are just swept under the rug.

Mount's gripe about automated build systems is essentially that if and when
the system does something wrong or inefficient, the users have no way to cope
with it. System correction is a vendor burden, not a user burden. One needn't
be a compiler/builder/etc. expert to compile a program; non-engineers drive
cars all the time.

Suppose the vendor did its job and optimized the build process.

The example of how if one isn't around, one can't automate that GUI-driven
build process is weak. A network/clock-listening macro fixes it. Writing that
program/macro is probably "building a shelf," but it's the path of least
resistance. Dropping the GUI to learn the make stack is also "shelf building,"
because it's extrinsic to your problem (shipping). The resultant shelf is more
generally useful, but you've made a time trade-off.

In cases where one's stuck with that type of IDE, it's a good trade. (I'm
aware this may be somewhat begging the question, as the thrust of the article
is to avoid adopting that development environment to begin with.)

"Do not reward building shelves unless building shelves is your actual
business." There're cases where one can't avoid shaving a couple yaks. Not
everything can be done in one step. Incremental reward systems aren't weren't
shown hazardous by the article. Some of those shelves may help you not only on
the current project, but may be useful in the next. (E.g., having learned the
make stack or building that GUI automator.) Why should that work be
unrewarded?

