Design quality is people-sensitive. Programmers, even those of equivalent competence, have varying levels of expertise. A design that assumes Java idioms may be incomprehensible to a programmer who’s only familiar with Perl, and vice versa. Because design quality relies so heavily on programmer time, it’s very sensitive to which programmers are doing the work. A good design takes this into account.

Design quality is change-specific. Software is often designed to be easy to change in specific ways. This can make other changes difficult. A design that’s good for some changes may be bad in others. A genuinely good design correctly anticipates the changes that actually occur.

Modification and maintenance time are more important than creation time. It bears repeating that most software spends far more time in maintenance than in initial development. When you consider that even unreleased software often requires modifications to its design, the importance of creation time shrinks even further. A good design focuses on minimizing modification and maintenance time over minimizing creation time.

Design quality is unpredictable. If a good design minimizes programmer time, and it varies depending on the people doing the work and the changes required, then there’s no way to predict the quality of a design. You can have an informed opinion, but ultimately the proof of a good design is in how it deals with change.