Opinion-driven design
I once worked at a company that wrote and maintained an in-house framework. Over the course of ten years, they probably made around 250 websites and applications with it. Despite many shortcomings, the company kept using their framework for a simple reason: they were in control.
Thanks to that control, they were able to tailor their framework to their own needs without any overhead. And, while I would argue that using popular, community-backed frameworks is almost always the better choice over writing your own , I can appreciate some of their reasoning.
Except, in the end, they utterly failed in creating what they originally set out to do. Instead of a tool shaped specifically for their needs, the framework's core developers often wanted flexibility: they dreamt of open sourcing their framework and it growing popular, so it needed to handle as many cases as possible to reach as wide an audience as possible. And thus, flexibility and configuration were often prioritized, even though they rarely added much — if any — value to company projects. The core developers were always able to convince the not-so-technical managers; while in reality, the design and flexibility of this framework was often just a burden for me and my colleagues to deal with.
This mindset of "high configurability and flexibility" is, unfortunately, common in software design. I'm not sure why, but somehow programmers — myself included — often think they need to account for every possible outcome, even when those outcomes aren't relevant to their use cases. Many of us deal with some kind of fear of losing our audience if the code we're writing isn't able to handle the most specific of specific edge cases. A very counter-productive thought.
