"Complexity vs production" is a false dichotomy. Abstraction, which is fundamental to programming, is a means of managing complexity. The complexity isn't elim

"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?