Frameworkism: Senior Software Developers' Pit of Doom

Aaron on the Web's resource offers insights, tutorials, and resources for software developers and technology enthusiasts. Readers can learn about coding best practices, software architecture patterns, and emerging technologies. With articles, tutorials, and code samples, Aaron on the Web provides  guidance and expertise for building software applications and advancing technical skills.

Aaronontheweb

The post discusses the issue of 'frameworkism', where developers build rigid, preemptive frameworks that lead to significant technical debt. It details the problems encountered in the Sdkbin project, where copying and pasting code from previous projects without adaptation resulted in a cumbersome system that's hard to maintain. The author stresses the importance of understanding and modeling business needs accurately in the code rather than prematurely optimizing or enforcing standardized frameworks.

Bespoke Frameworks: a Telltale Sign of “Expert Beginners”

Preemptive Framework Creation is Premature Optimization

Bespoke Frameworks: Rapid Technical Debt Accumulation Factories

I agree with everything in the article except the idea that this is an “expert beginner” problem. “Beginner beginners” also suffer from this issue but in a different way: they were taught by an expert that this is how big projects look and what big projects do and then they attempt to mimic that methodology for whatever they’re working on. Now, not only do they not have the experience to pull this off from a technical standpoint but they’re making the same mistakes mentioned in the article.
I speak from experience because when I started learning .net core after spending years working in .net framework, I completed a course on web apis and it taught the exact same thing pointed out in the article: EF -&gt; map -&gt; dto -&gt; map -&gt; model. And the best part is the lecturer never explained when you should transition to this pattern. So when I tried my hand at creating an api project myself, I immediately resorted to this same pattern, only to realize that I’ve been writing mappers and dtos for things I only use once. And because the structure wasn’t fully formed in my head from the start (it never is) I was spending so much time refactoring code that didn’t need to exist in the first place.
Now if I were a proper beginner, I would probably have never caught the inefficiency. That’s not a fault to lay at the beginner’s feet, obviously, but at the lecturers of such courses that never attempt to define the boundaries of where and when a deeper framework should be implemented.