Create Opportunities for Safe Practice

We want to give our team more design authority, but this is only possible if they’re prepared to handle it. Teammates can’t gain experience unless they practice. We’re on a tight deadline, and taking time away from development for training is asking a lot. What do you do? Find safe ways to practice design.

Pair Design

Pairing is one of the simplest and safest ways to practice design. Start by working one-on-one with teammates while you’re doing design work. If you need to think through a model, invite a teammate to join you for a whiteboard jam, introduced. If you have a meeting to talk to stakeholders about quality attributes, take a teammate with you. Ask a teammate to review a document filled with decisions before you share it with the whole team.

Create Scaffolding

In education theory, instructional scaffolding refers to support structures given to individual students to promote and reinforce learning. In school, you likely experienced many scaffolding techniques such as detailed feedback on a test, handouts, rubrics, and homework templates. We can use similar techniques when teaching our team about architecture. Here are a few examples:

• Build templates to support commonly delegated design work.

• Provide constructive criticism during peer reviews. See Activity 31, ​Code Review​.

• Create a code skeleton for new components. The code skeleton should sketch the module patterns planned but still require work to put meat on the bones. Bonus: Pair with someone to create the skeleton.

• Describe expectations for a particular artifact and share an example of what better and worse versions of that artifact look like.

• Create checklists for different design mindsets and tasks to help teammates internalize architectural thinking.

Introduce Architectural Guide Rails

An architectural guide rail restricts design options to ensure detailed design stays within the bounds of the desired architecture. Guide rails are a form of constraint we choose for ourselves. We can use guide rails to make design simpler (see ​Limit Design Options with Constraints​), but we can also use guide rails to create opportunities for safe practice. Imposing guide rails decreases the chances that we’ll mess up the architecture.

Guide rails come in many forms and varying strengths. A design policy, instructions that describe something to do or avoid doing, is a simple guide rail but difficult to enforce. We can temporarily impose design policies when we delegate design work or put policies permanently in place to reduce risk, promote quality attributes, or overcome team weaknesses.

The strictest architectural guide rails are built into the code and make it impossible to do the wrong thing in the architecture. We discussed several approaches for creating guide rails in ​Build Models into the Code​. One example of a guide rail is to require the use of a specific library. Imposing this constraint might make development easier and help you avoid simple mistakes.

Host Information Sessions

If your team is keen on software architecture, consider hosting information sessions so you can dive deep into specific topics. Always be prepared to teach relevant information just-in-time before the knowledge is required to be applied. Dozens of micro-lessons are just as good as a single long training session.

As the team’s skills increase, they’ll start to share more feedback about the architecture’s design. Be gracious with feedback and encourage it. When the team is willing to tell you how to improve the architecture, then you’ll know you’re doing something right and can think about delegating more design authority.