Recent searches
Search options
Administered by:
It's time for another post about Post-Architecture! This time the thesis is Premature Abstraction Is the Root of All Evil: https://arendjr.nl/blog/2024/07/post-architecture-premature-abstraction-is-the-root-of-all-evil/
I've taken a bit more of a practical turn with guidance on how to keep (early) architecture as simple as possible. Please let me know what you think!
Replies to this post will appear as comments on the article.
@arendjr
I will stick in my perennial comment: most developers need to be taught to come up with abstractions (and use existing ones, like hashmap and set) rather than avoid creating too many. Overengineering happens and in this context lots of guidance helps but I want to scream "but you can use abstractions!!!" first
Very old discussion:
https://blog.startifact.com/posts/under-engineering-over-engineering-right-engineering/
@faassen thought about your post a bit more, and I think it’s fair to say my Post-Architecture series is my attempt to “formalize my system” towards right-engineering. I’ve focused a lot on the simplification aspect since I guess the people who are still under-engineering are less of my audience since they’re less involved with architecture, while I personally learned quite a bit from past tendencies to over-engineer. 1/2
@faassen I will also happily scale back up the complexity wherever it is needed. The most complex systems I built that remained easy to reason about are the ones that had a functional core. Maybe the thing I left most unsaid is how to recognize when it is the right time to scale the complexity back up. And to be truthful, I’m not even sure how to articulate that. Maybe some future episode :)
2/2
@arendjr
Yeah, determining what complexity works is very hard. I have extracted and created quite a few frameworks during development of a complex application. But whether devs are still happy with them after years is hard to know