Think, Do, Check

Every day, for as long as we work on a software system, we learn interesting things about the software. Every new thing we learn might force the architecture to evolve to reconcile the new information. For us to keep tabs on this ever changing landscape, we need a design approach with a tight feedback loop that gives us the opportunity to change our mindsets often.

There are three steps in our approach: think, do, and check. Each iteration of the think-do-check cycle focuses on a particular design mindset.

Iterate to Learn

An iteration can be as brief as a few minutes or as long as a few days. We prefer shorter cycles over longer ones, but sometimes more time is required for in-depth research. Every iteration follows the same steps, though the execution will vary depending on the design mindset we adopt.

Think

What do we hope to learn? What questions do we need answered? What are our top risks? Thinking involves creating a plan to learn what we need to answer specific questions or reduce risks.

Do

Execute the plan. Create something tangible that quickly and cheaply uncovers information needed to check our thinking and share our ideas.

Check

Critically examine what we accomplished during the do step so we can decide our next move. The insights coming out of the check step tell us what to do next. Repeat at the think step.

A software system is never finished; it is only released. Since software is never done, our design approach has no end. Anytime you need to revisit some aspect of the architecture, whether it’s to evolve an existing design or create something new, the same approach applies.

Adopt Mindsets in Any Order

Think of the four design mindsets like four tool boxes, each containing tools tuned for a particular type of design work. When the need arises, embrace the mindset required to learn more about the world or reduce a risk.

In the understand mindset, we’ll focus on stakeholders needs and how to specify those needs as requirements. In the explore mindset, we’ll brainstorm ways to solve the problem as we understand it by looking at patterns, technology, and other solutions. In the make mindset, we’ll model the system so we have something concrete to reason about and share. In the evaluate mindset, we’ll put our models and requirements to the test.

Mindsets shift frequently and quickly. During a single conversation, we might change mindsets several times. During a workshop, we will create situations that force participants to adopt new mindsets so that we can arrive at a desirable outcome. You’ll see an example of this in Chapter 9, ​Host an Architecture Design Studio​.

Experienced architects are often unaware that they attack architecture from varying perspectives. They fly by instinct and adopt different mindsets intuitively (thanks to years of practice). Awareness of the four design mindsets gives us new techniques for getting out of a rut. If you get stuck, choose a new mindset to get yourself unstuck.

Plot Your Course: Think-Do-Check and Mindsets in Action

Let’s see a concrete example of how the think-do-check cycle and design mindsets might play out in practice. Say a stakeholder just gave us a new constraint and this increases the risk that the architecture will be unable to satisfy performance requirements.

• Think. We know system performance is important, but we don’t know what it means to have good performance. Since we need information about the problem, let’s adopt the understand mindset. Looking through some practices in Chapter 14, ​Activities to Understand the Problem​, we decide to capture quality attribute scenarios.

• Do. We brainstorm some performance scenarios and record them in a document.

• Check. The team and stakeholders review the scenarios and provide feedback.

Based on what we learned, new risks arise. Can we achieve the performance quality attribute scenarios given the new constraint?

• Think. Since we need to verify that our decisions promote a specific quality attribute let’s adopt the evaluate mindset. We plan an experiment so we can directly test the constraint’s impact on performance.

• Do. We write some simple scripts to drive existing parts of the software system and collect data. We run the experiment.

• Check. With data in hand, we examine the results and conclude that the new constraint negatively impacts performance but only by a few 100 milliseconds.

We think we’ve done a thorough job, but performance is funny. Hurting performance might not be a big deal until it degrades too much. We need to share these results with our stakeholders and discuss the implications of the new constraint.

• Think. Since making ideas tangible facilitates communication, we’ll adopt the make mindset and create a simple prototype. We want stakeholders to experience the impact of the new constraint. Graphs aren’t enough.

• Do. We develop a throwaway prototype that demonstrates the application workflow and simulates different assumptions about performance.

• Check. We give the prototype to our stakeholders and explain why the performance of the system was impacted. On paper, a few 100 milliseconds is tiny, but experiencing the slowdown firsthand shows that this dip in performance isn’t acceptable.

The prototype helped our stakeholders learn something about the problem nobody knew was important until now. Next, we’ll adopt the understand mindset and refine our new requirements. We check our understanding a few minutes in the same meeting by selecting the explore mindset. And the cycle continues.

The think-do-check cycle is extremely flexible. How you use it depends on the complexity and size of the system, your team’s size and skills, and your experience with having simultaneous design initiatives in flight.