Wow, that is incredibly sad to hear. I'm 40+ years in, and still love all of that.

Where's Chesterton's Fence?

https://en.wiktionary.org/wiki/Chesterton%27s_fence

[EDIT: Ninja'd a couple of times. +1 for Shirky's principle]

Sure, don't add hooks for things you don't immediately need. But if you are reasonably sure a feature is going to be required at some point, it doesn't hurt to organize and structure your code in a way that makes those hooks easy to add later on.

Worst case scenario, you are wrong and have to refactor significantly to accommodate some other feature you didn't envision. But odds are you have to do that anyway if you abide by YAGNI as dogma.

The amount of times I've heard YAGNI as reasoning to not modularize code is insane. There needs to be a law that well-intentioned developers will constantly misuse and misunderstand the ideas behind these heuristics in surprising ways.

A couple are well-described/covered in books, e.g., Tesler's Law (Conservation of Complexity) is at the core of _A Philosophy of Software Design_ by John Ousterhout

https://www.goodreads.com/en/book/show/39996759-a-philosophy...

(and of course Brook's Law is from _The Mythical Man Month_)

Curious if folks have recommendations for books which are not as well-known which cover these, other than the _Laws of Software Engineering_ book which the site is an advertisement for.....

Separately, I'd add Rust's API design principles, though it's more of a adjunct with things in common. https://gist.github.com/mjball/9cd028ac793ae8b351df1379f1e72...

I wish AWS/Azure had this functionality.