A way to discover bugs early could reduce the amount of bug-fixing at a later state.
Normaly everything is taken in mind that try – catch operations should be used. This will of course catch all the exceptions that occur, but often they are only logged, and then fogotten.

We then only have catch the event but forgot to do anything about it. How often are you really reading the logfiles that are over hundreds of lines of debugin information. Instead we have created a ultimated log-file but we had not taken care of the actual problem, just logged it. Instead of logging it should be taken cared of at once.

Logging have been used way to much lately, and you should keep in mind that only log the neccessary stuff to be able to find critical errors when searching. And remove all the debugging messages.

log4J, log4C, JavaLogger or any other library is good to use to remove the “sout” which also takes cpu-time.

Instead take care of the catch and make somthing out of it:

• Fail fast and crash loud, this will reveal the problems early and removes the major bugs at the begining of the production. Instead of finding them at the customer.
• Crash, don’t trash.

Another thing is that software testing is uselss if it isn’t complete. Code coverage of statements and branches cannot find all software bugs. But Path coverage is a comprehensive technique that can detect bugs early in the software development life cycle.

Even so, release early will force the customer to react to the product and will problably point out errors and missunderstanding that often occur. When releasing often you will Have to listen to your customers and will also give you a better communication-channel with them. This is also somewhat related to the Scrum philosofy that release often when functionality is ready to test.