I would call the 2nd a failure. If it’s a nightmare to read and maintain, then it’s crap. Both of those characteristics also lead to the conclusion that the code is difficult to validate.

And in the end, if I can’t be certain that it’s correct, I don’t care about its performance, and neither should anyone else.

1) Performs required task in predictable conditions.
2) Degrades gracefully in unpredictable conditions. “Perfectly graceful” implies that a code failure has zero impact on other system components’ ability to perform their required tasks.
3) Does not lose properties 1 or 2 when another component is added to the system.

(note: component could be code fragments, functions, classes, executables, etc)

I do know what you mean though, real developers with hearth for their code will ‘feel’ if their code is good/bad enough already. I won’t argue there.

I’m writing a thesis about software quality, it is related to my job. My first question actually is “what is software quality”. As you said, it is subjective. In that sense we (developers) have to agree on a term we call “quality”.

I am still working on that definition. But from there it will be easier. Using Software Quality factors you might be able to know what Developers tend to like (ie, try to figure out what other developers think of in terms of quality). A good example is “maintainability”. You hear about that all the time. But even maintainability can be split up into tinier pieces.

Once i have my definition clear i can investigate metrics and such. Using such tooling I can score the quality factors we find important. Also, the tools will point us into pieces of code that should be worked on if we want to deliver quality as we see it.

Short answer is: Try to make it objective, and work from there. And even then there is only this little piece you probably have taken care of. Because, what *you* see as quality (as developer) might be totally different than your customer thinks off… but thats worth another thesis i guess :)

The trick is to make sure that there is a consistent view on what constitutes quality code within your team and hopefully within your company. When people who work together have wildly different ideas on the subject, that’s when it can get a little hairy.

For example, what is better – very clean readable code which is easy to understand but might not be as optimised as it could be, or highly optimised, great, intelligent code, which is a nightmare to read and maintain due to the many advanced techniques being used?

As I see it, both coding styles are good and both have their uses, but they cannot really be compared together. They should be compared to code similar to their style and requirements.