Seek concrete examples to deepen problem understanding: Lessons from Eric Evans (Part 2)
The most emphasised heuristic from Eric Evans' Software Design masterclass
This is the second part of my previous essay about what I’ve learnt in Eric Evans’ Software Design Masterclass. The full context can be found in the first essay.
In software design, a deeper understanding of a problem is important. Gaining that deep understanding will also need to be efficient, as domain experts are typically busy. Through my experience in Eric Evans’ Software Design Masterclass, I learned a small yet impactful step to gain a deeper understanding more efficiently.
During a conversation with a fellow attendee at the DDD Europe 2024 conference, I shared this significant insight about concrete examples. “Well, that’s pretty obvious isn’t it?”, they responded, highlighting a misconception I believe needs addressing.
If this technique was truly obvious, Eric wouldn’t have felt the need to emphasize it repeatedly throughout the two-day course. His constant reiteration reveals how deeply this idea is engrained in his head as a heuristic. It’s so pervasive that I noticed he repeated the phrase ‘concrete example’ in his unrelated closing conference talk, which was about LLM and DDD.
The effectiveness of a concrete example became clear during our exercise. Consider a simplified snippet of the interview we did with Gien Verschatse, who acted as a domain expert in the class:
Eric: “Alright, class, remember, ask for concrete examples.”
Gien: “The problem is the fridge shows an error when I scan my plate.”
Class: “How does the fridge operate?”
Gien: <Long irrelevant explanation>
Class: “How does the barcode look? Is it a QR code?”
Gien: <Long irrelevant explanation>
Eric stepped in, “Could you walk us through a concrete example of when this problem happened?” Suddenly we were getting a great detail of what the problem is. I could notice the class were having a lightbulb moment, we understood the problem deeper now that we could come up with a better solution.
The first part of the phrase ‘concrete example’ is the word ‘concrete’. The word concrete implies a real-world example, not a hypothetical or abstract one. While abstract examples can enhance our understanding, a concrete example keeps a discussion more grounded in reality, therefore we’ll be more confident that we’re solving the right problem.
The second part of the phrase is the word ‘example’. In my opinion, this word requires more emphasis given none of the class participants asked for any form of examples in the exercise.
Explain, example, extrapolate, all these words share the same prefix Latin root that implies “out of” or “from”, to mean a process to bring something to light, to make something clear. Giving an example is a process of making something clearer by representing a single item from a larger whole to illustrate a point.
On reflection, I realised how obvious it feels to explain concepts using examples, yet how non-obvious it often is to ask for them. I found it easier to help my eight-year-old daughter understand the concept of inertia through examples. In the London Underground, I would point out her experience when the train is about to move or about to stop, as an example of inertia, providing a concrete point of reference to a more abstract concept. Examples helped her gain that understanding.
Building on this, let’s consider the word ‘dog’. Imagine how you would explain this abstract concept to a child, without examples, it would have been challenging. Examples are fundamental to our knowledge acquisition process. My daughter’s understanding of dogs expanded through a series of examples and counterexamples, such as mistaking a cat for a dog.
While it may seem unintuitive to ask for concrete examples initially, integrating this practice has proven valuable, even when I felt that I understood a particular problem. For instance, in a recent conversation with our team:
Product Manager: “I’d like a single analytics dashboard, so I don’t have to look to multiple places to analyse our customer conversion.”
Team: “We’re going to need to adopt a data platform. We’re worried about the associated cost.”
Product Manager: “I think we need to invest in a data platform, it’ll allow us to collect and gather more data in the future.”
Team: <Long discussion and conversation>
Notice how even though we were discussing a problem, the problem was not concrete enough. This is exactly what happened in Eric’s class. The team were trapped in the discussion that didn’t deepen our understanding.
I asked for a concrete example, “Could you show us, share your screen, what is it that you’re doing, and found painful?” Upon seeing the real-life demonstration, the team immediately had a clearer understanding of the problem. We also started to think like a designer, we dug deeper into the pain points. We ask, how often does our Product Manager need to do this?
At the end of the discussion, we thought a simpler solution would work so long as we make it evolvable. Better yet, we thought the problem wasn’t painful enough for now we deferred from solving it.
Ultimately, grounding our understanding of problems through concrete examples anchors our discussions in reality. This technique proved invaluable in efficiently comprehending a problem.
If enjoyed this post, you might enjoy these other DDD posts and my deeper thoughts about the intuitiveness of TDD.
The Unspoken Secrets of DDD: Lessons from Eric Evans
Like any other practices or techniques I learned, I’d like to validate my understanding against the source of truth, and I can’t get closer to the source of truth than attending Eric Evans’ class, a pre-conference workshop in DDD Europe 2024. It’ll be an opportunity to observe the original author of the big blue book, the man himself, operate in real li…
Why Explore DDD
Imagine that you’re designing a REST API that returns a date. Knowing that dates are not a primitive type, you must decide how to represent the date in a string. You came up with these options: Use ISO 8601: 2020-01-12 Create a custom date format: 20201201
TDD Made Intuitive: Spec-First Thinking
Welcome to the latest issue of my newsletter series, ‘Test First vs Last’, where we’ll explore how the sequence of writing tests affects our minds. The full context of this series can be found in the introduction post.
It seems like all learning somehow builds off of existing knowledge. When you are learning something new and don't understand it yet, you have this abstract concept floating around in your brain but it's not connected to any existing scaffolding.
I wonder if a concrete example is something that tries to locate existing scaffolding in your brain so that the concept can latch on a point. The "aha" moment.
The more examples, the more points where the idea can hook into existing scaffolding and the abstraction or concept becomes stronger.
We need high quality training data for our neural nets!