No, I am not looking to solve a specific problem. The way I start a project is to draw a very simple(throwable) sketch of what the software design will look like, and then iterate over it as I write the code. Lately I have started slowing down because midway through writing code I start rethinking the design and start over again from scratch. So I was just curious what approach others use and is there a way to avoid the situation that I am in.
What's the source of requirements you're building to and who verifies those?
If you're creating requirements out of thin air, just so you can build something (eg: you want to learn something) - your current approach is absolutely ok.
Try to write pseudocode for the critical parts so you can test your design before you write code.
Sometimes class diagram, sequence diagram, pseudocode, scribbling on piece of paper etc; whatever gets me going quickly.
I find OOP to be weak in the design stage. It does help later to simplify the code. But, only after you find out where the actual objects are. I prefer ERD for any modeling I might need in the design.
Older methods like structured design and data-structured design offer better guidence in the design stage. Too bad people look down on anything that is not OOP (or the newer hype FP).
The most useful method by far, however, is to recognize the shape of the problem, look for and apply a known solution.