burning my object oriented church

When brainstorming I always tend to immediately develop a needlessly complex O.O.P. way of doing something. To date this has succeeded once. It seems that OOP simplifies everything when I'm designing but when I'm coding it just gets confusing - where does responsibility lie among my data? Is it an object's duty to update itself from a relational database? Or should a polling loop do that? Should objects be self-displaying? I can never get past these questions.

I always end up discarding the oop design in favor for a procedural solution. The lesson, it seems could be one of two things:

1.
Don't start with OOP. Come up with a procedural process, start writing some code, and wait for object ideas to rise up from the process itself. Starting with OOP molds the task - the program - to whatever objects you think you need. Going to opposite way will result in using objects that you do need and the bulk of code you write will be fleshing out the process of the program and not its data members

2.
I'm simply bad at thinking OOPishly. Starting with OOP principles and developing a process is a fine way to go and I just mess it up every time.

Though humility is a good thing, I'm leaning towards 1. It seems unreasonable to expect to come up with a good way to abstract data when you have no clue, yet, how that data is being used.

The goal of a program is to get information from point A to point B. The intelligent way to route it through a bunch of objects wouldn't become apparent, I think, until you make the connection between A and B to begin with: even if it's with less-extensible, (potentially) more verbose procedural code.

Perhaps the best way to think about it is: Start Stupid. Refactorization is easy (and fun); coming up with a genius, modular, efficient way of doing something right off the bat (as a relatively young programmer) is nigh on impossible.