How we’re using CRC cards for Agile software design

Scenario

At Simply Business, our engineering teams develop insuretech systems that enable our customers to get the right insurance product for their small business. We were looking to expand our product offerings in the US to include Business Owners Policy (BOP), which provides protection for business property and liability.

This presented a few software design challenges.

• To implement BOP, our team needed to design a way of capturing additional risk factors for businesses seeking insurance, that determined the risks that the business is exposed to. These risk factors would be sourced from a third-party provider and be used to enrich the data we already held to provide insurance quotes for BOP.
• We also wanted to design the system in a way that would support integration with additional third-party data providers in future.

The problem was, how could we design and store risk factors from third-party providers?

Designing with CRC cards

The team needed to get a sense of the bigger picture, identify all the pieces involved in solving the problem, and then be able to iterate on ideas rapidly.

We chose to appeal to a technique we’ve turned to frequently on our journey in breaking up our monolith, which is to use CRC cards – an object-oriented design technique developed by Ward Cunningham and Kent Beck in the 1980s. CRC cards are a prototypical technique for designing object-oriented systems using index cards, in which each card contains the name of the class, its responsibilities and its collaborators (i.e. other classes that the class needs to fulfil its responsibility). In the age of remote working, we used this Simple CRC card app.

Forming an initial design with CRC cards

Using CRC cards, we translated our business needs into use cases, objects and responsibilities to arrive at a set of classes.

We began by listing the use cases we needed to find solutions for, and used role play to identify the objects involved in each use case, in accordance with the usual practice.

The team picked up this practice very quickly – the learning curve seems to have a very small gradient. Team members soon became quite creative with the practice. The result was a number of refactorings of the cards, involving moving responsibilities. Perhaps we can call this refactoring a Move Responsibility.

Iterating on the design

We found that we iterated through the design many times, almost 20 times in total, mostly simplifying the design. Therefore we propose some names to the CRC card refactorings we did: Clarify Responsibility, Extract Class card, Inline Class card and Convert Responsibility To Class card.

To be or not TDD

The team set about testing the design hypothesis using Test-Driven Development (TDD). In the words of one of our software engineers, ‘the overall process was enjoyable’. Engineers were able to map how things fit together easily; they found the ‘separation of concerns clearer to grasp’ and ‘TDD felt seamless’.

What was also interesting from an architectural perspective was how easily our design aligned with the long-term architectural vision for our platform, and that the design could be adapted to support upcoming use cases.

Specifically, the Third Party Risk Factors card we identified to capture risk profiles for third-party data would support our transition to microservices.

What we achieved here was a seam that hid the design decision of whether the sub-system is a component within another, or a separate microservice, from the client, an application of the principle ‘Use Uncertainty As A Driver’, taken from 97 Things Every Software Architect Should Know by Kevlin Henney.

We might have made that decision an implementation detail. In the end, we decided on a microservice. The client system remains largely unaffected by the decision of course.

Through the Extract Class card refactoring, we discovered a client-driven contract for the microservice; it receives a list of Risk Fields and responds with a series of Risk Factors:

f(RiskFields):-> RiskFactors *

Example:

To conclude, using CRC cards as a design technique gave us a very good starting point to develop a testable suite of code from which it could be refactored using the Four Elements of Simple Design.

A special thanks to Simply Business colleagues: Kavita Gupta for facilitation support, and Etienne Mustow, Monika Danielewicz and Joe Donahue for collaboration on the project.