A large part of it is because for most programmers, it is the only way to demonstrate growth in their own skills.
Relatively few developers get to lead projects, design truly interesting systems and so on. Most developers, especially in bespoke business software, end up writing large amounts of fairly un-challenging code day in day out.
But then if you just churn out the same sort of business logic for years on end, with little access to problems that are inherently challenging, how do you feel any advancement in your craft? For many developers it is through over-engineering or pointless re-engineering.
Common signs: tasks that are actually trivial suddenly start using home-grown frameworks. Obsession with vague rarely defined terms like "best practices", "clean code", "modularity" etc. An insistence that practices which were once considered an advance were actually a regression, like the recent trend to claiming that exceptions are bad because they make control flow "hard to understand", which justifies rewriting everything to use return codes, or XML is bad because everyone claims it is, but JSON with schemas is totally not the same and definitely how architectures are done Right™.
To get a perfectly simple design and implementation that is nonetheless powerful you really need a perfect match between the time/capabilities of the engineer and the inherent difficulty of the problem. That way the developer's mental energies will all be spent designing something that will work, and relatively little is left over for inventing new config file formats.
The funny thing is I actually faced this problem a lot last year. Since I read paul grahams essay on hackers I decided to focus that will for hard problems into my side projects(although this has taken my focus from popular frameworks to specialized libraries)
Relatively few developers get to lead projects, design truly interesting systems and so on. Most developers, especially in bespoke business software, end up writing large amounts of fairly un-challenging code day in day out.
But then if you just churn out the same sort of business logic for years on end, with little access to problems that are inherently challenging, how do you feel any advancement in your craft? For many developers it is through over-engineering or pointless re-engineering.
Common signs: tasks that are actually trivial suddenly start using home-grown frameworks. Obsession with vague rarely defined terms like "best practices", "clean code", "modularity" etc. An insistence that practices which were once considered an advance were actually a regression, like the recent trend to claiming that exceptions are bad because they make control flow "hard to understand", which justifies rewriting everything to use return codes, or XML is bad because everyone claims it is, but JSON with schemas is totally not the same and definitely how architectures are done Right™.
To get a perfectly simple design and implementation that is nonetheless powerful you really need a perfect match between the time/capabilities of the engineer and the inherent difficulty of the problem. That way the developer's mental energies will all be spent designing something that will work, and relatively little is left over for inventing new config file formats.