[Frost1x]

I tend to agree with you, however, there's sometimes so much complexity that you really do have to abstract it to manage sanity.

The issue I often see is that when abstractions are created, the thought process or design of those abstractions aren't well explained. When you create abstractions, more verbose documentation and design is needed to share the ideas. Anyone using this in the future needs to understand your abstractions and there's a cognitive cost of dealing with it.

You reduce this cost when you explain everything well, give examples, show use cases, etc. When you don't provide this sort of verbose documentation, you might as well have made it a large sequential program because it likely would have been easier for the next person to understand.

[stephc_int13]

Yes, this is often more difficult than it seems, this is typically something that requires experience and wisdom.

When unsure, it is still better to write less abstract code and somewhat messy code than falling into the over-engineering trap.

It will cost less to fix and it will also cost less to write in the first place.