As Churchill famously remarked, “the maxim ‘nothing avails but perfection’ may be spelt shorter: p-a-r-a-l-y-s-i-s”.

You need to internalize the notion that this approach is unprofessional.

Or, as Jamie Zawinski put it (in “Coders at Work”, recommended by Joel Spolsky once), “At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

And that contains an important observation. The job of a programmer is not to write code! It is to solve problems. If a problem can be solved by not writing a line of code, or even by deleting code – all the better.

See your job as one of a problem-solver, who only happens to be a coder. Not the other way round. A shift in priorities follows organically.

I am suffering from the same syndrome, but I cope with it by doing hobby projects, in which I have no deadline and I have my own little perfect world. (And yes, they typically end up paralysed by perfectionism). But at least thanks to that I’m venting off from all the rotten compromises I have to make at work, and everybody’s happy 🙂

Thus my advice would be: try to write perfect programs in your spare time. You will learn that you’re chasing a mirage and it’s not worth it. Or you may get addicted to the thrill of chasing this mirage, but since it’s your spare time, your professional reputation won’t be exposed to risk, and you won’t feel so perfection-hungry at your pragmatic, day-to-day work. Or perhaps you’ll actually learn to write perfect programs in finite time. Either outcome is good!

If you absolutely cannot work on a solo project then how do you
explain it to your boss so that it doesn’t seem like you’re
incompetent?

Sorry to say that, but it wouldn’t only seem so. It is a form of incompetence, fortunately one that can be dealt with fairly easily.

One thing I could suggest from my own experience is to have a clear “definition of done” for every task you are working on.
Although this term comes mainly from the scrum environment (see a description here) it could also be helpful to adopt it when working alone on a project.

The main idea is that you define clear, measurable criteria that describe when a given task is completed.
But the important thing is that it also works the other way round:
As soon as the criteria are reached, the task is considered done and no more work should be spent on this specific task.
If you still think you could polish or tweak things a bit more up, define a new task (maybe with a lower priority) and define exactly what and how you want to polish this (again with clear acceptance criteria). But start this new task only after you have finished all other tasks with a higher priority.

In that way you could ensure that you do only the work which needs to be done to get the program to work.
Sure this might even mean that the software is not yet perfect but it doesn’t matter, at least it does what it should, and improvements can be done after that.

If your project has at least a product owner (or a person with an equivalent role) you both could sit together and define the DODs for every tasks together.

How do you overcome it?

I see (intentionally seeking) other people making mistakes and being fine with that. That tones down my fear of mistakes.

If you absolutely cannot work on a solo project then how do you explain it to your boss so that it doesn’t seem like you’re incompetent?

I don’t know how it looks from the eyes of my boss. I can’t read others’ minds. If I think I look incompetent, that’s just my fear of looking incompetent comes into play. And if I’m really incompetent and try to pretend I’m not, I screw up in the end anyway, so I better confess.

It is not clear from the question if the projects were actually released at some point or were they abandoned before the first release.

In the latter case it’s clear that a change in mindset is needed. We engineers would always like to perfect our product and feel uneasy when we need to release something that still has lots to improve. But this is exactly what needs to be done. You need to release early and release often and accept the fact that the first version will be painfully bad. This is the only way to write quality software that actually solves the problems your users wan’t to get solved.

It might also be beneficial for you to familiriaze yourself with the concept of Minimum viable product and perhaps even read the Lean Startup book from Eric Ries.