When faced with a new programming challenge, it can usually be approached from one of two ways: the front end or the back end. Each has its merits, and completely focusing on one or the other is a recipe for disaster. But, I think that most programmers tend to be a little "backend heavy". I'd almost go so far as to say that it's difficult to call yourself a programmer without being biased this way. After all, programmers enjoy solving complex problems by creating new powerful abstractions. If not, you'd be a little nuts to go through all the frustrations of programming without enjoying watching something work.
What I find surprising is that if a problem is too simple, it's the programmers themselves are the ones that create more complexity. I find myself doing this all the time. "Well what if the user wanted to do foo and not bar. Instead of hard coding this action, I can add a new <insert cool pattern/framework/abstraction here> and the application will then support any action. Then we can make a user preference and new configuration management system that users can tailor to their needs". This cascades of course, and before you know it, you've created a new framework. It's just so easy to get lost in it, that programmers sometimes forget to ask the obvious question: "hold on a sec, why are we doing this again? Let's just cross that bridge when we get to it".
Focusing completely on the front end can be just as problematic though. Security holes, performance bottlenecks, and general lack of flexibility can hold you back too, perhaps even more so. Any one of these issues can be devastating. Then it'll leave you wishing you had spent just a whee bit more on prevention, instead of having to pay so much for the cure.
Right about now it sounds like my point is that everybody should just do things right from the beginning, without wasting time building anything unnecessary. But realistically, I think the most important thing is to "use your brain". The applications that programmers build are supposed to be helping users in some way. Refactoring is supposed to help programmers maintain their code. Writing tests is supposed to help maintain confidence in the code base. User testing is supposed to help inform usability improvements to the application itself. If something isn't working like it should, maybe it needs to change, or be rethought. It's always healthy to take a step back and review how things are going. I think Einstein said it best:
Everything should be made as simple as possible, but not one bit simpler.