Pairing with a Subject Matter Expert
How doing so can address the root causes of technical debt
In my prior post, I introduced strong-style pairing as an alternative to the traditional driver-navigator pairing style that most software engineers are familiar with. I also covered two key usage contexts where I’ve seen strong-style pairing especially beneficial — interviewing and onboarding.
In this post, I talk about a key usage context for strong-style pairing that is often overlooked.
Leveraging a Subject Matter Expert
Modern software engineering involves much more than simply writing source code that executes some expected behaviour. A more fundamental purpose of software engineering is to create a programmatic model of reality. This reality is often referred to as a business domain, and the distilled logic that mirrors this reality is called business logic. Indeed, Domain-Driven Design (DDD) is the methodology we adopt when we take domain modelling to be the primary goal of software engineering.
Given that domain modelling is a crucial role of software engineering, what happens when the software engineers lack knowledge in the domain? Take accounting as an example. Many accounting designations can take a decade to earn, requiring university degrees, completion of standardized tests, as well as years of relevant experience in the field. How are software engineers expected to acquire this level of knowledge at the same time as building the software product itself?
The answer: they’re not. Or at least they shouldn’t be.
DDD comes with a number of key activities and practices such as event storming and ubiquitous language that leverage domain experts effectively. These domain experts are more commonly referred to as Subject Matter Experts, or SMEs. These SMEs are not typically software engineers. Nevertheless, a SME with a strong technical grasp of a business domain could be navigated through a sufficiently-expressive codebase with the help of a software engineer. This is where the practice of strong-style pairing comes into play.
Shared understanding of the domain model
A firm prerequisite for a successful strong-style pairing session is for the strong-navigator to have a clear idea that they wish to explore. “Explore” can mean implement, validate, or understand. In the usage context of leveraging a SME in a strong-style pairing session, it's the SME who should possess this clear idea. Consequently, the SME takes on the role as strong-navigator, while the other role takes control of the keyboard — we use the term “typist” for this role, though they may not necessarily be typing in this usage context.
Given this setup, the SME now explains their understanding of the business domain, while the typist maps this understanding to the modelled domain of the codebase. As they do so, they step through the code while translating and explaining to the SME how the software behaves.
Such a pairing can build a shared understanding in two key ways:
The typist gains an understanding of the business domain beyond what is modelled by the codebase, including gaps and errors in how the modelling has been done.
The strong-navigator gains a concrete understanding of how the business domain has been actually modelled by the codebase; similar to the typist, this understanding includes gaps and errors in the current model.
Gaps in the domain model
On a product team, why would such an exchange need to occur? Oftentimes we like to imagine product development operating like a smoothly-flowing river — requirements in, features out.
In reality, the most valuable features don’t flow smoothly through our Sprints or Kanban boards. They either get snagged as being more complex than initially imagined, or they resurface as bugs. In fact, these two causes are often interrelated. Particularly intransigent areas of a codebase can be both difficult to add new functionality to, as well as prone to regressions once the functionality has been added.
This is essentially a manifestation of technical debt as originally defined by Ward Cunningham:
To summarize, the original definition of technical debt was never about shipping poorly-written code that would later be “cleaned up”. It was about implementing a simplified a domain model based on a limited initial understanding.
To be clear, this is the right path to take in the beginning. As the product grows, these simplifications become over-simplifications, and software engineers start to get out of their depth when it comes to their understanding of the business domain. At this point, a SME is consulted. As the codebase is the source of truth when it comes to the currently-implemented domain model, strong-style pairing is therefore the most efficient and safest way to walk an SME through the domain model.
Wrap-up
Software engineering is more than just writing code. Consequently, it should involve more than just the coders. When modelling an especially complex business domain, it’s imperative to involve Subject Matter Experts (SMEs). If we take an Agile approach, our software products will outgrow their original, simplified domain models. They get replaced with more complex ones built in close collaboration with a SME who ensures that they’re modelled in the simplest and most elegant way for the set of use cases that satisfy the product’s customers.
This collaboration ensures that the models stay as simple and correct as appropriate, given the set of use cases that satisfy the customers’ needs. As new models emerge out of existing code, strong-style pairing is the most effective and risk-free strategy to take when collaborating with a SME.