I remember a few months ago one of the Bodington developers once telling me that Moodle was rubbish.
This sort of took me by surprise. I know a lot of the Moodle source code is not very good code, but Moodle is used by about 12000 schools, colleges and universities, whereas the number that use Bodington is in single figures to the best of my knowledge. Moodle solves people's problems more than Bodington does at the moment, so it puzzled me how it could be called rubbish in comparison. After all the point of software is to make somebody's life somewhere better in some small way.
Now this is possibly a short-term vs. long-term thing. Moodle might find one day that it is nearly impossible for it to improve any more in certain ways because of various short-term decisions that were made. It's often much easier to do certain things from scratch rather than change what's already there that is being used by people. But it's good for there to be both short-term and long-term solutions. In fact, you almost need both. As I've said before, developing a VLE without looking through all the things that Moodle has gone through would just be silly. You could learn so much.
Sometimes you do want to go for the long-term solution from the start because the up-front investment will save you such much time later. Provided you're sure there's going to be a later. This is why The Simplest Thing That Can Possibly Work isn't always right. When I do requirements types stuff for new projects, I'm as much trying to figure out what sort of changes will and will not be needed later as to figure out what's needed now. Sometimes something that requires almost no extra effort at the beginning such as setting up the database structure in a particular way will save lots of work down the line.
The problem is I think when people want everything about some code to perfect and don't realise that certain sorts of perfectionism take time and you could be spending that time doing other things. It's a fine line - you've got be cautious because of the Broken Windows phenomonen, and I'm not advocating sloppy code. But there's also the Pareto Principle and when you're trying too hard to be perfectionist you're usually doing it for slightly selfish reasons - you're often doing it more because you want people to think you're perfect than because it's actually the best thing to do. That is unless you write software that keeps aeroplanes in the air or something that like, in which case I'd rather that you were perfectionist. I used to write some of the software that makes sure the internet stays up and that was also one of those times when corner-cutting wasn't in order.
It takes quite a lot of courage not to do things perfectly but do more useful stuff instead. It's much easier for people to fault you for things that you haven't done perfectly than to do so for being too slow - the latter seems to get regarded as just bad luck or inevitable. People never compliment you on having the common sense not to make a part of the user interface that almost nobody ever uses quite as good as it could be or to not check your site in every single browser that exists.
I think it's also scary from a professional pride point-of-view that it might actually sometimes make business sense to ship software that has bugs. We all want to improve how we do things and to be perfect. And you do gradually improve, but after all, there's no point developing perfect software if nobody uses it. Though coincidentally the only software I've ever developed that hasn't been used is the stuff that's supposed to go into the next release of Moodle...