Design specifications aim to formalise the requirements that must be fulfilled. However, different developers will interpret these specifications in different ways. 

For example, consider the design of a bridge: 

• different structural engineers are likely to create quite different bridge designs. Each design may equally fulfil the design specifications; 
• it is the manner in which these specifications have been interpreted and implemented that is different. 
• The Sydney Harbour and Golden Gate bridges both fulfil similar design specifications yet these specifications have been interpreted in quite different ways.

Software development involves many creative aspects. 

This is particularly obvious in regard to the design of the user interface, however it is also true for algorithm and source code development. It is natural for different people to interpret the same specifications in different ways. 

For example, the design specifications for a module may require the input of a date by the user. The date could be collected as a complete string or it could be collected in pieces as year, month and day. In the first case, the entire string must be validated and in the second case, each component would be validated once entered. Both interpretations fulfil the design specifications in different ways.

Even if the design specifications are interpreted in the same way, it is likely that different developers will create quite different solutions. Most problems can be solved in an almost infinite number of ways. In this section, we are concerned with evaluating what makes one approach better than another when each approach solves the problem.

We are interested in assessing the elegance and efficiency of different solutions. Elegance is a somewhat subjective term. It refers to solutions that are superior, cleverer or more refined. Elegant solutions will also be more readable, both in terms of the code itself and its related documentation. Unfortunately, there are no hard and fast rules; each approach needs to be critically examined, however a number of guiding questions may assist in this process:

• Is it a generic solution? 
• Generic solutions are easier to modify if specifications change in the future. 
• Furthermore, they are easier to reuse as part of other applications.

• Can it be understood? 
• Algorithms and code that are difficult to understand will be difficult to test and maintain. 
• The code itself should be understandable but it should also be suitably documented.

• Is it efficient? 
• Inefficient solutions require more processing resources and thus execute more slowly. 
• Solutions should solve the problem in the best possible way. 

• Is it self-contained? 
• The solution should solve the problem without affecting other code. 
• As a consequence, testing and reusing the module will be easier.