'Whiteboard' your architecture
Visualizing design options and architecture on a whiteboard is a great way to represent, challenge and communicate ideas. At Magnifica we use whiteboards to draw (then normally erase and draw again) design options to discuss them as a team. It's a great time to discuss and re-enforce architectural principles i.e.:
- Single Responsibility principle
- Common-reuse principle
- Separation of concerns
- Principle of Least knowledge
Proof of concepts
If the problem domain is well known sometimes it's useful to just dive-in and write some code. Building a proof of concept to determine whether there exists, or is likely to exist, a solution that can successfully resolve a design issue is a great way to get to a decision.
Also, proof of concepts can help validate that your selected design option is the right decision.
Use notations and tools such as QOC
QOC (Questions, Options, Critera) is the method of notation we use when making key design decisions. Laying out your design issues/questions in a structured way against a list of possible options is the starting point. Next you define the criteria against which you want to judge the options available to the project. QOC is a great way to visualise, reason and argue for and against specific options.
It also provides a nice way of documenting these design decisions so that other members of your team can see why and how you came to a decision.
Collaborative decision-making
Because the decisions made by groups are often different from those made by individuals collaborative decision making can be an advantageous method of coming to a decision. It is however important to note that a poorly performing team or group is likely to produce a poor decision. It is
'Whiteboard' your architecture
Visualizing design options and architecture on a whiteboard is a great way to represent, challenge and communicate ideas. At Magnifica we use whiteboards to draw (then normally erase and draw again) design options to discuss them as a team. It's a great time to discuss and re-enforce architectural principles i.e.:
- Single Responsibility principle
- Common-reuse principle
- Separation of concerns
- Principle of Least knowledge
Proof of concepts
If the problem domain is well known sometimes it's useful to just dive-in and write some code. Building a proof of concept to determine whether there exists, or is likely to exist, a solution that can successfully resolve a design issue is a great way to get to a decision.
Also, proof of concepts can help validate that your selected design option is the right decision.
Use notations and tools such as QOC
QOC (Questions, Options, Critera) is the method of notation we use when making key design decisions. Laying out your design issues/questions in a structured way against a list of possible options is the starting point. Next you define the criteria against which you want to judge the options available to the project. QOC is a great way to visualise, reason and argue for and against specific options.
It also provides a nice way of documenting these design decisions so that other members of your team can see why and how you came to a decision.
Collaborative decision-making
Because the decisions made by groups are often different from those made by individuals collaborative decision making can be an advantageous method of coming to a decision. It is however important to note that a poorly performing team or group is likely to produce a poor decision. It is therefore important to try an create a 'Good' group to own the decision-making process.
A good group has:
- Clear goals
- Good communication
- Individuals with knowledge (find about knowledge)
- Good dynamics (e.g. individuals that aren't going to try to point-score)
Scenario based evaluations
Once a best design option has been selected you need to test the decision is sound. Scenario based evaluations are a powerful method for reviewing your choice.
Focus on a scenario that is most important to the business objectives of the product, check the impact on the suggested design.
