I once worked in a company that had a VB6 application (this was a long time ago), which had been mainly written by three developers working at the company. Two of them left, but we still have one of the original developer and five or six others that had worked on the application for a year or more.

One day we were discussing changing a section of the application to add functionality. I was surprised to find that none of the developers wanted to work on the code. They were all "afraid" to make changes. Having been a developer and spent time digging through other people's code, I was amazed by this. Certainly some tasks are difficult, but being afraid to change code?

I wish I'd been more knowledgeable then. Today I'd tell the developers the first thing they need to do is write tests. They need unit tests, or integration tests, but they need some way to determine if they are breaking functionality.

And if they do break something, that's fine. Go fix the breakage. Refactor other code, write more tests if they are needed, and go for it. You learn by breaking things. Your tests protect you and let you refactor code. As much as I realize we don't want to spend unnecessary time writing tests, we need something to examine our code as we write. We might as well use a testing framework to help. That way we're not afraid to change the existing application.