My opinion is that it's very, very hard to avoid this.
I would say that in all the software I have ever written, some part of it sucked. It's actually quite upsetting if I think too hard about it, I wish it wasn't that way. This is mainly because of four reasons (in no particular order):
1. I didn't have time to really finish it
2. I didn't test it thoroughly enough
3. There was some part of the underlying language or framework that I was unaware of that behaves unexpectedly (e.g. the framework encodes output, the int in the language can only handle up to 16384, or you can add a general error catcher, but if you invoke a web method in a particular way, the framework 'helpfully' circumvents the error handler, leading to weird bug that you never hear about)
4. I was using a new language/framework that I didn't know quite how to use. It's not just inexperience, quite often the examples for new frameworks/languages turn out to be bad practices or inefficient ways of doing things in the long run.
Even if you're a good programmer and try and plan ahead, quite often you're writing something you don't quite understand until you actually write it and as you go you make, in hindsight, a couple of poor decisions. It's often a big job to go back and change those poor decisions, and even if you did it might not completely fix the problem. Some remnants of the old design stick around like a bad smell.
And there's also bad design decisions that don't come out until the program is out in the wild, you might have thought the purpose of your wheel was to make bicycles, but in fact only a couple of neckbeards make bicycles, everyone else is making cars out of them and they're completely the wrong design.
And worse, only the neckbeards are on the mailing list so you get a disproportionate amount of feedback from a vocal minority and don't even realise it's not really suitable.
And on top of that, some software suffers from the first mover advantage though it's badly written and then gets almost, but not quite, abandoned, so no-one ever moves to the much better alternatives.
And then all those little warts and mistakes, as you say, propagate.
I have screamed at my screen in rage at how stupid some programmer has been while designing a program that almost does what I want but quite spectacularly (or worse silently) fails at some key part. But they probably tried hard to make it good.
In truth, writing excellent software is still the domain of a very elite few, the rest of us write ok, but very brittle, software.
I would say that in all the software I have ever written, some part of it sucked. It's actually quite upsetting if I think too hard about it, I wish it wasn't that way. This is mainly because of four reasons (in no particular order):
1. I didn't have time to really finish it
2. I didn't test it thoroughly enough
3. There was some part of the underlying language or framework that I was unaware of that behaves unexpectedly (e.g. the framework encodes output, the int in the language can only handle up to 16384, or you can add a general error catcher, but if you invoke a web method in a particular way, the framework 'helpfully' circumvents the error handler, leading to weird bug that you never hear about)
4. I was using a new language/framework that I didn't know quite how to use. It's not just inexperience, quite often the examples for new frameworks/languages turn out to be bad practices or inefficient ways of doing things in the long run.
Even if you're a good programmer and try and plan ahead, quite often you're writing something you don't quite understand until you actually write it and as you go you make, in hindsight, a couple of poor decisions. It's often a big job to go back and change those poor decisions, and even if you did it might not completely fix the problem. Some remnants of the old design stick around like a bad smell.
And there's also bad design decisions that don't come out until the program is out in the wild, you might have thought the purpose of your wheel was to make bicycles, but in fact only a couple of neckbeards make bicycles, everyone else is making cars out of them and they're completely the wrong design.
And worse, only the neckbeards are on the mailing list so you get a disproportionate amount of feedback from a vocal minority and don't even realise it's not really suitable.
And on top of that, some software suffers from the first mover advantage though it's badly written and then gets almost, but not quite, abandoned, so no-one ever moves to the much better alternatives.
And then all those little warts and mistakes, as you say, propagate.
I have screamed at my screen in rage at how stupid some programmer has been while designing a program that almost does what I want but quite spectacularly (or worse silently) fails at some key part. But they probably tried hard to make it good.
In truth, writing excellent software is still the domain of a very elite few, the rest of us write ok, but very brittle, software.
EDIT: Added reason 4