[Chris_Newton]

Probably my favourite open-ended interview topic for programmers is asking them to rank various properties code might have in order of importance, and explain why they chose the order they did.

For example, one possible list of properties might be conciseness, correctness, documentation, efficiency, maintainability, portability, readability, and testability.

Often, I can learn a great deal about what sort of person I’m talking to just by watching them define their terms, decide what assumptions they think are necessary, and then reason through the resulting dependencies.

I get the feeling that the parent posters (hercynium and catnaroek) might argue for quite different orders, but both with good reasons.

[galaxyLogic]

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.

[Chris_Newton]

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.

[hercynium]

Bingo!