Becoming a Better Bug-Fixer

Are there any statistics available to how much longer it will take to develop applications when creating unit test during the development compared to just coding?

There is some very interesting research about this. Read the following whitepaper:

Realizing quality improvement through test driven development: results and experiences of four industrial teams

The whitepaper and others research from one of its authors, Nachi Nagappan, are discussed here: http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

The study and its results were published in a paper entitled Realizing quality improvement through test driven development: results and experiences of four industrial teams, by Nagappan and research colleagues E. Michael Maximilien of the IBM Almaden Research Center; Thirumalesh Bhat, principal software-development lead at Microsoft; and Laurie Williams of North Carolina State University. What the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer.

“Over a development cycle of 12 months, 35 percent is another four months, which is huge,” Nagappan says. “However, the tradeoff is that you reduce post-release maintenance costs significantly, since code quality is so much better. Again, these are decisions that managers have to make—where should they take the hit? But now, they actually have quantified data for making those decisions.”

Additionally, Jason Gorman has proposed such an experiment for the Software Craftsmanship conference this year. He's been trying an experiment creating the same application using a TDD and a non-TDD approach and he's recently blogged about his results:

Over 3 iterations, average time taken to complete the kata without TDD was 28m 40s. Average time with TDD was 25m 27s. Without TDD, on average I made 5.7 passes (delivering into acceptance testing). With TDD, on average I made 1.3 passes (in two attempts, they passed first time, in one it took 2 passes.)

Now, this was a baby experiment, of course. And not exactly laboratory conditions. But I note a couple of interesting things, all the same.

It will be interesting to see the full results of this experiment when more people perform it.

Are there any statistics available that shows how many hours maintenance decreases when having (good) unit tests?

From the whitepaper above:

The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice.

In my head this raises alarmbells.

Granted, I am not a database programmer. My work is not nearly as security critical for example. But when you say

But sometimes what I do is fed up of doing some research (cant find suitable information on the internet) I just change the logic which takes me much less time as compared to the other.

I get the feeling that you know yourself that the approach you're taking is most likely not the one you should be taking.

To me it seems you're treating symptoms rather than the underlying problem. And I can't say I have never done so. But experience tells me that, although it might never happen, this will usually come back to bite you in places you don't want to be bitten.

I would say that your last sentence is correct. Take the time to find and fix the original bug. You can't be sure you've fixed the issue if you haven't figured out what the issue was in the first place.

Any workaround might cosmetically solve your problem, but could as well introduce side-effects you hadn't thought of, besides possibly still leaving your system exposed to the original problem.