[alkonaut]

Don't design your software for future features you might need. Design it to be easy to change. This means it has to be decoupled and simple. The trick is to make the software decoupled without making it complex. Adding layers and interfaces and abstractions is the easy way to achieve loose coupling, but it also adds complexity. Making software that's simple while still being easy to change is much harder than making some layer lasagna.

[tartoran]

> The trick is to make the software decoupled without making it complex

Any insights into how to do exactly this? Any rules of thumb or guidelines? Also what is not considered complex to some adds a cognitive burden to others.

[alkonaut]

No, I can’t think of any simple guidelines. It’s a tingling sense you get after 10-20 years of doing it that says “I should probably make this simpler and direct” or “I should probably make this more general/layered”.

I think the sense is mostly developed not by successful designs but by mistakes and the subsequent refactorings.

The only “simple” advice I have is that in FP the simple and decoupled seems to happen without added work, while in OO it’s quite a cognitive overhead to avoid tangling things up. So my only insight is perhaps “make everything simple functions and shy away from state whenever possible”.

[tartoran]

Yes for FP. It seems that when I join OOP complex projects/systems it is much harder to grok the codebase if the original creator isn't around to tell me how it works and explain the intricacies. FP on the other hand makes that part a whole lot more easier to digest.