Good Code

What are the fundamental, orthogonal aspects of GoodCode?

Meets users' needs (not exactly the same as fulfills requirements)
OnceAndOnlyOnce (within reason)
SimplestThingThatCouldPossiblyWork
Handle likely ChangePatterns without requiring an overhaul

Alternatively, see the four rules at:

XpSimplicityRules

But some code could not meet any user needs and still be good code. We are talking about good code, not a good product.

So you are saying that as far as GoodCode is concerned, "meeting users' needs doesn't matter". For the above to be true, however, it would have to be the case that "the users of the code" and "the users of the product" refer to the same set of persons. Is that true? (Does your definition of "user" make it true?)

Sorry, I was not clear enough; my point is that good code is not necessarily related to users' needs and that meeting these needs is not sufficient to qualify code as good. I may have perfect code which is not meeting (or not meeting any more) the users' need.

Let's divide software quality topics into two areas:

External quality mean all the properties of the software as a product that users can experience and enjoy:

conformity to their expectations (and evolution thereof)
reliability
accuracy
ease of use and comfort (including response delay)
robustness (or adaptability to some unforeseen condition of use)
openness (or adaptability to future extensions or evolutions)
... I'm surely forgetting many more.

Internal quality mean all the properties of the software as seen by the developers that are desirable in order to facilitate the process of creating a good product :

concision : code do not suffer from duplication
cohesion : each [module|class|routine] does one thing and do it well
low coupling : minimal interdependencies and interrelation between objects
simplicity
generality : the problem domain bounds are known and stated
clarity : the code enjoys a good autodocumentation level

From here, I can't find any other property that GoodCode should hold. Surely, there are some. [Where lies maintainability?]

In which of these two category should enter "meeting users' need"? Clearly, this is an external quality point. On the other hand, many software applications do satisfy that point, while being based on good, ordinary or even really bad code.

Of course, in any situation where one writes code, meeting user's need really matters. But that doesn't quite influence the quality of that code. Hope I clarified my point.

I for one find the distinction between InternalAndExternalQuality a useful one, though not a "philosophically" rigorous one; from one standpoint at least, the customer's, only external quality matters. (The excellent discussion of quality attributes in BertrandMeyer's ObjectOrientedSoftwareConstruction 2, for instance, is quite clear on this.)

The point I was making above is different, though; it's that "meeting users' needs" isn't necessarily the same as "meeting requirements", and there might be users of the code who are not users of the product. Developers, testers, etc. would belong to that category. If we define "users" this broadly, GoodCode can be adequately (and completely) defined as that which best meets the needs of all its users.

I find this broadening of the acceptation of the term "users" a little bit embarrassing because it can involve the team in some "Who's The Customer?" AntiPattern - mixing and changing priorities on the basis that we don't exactly know who is the customer. Of course, we can say that Developers and Testers are also users of the code. But it seems counterintuitive and confusing when talking about software product and software artifacts' quality.

May I try this analogy: technically, the Author of a book and the Editor of that book are also readers of the book. But when both are working on that book at different levels, they clearly use one acceptation of the term "Reader", and that is "The reader of the book as a product".

"GoodCode is code that can't be improved significantly even by expert software developers."

Concision, cohesion, low coupling, simplicity, generality, clarity. Is something missing?

I think it is too specific. For example, if the coupling is too low it can reduce the quality of the code. In some contexts, even a high-coupling may be called for. So, if we say low-coupling, at what point do things become too decoupled? <-- This is unclear.

You assert that coupling can be a good thing, then ask when. That alone seems an argument that coupling is bad. It's not a rigorous argument, but you get the idea.

Opinions about what is GoodCode is a landmind of HolyWars. Personally I believe it's mostly about fitting individual WetWare rather than finding the OneTrueWay.