Now I am not saying design isn't a good thing. It's important to have a solid design behind your games especially when the games become larger. The problem is that until you have completed a few games, how do you know what the best design is? There are many aspects to game programming and it can be hard to see how everything fits together at first. After you have completed a couple of games, you will start seeing the underlying connections which will make the design questions a lot easier to answer.
I think it is a mistake to start off trying to create a game engine. If you have never completed a game, don't try creating an engine. Just create a game, but focus on reusability where you can. Create a reusable Image class or Sprite class that you can use in another game. This is one of the major points of using Object Oriented design, reusability. By your second game you will probably have a bunch of components that you can group together to form a framework for further games. Let the "engine" evolve from your games, not your games from your engine. Sure, not everyting is going to be perfect, but you shouldn't always expect it to. Code can always be rewritten or redesigned later if it needs to be, and through this process you will have a couple of games already completed and the beginnings of a solid foundation to build future games off of.
I am changing my outlook on game development to better use the "Ready, Fire, Aim" approach. It's already helping me out with my own coding as I am actually working on a game and not just a bunch of code. This is only a slight shift in thinking but one that I feel is very useful.
Cross-Posted from Somewhat Structured Thoughts