IMO, that's the wrong way to think about software architecture. It doesn't matter "how OO" a codebase is. What matters is how easy it is to maintain. Object orientation is just one tool of several that you can use to get the job done. The danger of focusing so much on OO is that you wind up with a rigid, inflexible monster that makes it impossible to make changes without negative consequences (like code breakage, or increased complexity of implementation).

Yep. I saw a video of Jonathan blow talking about how he coded stuff in Braid. It was very interesting. He would just put a comment in a function instead of creating a new funtion, wrap that code in braces, and then code away, knowing that the code wasn't going to break any other code. From an 'OO' point of view this is just rubbish, but when you're one of a few people trying to fix a bug in a game so you can ship it, you'd rather rewrite the same code snippet 10 times and test each fix once than change a function used in thousands of spots and have to test thousands of things when you make a change.

void someFunc() {

   // fix a bug here
   {
      // here is some code, wrapped in braces,
      // so the scope can't possible cause problems
      // anywhere else.  I can change this code all 
      // I want and not break anything else
   }
}

This may be going to far, but I really had to stop and think about it. I'm still thinking about it...

Interesting idea! I'm going to focus on just coding out the program first and then see what can be made modular without causing too much grief in the long run

This is all you need: http://www.infoq.com/presentations/Simple-Made-Easy