mstdn.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A general-purpose Mastodon server with a 500 character limit. All languages are welcome.

Administered by:

Server stats:

16K
active users

Arend van Beelen

It's time for another post about Post-Architecture! This time the thesis is Premature Abstraction Is the Root of All Evil: arendjr.nl/blog/2024/07/post-a

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.nlPost-Architecture: Premature Abstraction Is the Root of All EvilPractical tips that allow you to build an evolving architecture

@arendjr
Here's one trick that I use to find potentially useful classes/structs in an emergent way.

* Write functions.

* Organize the parameters to these functions so they take things in the same order. A Foo first, then a Bar. Make them consistent

* If you see a bunch of functions that take the same arguments, factor them out into a class/struct and the functions become methods

Refactoring over and over is so useful to construct design and architecture incrementally.

@arendjr
Refactoring is key, don't stick to what is there but find ways to organize better incrementally. Lean on tests and types help you remain in a working state

@arendjr
One symptom of premature architecture is premature modules. I see developers start a project by creating many empty modules in some tree. Everything they add has a place. This often gets frozen early and doesn't get refactored. The classification method to determine what goes where is rigid and simplistic

I much prefer starting with one module and splitting later when the shape becomes more clear. I end up with a tree too in a larger project, but a tree that fits the project better

@arendjr
The other big aspect of this is frameworks. Frameworks lock you into some architecture and code organization. If the framework fits the problem well that is great. It offers a lot of guidance and takes away decision making so you can focus on other stuff. If it doesn't fit, or as your project grows, doesn't fit anymore, it's more difficult.

@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:

blog.startifact.com/posts/unde

Secret Weblogunder-engineering, over-engineering, right-engineeringMartijn Faassen's secret weblog

@faassen Haha, yeah, using abstractions is indeed a skill that needs to be learned. I think we’re already pretty much in alignment, as nowhere did I mention you cannot use abstractions. Using abstractions is almost inevitable, and I think nobody would bat an eye if you use an abstraction you need. I think the main danger I’m trying to warn against is developers who identify more with the architect role and start to put abstractions where they’re not needed.

@arendjr @faassen Thanks for article, all the links, and discussion both. Really good.

@arendjr
Oh for sure. I just worry somewhere along a game of telephone people will say "don't use abstractions"

Just like I have heard "just write the dumbest code and then profile if it's too slow". That's true if you have absolutely no idea, but if you know your database will have 10 million rows maybe a for loop to implement a query is something you can avoid right away

@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