So, for the consumer it must:
- execute and perform the functions needed by the consumer within the parameters the consumer needs (execution speed, accuracy of outputs, ease of use, development time, etc) and not do things that the customer doesn't need or want like open up security holes.
For the authors/maintainers of the code it must be:
- clear to read (by conforming to some coding standard and be documented to the point where those who did not write it but are familiar with the language/framework can learn what is does and hopefully why, without undue hurdles).
- consistent by using some type of paradigm throughout that unifies it (a domain model) that can be understood by the consumer (domain expert) and the developers alike (i.e., a shared domain language). This makes it easier to modify and more useful and understandable to the consumer.
- verifiable by some type of automatic and documented means (usually tests). This also makes modifications easier due to the assurances that the documented functionality in the tests, if they still pass after modifications, has not regressed. Static typing and compile time errors help with this in my opinion.
- have little magic. It's harder to find and fix problems if it is not clear what something does and how it does it. Code that is debuggable is much easier in which to find and fix problems.
- structured appropriately for the situation. It is possible and I have seen cases where code has had too many layers and not enough layers. Blindly following best practices without knowing how they apply in a particular situation may just add unnecessary complexity and cost, but writing code without thought for structure and best practices quickly becomes unmaintainable. So, a balance is needed here.