I suppose the answer can only be supplied if we know more about you as a developer, and as a person. If you're a perfectionist, then it could well be that your previous projects are perceived by others to be of better quality than you yourself perceive them. A perfectionist could well consider a project 'unfinished' if it doesn't cover improbable edge cases, for example.
However, assuming that you're accurate in your statement that your projects were unfinished, then it would appear that you need to question why that's the case, as we cannot infer that the traits you've ascribed to yourself are the cause of project failures without knowing more about the other variables in the equation. For instance, the projects may well all have been failures for no fault of your own: scope creep, management interference, poor teamwork (or poor team members), or any number of other variables could be responsible. But since this is not something we can address at this point, let's assume that your project failures are indeed a result of your perfectionism.
The easiest way (in my experience) to 'cure' perfectionism in software is to follow the YAGNI ("You Ain't Gonna Need It") mantra, coupled with approaching a project from a divide and conquer perspective (yeah, pg would pretty much hate this). First break the project into its key deliverables and its 'nice to haves'. Once all the key deliverables are complete, then the project is complete; 'nice to haves' aren't factored into the completeness equation for the project. Once you know what your key deliverables are, then order them in terms of dependency: if deliverable A requires that deliverable B be completed before deliverable A can be completed, then focus on deliverable B first. Now that you know what you're supposed to be working on, you can get started on the deliverable at the root of your dependency tree, but whilst working on it ensure that you're only adding the functionality necessary to complete the current deliverable. As you work your way through your deliverables, refactor the previous deliverables as necessary to make your current deliverable work. For instance, if your root deliverable wasn't required to be thread-safe when you first wrote it, but your new deliverable requires it to be thread-safe, then work your way back through your deliverables refactoring as necessary in order to meet the requirements for your current deliverable.
By sorting your deliverables into dependency tree, you can ensure that you can properly apply YAGNI. It's very tempting for a perfectionist to turn into an architecture astronaut, and spend weeks or months mapping out the entire solution and all its edge cases before they've even started to work on a single deliverable; by keeping your deliverables in a dependency tree and working from the least to the most dependent, you force yourself out of this mindset. By applying this method, you also force yourself away from analysis paralysis, because you're not permitting yourself to consider patterns or architecture until the project's current deliverable necessitates it.
It's worth noting that this method won't work for all projects, as it requires a good understanding of what the deliverables for the project actually are before you can apply it. It also may not work for you at all, since it's all down to personal experience, but I've personally found that forcing yourself to focus only on the concrete deliverables ensures that you don't end up stalling yourself in analysis, and gives you lots of little pep boosts in the form of finished deliverables and refactorings.
Nonetheless, good luck finding a cure that works for you.
However, assuming that you're accurate in your statement that your projects were unfinished, then it would appear that you need to question why that's the case, as we cannot infer that the traits you've ascribed to yourself are the cause of project failures without knowing more about the other variables in the equation. For instance, the projects may well all have been failures for no fault of your own: scope creep, management interference, poor teamwork (or poor team members), or any number of other variables could be responsible. But since this is not something we can address at this point, let's assume that your project failures are indeed a result of your perfectionism.
The easiest way (in my experience) to 'cure' perfectionism in software is to follow the YAGNI ("You Ain't Gonna Need It") mantra, coupled with approaching a project from a divide and conquer perspective (yeah, pg would pretty much hate this). First break the project into its key deliverables and its 'nice to haves'. Once all the key deliverables are complete, then the project is complete; 'nice to haves' aren't factored into the completeness equation for the project. Once you know what your key deliverables are, then order them in terms of dependency: if deliverable A requires that deliverable B be completed before deliverable A can be completed, then focus on deliverable B first. Now that you know what you're supposed to be working on, you can get started on the deliverable at the root of your dependency tree, but whilst working on it ensure that you're only adding the functionality necessary to complete the current deliverable. As you work your way through your deliverables, refactor the previous deliverables as necessary to make your current deliverable work. For instance, if your root deliverable wasn't required to be thread-safe when you first wrote it, but your new deliverable requires it to be thread-safe, then work your way back through your deliverables refactoring as necessary in order to meet the requirements for your current deliverable.
By sorting your deliverables into dependency tree, you can ensure that you can properly apply YAGNI. It's very tempting for a perfectionist to turn into an architecture astronaut, and spend weeks or months mapping out the entire solution and all its edge cases before they've even started to work on a single deliverable; by keeping your deliverables in a dependency tree and working from the least to the most dependent, you force yourself out of this mindset. By applying this method, you also force yourself away from analysis paralysis, because you're not permitting yourself to consider patterns or architecture until the project's current deliverable necessitates it.
It's worth noting that this method won't work for all projects, as it requires a good understanding of what the deliverables for the project actually are before you can apply it. It also may not work for you at all, since it's all down to personal experience, but I've personally found that forcing yourself to focus only on the concrete deliverables ensures that you don't end up stalling yourself in analysis, and gives you lots of little pep boosts in the form of finished deliverables and refactorings.
Nonetheless, good luck finding a cure that works for you.