Bio
Gien Verschatse, a software developer with 10 years of experience, mainly in a .NET environment, who likes to start her day with coffee.
She specialises in bridging the gap between users and developers by practicing domain driven design. Besides that
she loves to learn how teams can improve the way they make decisions both on a technical and organisational level.
She is a strong believer of continuously learning by deliberate practice and knowledge sharing,
which is why she dedicates a lot of her free time speaking at conferences or user groups.
She also helps to organise an F# conference in the US, Open FSharp.
When she is not busy with all of the above, you will find her on the sofa, reading a book (yes, with coffee).
When To Move From Collaborative Modelling to Coding?
(Lab)
by
Kenny Baas-Schwegler, Gien Verschatse, Evelyn Van Kelle
Managing polarities in software design and engineering.
When can we actually start coding? How do you know when you have done enough collaborative modelling? How can we make our architecture and design really iterative?
Domain-driven design puts a huge focus on collaborative modelling to build a shared understanding of your domain and we use a lot of tools like EventStorming, Example Mapping, Whiteboard sessions and Responsibility mapping to get to that shared understanding. But when it comes to questions like “when do we start coding?’, and “How much collaborative modelling is needed?”, it is often difficult to find a good answer or the answer you receive is “it depends”.
The reason that it is so difficult to answer those questions is because we are looking at these questions in the wrong way. We look at them like a problem we need to solve, instead of what it actually is: a polarisation that needs to be managed. If we don't learn how to recognize and manage polarities, we will make compromises or stay on one side of the polarity and experience the downside of both. To identify and manage polarities, we need to discuss and start using polarity mapping.
In this session, we will interactively introduce you to polarity thinking. We will explore how to identify polarities and how to manage them with Barry Johnson Polarity Mapping. We will explore too much vs too little upfront design, by filling in the polarity map together, we show you the power of visualisation to manage the polarity. We will go from either-or thinking to both-and thinking, and this way include the entire team in managing that polarity. You will leave the session knowing when to go from collaborative modelling to coding and fill in the polarity map with your team the next day!