Over the years I've come to the conviction that the 2 most important properties of programs are simply
1. Correctness
2. Maintainability
A program that does not do what it's supposed to is of little value. This is a relative metric however, a program can do many valuable things right, yet have a few bugs.
But once a program does what we want, what else do we want from it? We want the ability to change it easily, so it can do even more things for us.
Maintainability is also a relative metric, and even harder to quantify than "correctness". However when looking at two ways of writing a specific part of a program, it is often easy to say which produces a more maintainable solution.
Many good candidates seem to anchor on those two properties (correctness and maintainability) as a starting point. More generally, they tend to identify that some of the properties are directly desirable right now, while others have no immediate value in themselves but are necessary to ensure that you can still have the directly desirable properties later. Which ones take priority under which conditions can be an enlightening conversation, often leading to related ideas like technical debt, up-front vs. evolutionary design, and so on.
A program that does not do what it's supposed to is of little value. This is a relative metric however, a program can do many valuable things right, yet have a few bugs.
But once a program does what we want, what else do we want from it? We want the ability to change it easily, so it can do even more things for us.
Maintainability is also a relative metric, and even harder to quantify than "correctness". However when looking at two ways of writing a specific part of a program, it is often easy to say which produces a more maintainable solution.