I'd agree with you for this post, minus the weird re/usability semantics, but that interpretation goes against the previous parts of this series. If you read P

I'd agree with you for this post, minus the weird re/usability semantics, but that interpretation goes against the previous parts of this series. If you read Part 1, the argument is largely against even well-architectured versions of re-usability. The author takes issue with all components designed for drop-in future use, believing that each problem requires a tailor-made solution. The re/usability debate seems weirdly entangled with the coupling debate for no good reason. The author believes re-usability means tight coupling, and "usability" means good APIs with loose coupling (which can be re-used...).