What you've read somewhere is very true. When working on software you want to minimize all your feedback loops (this is the main principle behind agile/lean development). The sooner you find out that a correction is needed, the easier (effort, risk...) it will be to make that correction.
So if I had to choose between the two approaches you listed, I would go with (1), develop/test module at a time because the other approach has the largest feedback loop that you could possibly have. Writing entire program and only then testing it is asking for disaster.
However, I want to point out few more things to you:
It seems you are assuming that "a bug" is a coding error. And yes, coding errors are bugs, but when building software you also need to be aware of other bug types:
- design bugs - your code works as intended but your design doesn't work. Maybe it's too complex, maybe it fails to properly address the requirements.
- requirements bugs - your code works as intended and as designed but your understanding of what the user needs isn't correct. Sometimes that user is you. It can happen that you'll picture how you want your app to look and behave. Then you create a UI for it and discover that your original plan was completely inadequate because it fails to solve (or solve elegantly) whatever problem your program is meant to do.
Neither one of your approaches is good for finding these other types of bugs. And just like coding bugs are cheapest to fix as soon as you write them, requirements and design bugs are also cheapest to fix as soon as you decide on strategy and before you write too much code. After your program is mostly done, design bugs become way more expensive than coding bugs. And requirements bugs often mean you need to completely rewrite a chunk of your program.
In other words, picture that your program consists of a few modules. You write and test the first module and everything looks good. Then you write and test second and third module and things still look good. Then you go to put them together only to discover that module A's design isn't really adequate in order to integrate efficiently with module B. So now you are back, redesigning, coding and retesting module A, which you though was already done. Time will be wasted.
Better approach would be to come up with high level architecture (general module layout) for your program. Maybe you have a UI, some business logic, some communications modules and data storage. Write a bare minimum (essentially just a skeleton code) in ALL modules and then test the whole program. Even if all it does is start up and shutdown without any useful work. Make sure start up works. Then add one feature to the program. This feature will likely span many/all of your modules. Test to make sure the feature works. Continue doing this until your program is done.
This way you will not spend too much time in module A before understanding how the whole program comes together. You will also be able to see live UI and you will be able to interact with it, so if something needs to change you'll be able to make adjustments before too much other code is written.