Fundamentally defects are deviations between a user’s expected behavior and actual system behavior. That presumes there is an understanding of what users expect, and while a spec can model that, a spec can also bake rules in stone that break user expectations. So I would argue it is not the spec as such that increases quality, but rather having a documented reference of how the system ought to behave, whether written beforehand like a spec, afterwards as documentation, or during in the form of high quality tests.
If there is no separate record of how the system should behave there is no clear line between bugs and features, and the software will grow warts based on the vagaries of the ticket system. Often at that point someone proposes a rewrite to clean things up (aka “build it twice”), but unless the second time a proper spec is created the end result after a few years is often equally filled with warts. Quality is a process and not a feature, and the same process will usually produce a similar quality. I’ve seen the same software rebuilt four times, and only the fourth time was it preceded by a proper spec resulting from extensive user conversation. That fourth castle stayed up.
If there is no separate record of how the system should behave there is no clear line between bugs and features, and the software will grow warts based on the vagaries of the ticket system. Often at that point someone proposes a rewrite to clean things up (aka “build it twice”), but unless the second time a proper spec is created the end result after a few years is often equally filled with warts. Quality is a process and not a feature, and the same process will usually produce a similar quality. I’ve seen the same software rebuilt four times, and only the fourth time was it preceded by a proper spec resulting from extensive user conversation. That fourth castle stayed up.