“The domain model of the design should be easily recognizable to a domain expert.”

The idea I am trying to get across is similar in tone to “Functionality is easily consumed,” but this time from a more abstract domain expert’s point of view. If an expert in the problem domain can’t understand your design (i.e. the basic concepts represented in your code), then how can you be sure you’re solving their problem? How do you communicate between each other? At some level your design should also feel natural when used in providing a solution to any necessary use case as defined by the the domain expert.

I think you could write a piece of software that meets or exceeds everything you listed above that still doesn’t satisfactorily address a problem your customers care about; thus, this last piece of the puzzle.

Everything is easily understandable & maintainable till we write that first line of code!

I still like ‘cool’ though

I think that could make a whole new blog post, but to give you a brief idea, you might look at this guy’s blog post: http://weblogs.asp.net/sfeldman/archive/2009/02/08/switching-ioc-container-with-linq-expressions.aspx

Basically abstract and encapsulate, keep your dependencies on you 3rd party IoC to a minimum and use your own abstraction as much as possible.

@Frank

I draw a distinction between entry level and junior (not all places do) and consider junior developers capable of at least reading and grasping code — of course it’s always a trade-off between complexity and intuitive design, but I believe you should only make it as complex as it has to be, and as intuitive as possible.