I'm in my first real job as programmer and what I see is just the "Big Ball of Mud" code (without useful comments too), but I like to do clean code, and it's really hard for me to code in a worse way.
I'm searching for some study case where the usage of clean code (I see various definitions here of what is clean code) improved the development and maintainability.
What you need to understand is that no company sets out to write mediocre code. The problem is that 50% of the code, give or take, is written by the below average programmers of your company. You're preaching to the choir when you expound the benefits of clean code. The trick is how to do it. Do some research on things like peer review tools, static analysis, automated testing, continuous integration, TDD, scrum, extreme programming, etc. and present potential solutions instead of just explaining why the problem is bad.
I know this will go against the grain here but time to market, getting the requirements right, having the right funding, good marketing, the right price point and plain good luck have far more influence on a software products success than code quality.
This is NOT to say code quality should be ignored, but, you should acknowledge it is just one of many factors.
There are many examples of simply horrible code in hugely successful products (e.g. the original Apple OS which left its thread management to the applications).
I cannot think of any examples of beautiful code overcoming a badly conceived or overpriced product.
So if its time to market vs. pretty code, time to market should take priority!
A quick (but by no means exhaustive) search of Google Scholar turns up a lot of articles which refer to Bob Martin's Clean Code, but I haven't personally seen any papers that cover a correlation between "clean code" and improved development.
However, think about your question for a moment. You are asking about improved development, and that in itself is a very broad subject area covered not simply by writing better code, but also by many other factors such as communication, managing expectations, methodology and streamlining processes, testing, continuous integration, and really the whole box and dice when you consider just how many things go into making a software development project successful, let alone improving on it.
So you question should probably be: does writing clean code contribute to improved software development? To answer that, the only "evidence" I could provide with would be entirely anecdotal, and for that I think the Clean Code book would be an excellent reference, as it is written not only by Bob Martin himself, but also with many chapters contributed by some of the smartest software developers out there. If that doesn't help, then perhaps a little cold hard logic might apply.
If you make a mess in your home, and you never get around to cleaning it, then living in your home will become a chore. It becomes harder to find things, harder to move around, and nobody in their right mind will want to visit you if you live in a filthy environment. The same too with code. If your code is a mess, you find it harder to located problems, let alone fix them. It becomes easier to justify a work-around that might not do the job, but hey, it sure beats having to wade through all that old legacy muck, right? In the end, just like never tidying your home, allowing your code to become untidy will cost you time, and effort, and created difficulties for you in the long run. Keeping your code clean however will provide you with a nicer platform to work in, make refactoring and debugging less of a chore, and will require you to worry less often about whether you'll be able to maintain your code easily over time.
No, I don't have direct evidence to give you, and these are merely the thoughts of someone who has been doing this stuff for a very long time, and who hopefully has earned a little software development wisdom along the way. :-)
You have to separate clean code from the real goals: reducing cost of fixing defects after deployment and reducing unnecessary rework. When you talk about "writing clean code to make it have fewer bugs", you're talking religion. When you're talking about "reducing the defect rate by 10% saving 2 man-months of effort on the project", you're talking management. Clean code is a tool to improve the initial quality of the codebase and thereby lowering the total cost, but it is one of many.
The following paper explains why getting it right the first time matters from a cost perspective: http://www.cs.umd.edu/~mvz/pub/eworkshop02.pdf
I am unaware of any specific study, but check out work by Steve McConnell.
If anyone has it, he will. For instance a two minute scan found this (16 years old but still relevant today).
To add to mattnz's answer, if you haven't already I would say specifically check out Code Complete: A Practical Handbook of Software Construction by Steve McConnell. Besides the fact that it will likely improve your coding, he cites numerous studies throughout the book about how various coding practices affect the quality of programs.
As an example (from the book):
Another study of a different 450 routines (which is just an unusual coincidence) found that routines with the highest coupling-to-cohesion ratios had 7 times as many errors as those with the lowest coupling-to-cohesion ratios and were 20 times as costly to fix (Selby and Basili 1991).
Also it used to be the number one answer to the question What is the single most influential book every programmer should read? (though I see the answers to this question were recently reorganized in a lame way)
