All endeavors have their goof ups, and writing software is no exception. There are two ways of handling with mistakes - try to prevent them, or try to fix them. "Traditional" software engineering approaches focus on the former while "Agile" approaches focus on the latter. Formal requirements and big-up-front-design attempt to prevent mistakes from getting into code. Short iteration cycles with lots of customer interactions attempt to expose mistakes early and often so they can be fixed.
While the benefits of preventing mistakes is obvious, there are many less obvious benefits to embracing the mistakes and fixing them later.
When you accept that mistakes are part of the business, you plan for them. This leads to automated tests (to catch future mistakes), logging and other introspection techniques (like JMX) to catch and diagnose problems in the field, and hot patching or automated upgrades which have become par for the course in modern software - to fix bugs without a whole new release/deploy cycle.
These are obvious advantages and they can be (and are) used no matter what approach you take. However, there are some psychological advantages to embracing mistakes which can really pay off in terms of getting software out the door and getting it right.
Not being afraid of a mistake means you don't get paralyzed and can keep going. When developing software there are countless decisions that have to be made, from small things like what to name a variable, method, or class to larger things like what data storage mechanisms to use. With traditional approaches, your analysis step tells you everything you need to know to make the right decision. However, in practice, often you don't have enough information, or things change. This leads to extra long analysis and requirement gathering steps and the production of vaporware.
Accepting the idea that "it is ok to make a mistake now, because I can (and will) fix it later" is a huge step. Once you do that, you can keep from getting bogged down with the unknowable. Often it is by making a decision and seeing what the resulting software is, that you best understand the right decision. For me, one of the huge advantages of subversion over CVS is the ability to change file names while keeping revision history. Knowing that I can change a file name in the future keeps me from blocking while trying to determine exactly how a class will be used/morphed over time so I can give it the perfect name. Instead I give it the name that makes sense today, and if the class changes over time, the name can be changed to match its new use/behavior.
However, allowing yourself to make mistakes is only useful if you also a willing to admit mistakes. Admitting that a decision made in the past turned out to not be best is the only way that you can improve your software. It can be hard to admit mistakes, which is why I titled this post the way I did. If you embrace your mistakes, that means you are constantly willing to learn and improve, resulting in much higher quality software over time.