Pragmatic Dictator

The act of design includes:

• Consideration of many possible technology options
• Examination and identification of constraints
• Thought about the pros and cons of using various patterns and styles
• Comparing various splits of role and responsibility
• Looking at various tradeoffs of complexity versus function
• Formulation of opinion on possible future directions of system growth

A large proportion of this information is lost when the design document is written, because the focus is typically on providing a (notionally) definitive view of how a system should be structured which might be in the form of a bunch of UML diagrams or merely a collection of Visio-type diagrams and explanation of what each of the boxes in the diagrams does. At the code-level there is almost no chance that any of this information will have been retained. Yet this information is of high value since it:

• is the explanation as to why a design is the way it is
• provides reviewers with a clearer view of what was and was not considered
• forms the basis for assessment of the maturity of a designer and can be used for coaching/mentoring
• can provide insight for those with less experience
• contains assumptions which if breached by changes in circumstance would dictate a re-design
• dictates to a large extent how suitable for purpose a design might be

Thus I believe It’s important to expose elements of the act of design via documentation alongside the design itself, conversations during the design work etc.