A few words about debugging

Either your design is neat or messy, you will anyway put up with bugs.

Of course a neat design helps localizating bugs. But debugging will ever be the dark side of development, which will prove your smartness and fantasy, sometimes sorely.
There are many approaches and many books about debugging, ranging from breakpointing and logging to test oriented methodologies. I don't want here to go in depth but I wish you can do it yourself by reading about Agile and more specifically about eXtreme Programming.

Anyhow, I persuaded myself how important is preventing bugs, much before facing them.

Software development appears to be one of those things where less is more. Actually, the less code you write, the less probability you get to get into bugs. So be minimalist, achieve your functionalities with the least amount of code, avoiding redundancy and duplication. Don't Repeat Yourself and also Keep It Simple, Stupid.. All these recommendations, indeed, focus the Abstraction principle which is a minimalistic principle essential in designing software (and base of OOP).
Imagine that you have two parts in your engine where triangles are rendered. When you need to add a new rendering feature, you will have to modify both parts. Also if a bug about rendering incurs, you will have to check both parts again.

Have you ever heard about the Occam's razor principle? Well, if you still can't see how much a neat design has to do with minimalism, I think it can be worth to read some about it.

Regarding the finding bugs thing, I believe there is nothing better than a prototyping approach. Simply split in separate sessions your development. In each session changes are applied (say refactoring) to a bug-free version of your software in order to evolve it to a better yet bug-free version. This means that you need some kind of tool (say regression test) to verify that a certain version is still bug-free. When a new bug comes out, you will have certainly a better clue where it may resides.

The prototyping approach is OOP compliant and also brings more benefits such as:

• There is always a working release to show (though prototypal)
• You have a better vision of your design and can better address your efforts

As an example of bad prototyping, you can observe how many coders out there prefer to focus the last stunning effects of their 3D engines first instead of getting the game working as soon as possible and come back later to polish the details. They hardly have a clear vision of what is to be done, to be recycled, to be reinvented from scratch. In most of cases they don't even need to code a new 3D engine as there are already some others that can fit their requirements, perhaps open source (see devmaster.net).
A curious yet convincing lecture about this phenomenon is Write games not engines.

The prototyping approach also gives one more valuable benefit: you can get a prototypal version of your game working and sell it like it is the final version, even if not all intended requirements are accomplished (the above details to be polished). You make some money and can then keep on working for a new prototype, say a new chapter of the game.
It can be then worthwhile to split development in separate workflows, one for the making of a new game and others for the improvement of the engines in use. Which means that the game of today can be played with a better 3D engine, AI engine or Physics engine, developed in the future. This can be possible by means of a good software design.