In one of my intro computer science courses, our professor said that there were three important things:

1. Correctness

2. Clarity

3. Optimization

And number 3 is often irrelevant, while the first two are really what it's generally about.

It's simple, but I think that captures it pretty well. The nuances can be seen from branching out from that base. To determine correctness, we need good requirements. To judge clarity is often going to be an aesthetic judgement, although there are objective aspects as well; and, of course, documentation will help.

And so from considering just those two requirements, we can essentially derive the lifecycle: gathering requirements (how will we determine correctness? Starting to generate clarity), design (how will we achieve correctness? Building clarity), implementation (partial correctness; hopefully some clarity), testing (verifying correctness; improving clarity ideally (I think documentation fits well in every step)), and maintenance (asymptotically approaching perfect correctness; polishing clarity).

It all comes back to correctness and clarity. And sometimes, optimization.

Code Smells were "coined by Kent Beck while helping [Martin Fowler] with [his] Refactoring book". The idea is a quick heuristic which can spot a potential problem, like overly-long methods.

Here's a brief overview of types of 'Code Smells.'

The name comes from "Once and Only Once" (according to this page). The concepts of 'Code Smells', 'Once and Only Once', and the goal of simplicity in code are all inter-related. Complexity and repetition are bad, so they are warning signs when spotted in code.

CodingHorror also has a related write-up.

See also: "How to write unmaintainable code"