I don't know. It's not my experience that whether kicked off by novices or experts or anything in between, that the initial architecture will ever be done so well as to make maintenance and quality some kind of breeze when reality (users) sets in. Only if your problem space is so well known or tidy that it can basically be codified by an expert (which leaves like compilers, and a few other things).

I don't disagree that you don't want a bunch of greenhorns laying out the foundations for some big, long-term project. But, I just don't think it is ever realistic to avoid warts, and shortcomings, etc. and things that will "frustrate" developers because they would have built it perfect if only they had been there (accompanied by their hindsight...) but now they have to touch legacy code--icky!

That's my .02, but I think we as developers can often be prima donnas this way. It can't all be blue ocean and greenfield (i.e. fun). Dealing with and minimizing the shortcomings of software that has hardened and can't just be completely reimagined is--and will always be--part of the job.