There are various aspects to the quality of a piece of software. Clearly correctness is of primary importance: does the program produce the required results/behaviour? This aspect of quality needs little justification: there is no point in having a beautiful, fast, all-singing-all-dancing program which doesn't satisfy the customer's requirements! If quality in this respect is low then nothing else matters, but attention to quality in various issues internal to the program will contribute to achievement of quality in respect of correctness. These aspects of the programming activity include the following:
Are the best tools being used for the job? For example: are while loops being used where for loops would be more appropriate; are variables which are used only locally within methods wrongly declared as class instance variables?
If quality in this respect is low then, even if the program is (mostly) correct, it may be very difficult and/or expensive to maintain (to adapt to new requirements, or to correct faults uncovered during testing or by users).
Professionally produced software is accompanied by extensive "external" documentation - paper or computer files describing the purpose of the software, the rational for its design, abstract views of the design, test plans, ...
A program's "internal" documentation is also important: the source text of the program should make itself easily understood (exactly what this means is the subject of the rest of this paper).
If the documentation is poor, then even if a program is correct, with appropriate use of language constructs, it may still be so impenetrable that it is difficult and/or expensive to maintain.