I'm intrigued by the build-a-framework fetish, which - unlike the others you describe - isn't quite based on any useful principles.
What am I talking about? Let's say that as a .NET developer I need to store some data in some Azure tables. My tendency will be to create abstractions that aren't specific to Azure at all, and then in the implementation I'll use the classes Microsoft provides. The same is true for pretty much anything. Sometimes someone produces a really great library that simplifies the use of another, and if it seems really helpful then I'll use it.
The fetish I see is that developers immediately want to start building pointless, unnecessary "frameworks" to wrap existing classes, and then they want everyone else to use them for the sake of consistency. (This is much worse when it's a developer who can enforce it.) So now if I want to use an Azure table I have to use their weird, buggy wrapper class in a library named CompanyName.Frameworks.Storage.AzureTableStorage. Existing code is littered with dependencies on IMySpecialAzureTableStorageWrapperClass which a) isn't an abstraction because it can't represent anything other than Azure table storage, and b) hides or confuses the methods I need on the underlying classes. The solution? Add to the problem by modifying the wrapper. (I'm sorry, I meant "framework.")
It forces developers to learn someone else's bad proprietary code while denying the opportunity to learn the underlying API. In return it adds nothing except bugs and overhead.
It also gives some developers an opportunity to appear productive because they're constantly writing wrappers for stuff that doesn't need to be wrapped, and the fact that it's used everywhere creates the illusion that it serves a purpose.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm intrigued by the build-a-framework fetish, which - unlike the others you describe - isn't quite based on any useful principles.
What am I talking about? Let's say that as a .NET developer I need to store some data in some Azure tables. My tendency will be to create abstractions that aren't specific to Azure at all, and then in the implementation I'll use the classes Microsoft provides. The same is true for pretty much anything. Sometimes someone produces a really great library that simplifies the use of another, and if it seems really helpful then I'll use it.
The fetish I see is that developers immediately want to start building pointless, unnecessary "frameworks" to wrap existing classes, and then they want everyone else to use them for the sake of consistency. (This is much worse when it's a developer who can enforce it.) So now if I want to use an Azure table I have to use their weird, buggy wrapper class in a library named CompanyName.Frameworks.Storage.AzureTableStorage. Existing code is littered with dependencies on
IMySpecialAzureTableStorageWrapperClasswhich a) isn't an abstraction because it can't represent anything other than Azure table storage, and b) hides or confuses the methods I need on the underlying classes. The solution? Add to the problem by modifying the wrapper. (I'm sorry, I meant "framework.")It forces developers to learn someone else's bad proprietary code while denying the opportunity to learn the underlying API. In return it adds nothing except bugs and overhead.
It also gives some developers an opportunity to appear productive because they're constantly writing wrappers for stuff that doesn't need to be wrapped, and the fact that it's used everywhere creates the illusion that it serves a purpose.