This is a constant battle for any developer. It's not merely that the obvious solution is boring, but that oftentimes the programmer is juggling so many problems that an obvious solution to one doesn't seem sufficient because it doesn't address the others.

That is, yes, devoid of all context the simple solution solves the small problem, but it doesn't address the larger. It's funny that we get back to that after describing the art of programming as being able to break a large problem down into small, solvable ones, but there you are.

I frequently find myself having to rescope my tasks, say "I don't know the answer to that, but I don't -need- to yet" or "That could go either way; let me just create a common exposed interface and cut off this effort at that point" etc, rather than create a bloated mass of abstractions to handle all the possibilities. It's the problem agile was/is supposed to solve in terms of method, and what functional programming is supposed to solve in implementation.

Personally, I perceive the 'complexity as a status marker' less a technological or programmer culture problem and more as one of business and job culture.

You won't find someone building needless complexity into something if the fundamental goal pushes the limits of their abilities. Basically, starving men don't build Rube Goldberg Machines to crack their eggs.

In technology in general, the majority of jobs seem to be been-done implementation while the education and training continues to stress design and engineering.

Complexity is an outlet for every boilerplate operator who would rather be engineering and a differentiator to remind him/herself and signal to others a greater capability.

Some reasons from experience that developers over-do complexity: a) Someone at some point in the past told them to plan ahead b) They aren't sure about a feature (or perhaps about the future of a feature) and hedge against inaction c) Management does not manicure their task focus and/or priorities