It is interesting how the trade-offs between the following two desires come into play:

[1] "more extensible and more maintainable" (long term) [2] "meets a date with sufficient functionality" (short term)

In either case, intolererable bugs make the contribution invalid. The stuff has to "work" for the cheque-writer's definition of "work".

A manager setting pay rates has less latitude than people might think. The perception of bean-counters and other upper-management is that programming talent is a commodity that does not vary as much as it truly does. Even if they were to pay a superstar (defined however you like) what they were worth (in term of the bottom line), then they get nervous about having too many of their eggs in one basket. e.g. "Uhhhmm ... how about you get me 4 mediocre programmers instead of that superstar so that if one leaves or gets sick I am still covered".

I can tell you that most managers are driven by item [2] above with mostly just lip-service being paid to [1].

The peers of developers are much more slanted to [1]. This is why open source can kick so much butt. Developers actually get to do the right long-term thing.

So, in practice, a superstar "date meeter" trumps a "extensibility maven" in a managers (i.e. his bosses) eyes nearly every time.