Global Day of Coderetreat

A day of deliberate practice and learning.

📆 Saturday, 2022-11-05
☑️ Mandatory registration
🧩 More details next slide

Looking forward to seeing you soon!


The Vienna software crafting community invites you to participate in our local event for the Global Day of Coderetreat.

On this day, we come together to learn from each other, practice pair programming & test-driven development and focus on design aspects related to decoupling.

If that sounds interesting to you, we are thrilled to have you join us!

Global Day of Coderetreat

Welcome to a day of deliberate practice and learning!

🛒🧾🛍️       💡🤝🤓       🪢✂️🧵

Which Language? 💬

Spricht jemand nur Deutsch? Bitte melden.

Does anyone speak only English? Please report.

Big Thank you to Nagarro! 💗

Thank you very much for hosting us!

Dinner 🍽️

Who wants to join dinner?

Please raise your hand.

Is this your first Coderetreat? 🥇

Please raise your hand.

What is a Coderetreat? 🤔

A day of deliberate practice and learning.

Deliberate Practice and Learning?

  • Not about getting things done
  • Doing things differently
  • Try out new ideas
  • Do it right!

How does it work?

  • We work on the same problem repeatedly.
  • Try out different approaches.
  • Learn from each other.

Practice - reflect - improve! 🥳

Schedule 🕤

Time Topic
08:20 Arrival & Breakfast
09:00 Welcome at Nagarro
09:10 Intro Coderetreat 👈
Session 1 by Peter Kofler
Session 2 by Patrick Scheibert & Katrin Heiderer
Session 3 by Adam Zielinski
13:10 Lunch Break
Session 4 by Claus Aichinger
Session 5 by Roland Germ
Final Retrospective
17:00 Closing

About us 👋

Facilitators in order of appearance.

What about you? 💐

Let’s get to know each other:

  • Who are you?
  • Why is it better to be here than elsewhere?
  • What will you contribute?

Form groups of three (with people you don’t know).

Code of Conduct 🤝

Be mindful of your peers.

Be respectful.


Today’s Practice 🥷

Supermarket Receipt 🛒🧾🛍️

For a collection of items in the shopping cart

  1. look up prices,
  2. apply discounts,
  3. compute total and
  4. generate receipt.

More about the assignment in the first session.

Pair Programming 🤝


  • 🧭 Navigator Giving directions, looking ahead
  • 🚗 Driver Manipulating the code, concerned with small details


  • Talk to each other
  • Switch roles every 5 minutes

Refactoring 🔧

  • Improve code but don’t change behavior

  • Don’t break interfaces

Test-driven Development 🧪

  • If you write new code, write a test first

  • If you change code, is it covered by tests?

Decoupled Design 🤔

What is design?

Why does it matter?

Today’s practice: strategies to decouple design!

How do we get there? 🤓

  • Revisit same problem repeatedly

  • Try different strategies to improve design


Session 1

Focus: Familiarize yourself with the problem.

Facilitator: Peter Kofler @codecopkofler

Our Kata: Supermarket Pricing

Pricing goods at supermarkets

  • The supermarket has a catalogue with different products (rice, apples, etc.).
  • Each product has a price.
    • Item Products have simple prices. E.g. a can of beans costs €1.65.
    • Loose Weight Products have more complex prices. E.g. €1.99 per kilo.
  • The total price of the shopping cart is the sum of all the prices of the items.
  • Your receipt lists the items you’ve bought, the total price and discounts.
  • The supermarket runs special deals like
    • Percent discount on item, e.g. 10% discount on rice, normal price €2.49 per bag. 20% discount on apples, normal price €1.99 per kilo.
    • Buy two toothbrushes, get one free. Normal toothbrush is €0.99.
    • X for Y discount, e.g. Five tubes of toothpaste for €7.49, normal price €1.79. Two boxes of cherry tomatoes for €0.99, normal price €0.69 per box.

Our Mode of Work: Pen and Paper

Before we start coding, let’s think:

  • Identify concepts.
  • How would we design such a system?
  • Maybe do a verb-noun analysis.
  • Make a sketch.
  • Which actions/events are there?
  • Be explicit.

Only work on requirements listed above!

Extra Challenge: Decoupled Design

  • Do we need to get data from somewhere?
  • Do we need to write/print/format data somewhere?
  • Which “concerns” are there? (If concern means anything to you.)
  • Which domains/subdomains are involved? (If domain means anything to you.)

Find a Partner! 👀

Deliberate Practice and Learning 🤓

Retrospective 🤔

  • Which parts are “different”?
  • Which components did you identify?
  • Are Stock and Shop the same domain? No? How do we handle it?

Enjoy the Break ☕

And be back in time.

Session 2

Focus: Familiarize yourself with the code (and face reality).

Facilitator: Patrick Scheibert, Katrin Heiderer

Existing Code :-(

The code is there, we want to improve it.

Code Review, Refactoring, Pair-Programming

  • Read the code (“read by refactoring”)
  • Which design elements (aka classes) are there?
  • How are they connected? Which classes hold which data?
  • Which classes are doing what?
  • Compare with your diagrams from session 1.


  • Start with small IDE refactoring steps.
  • Rename the variables so they are more meaningful.
  • Extract methods to reduce complexity of the code.

Extra Challenges

One Level of Indentation

Each method cannot contain statements that require more than one level of indentation (conditional statements, loops, etc)

Short Methods

Limit the number of statements permitted for a function to 5 lines.

Find a Partner! 👀

Deliberate Practice and Learning 🤓

Retrospective 🤔

  • “I agree / Don’t agree”

Retrospective 🤔

  • Which refactorings did you do?

  • Which class or method names did you change?

  • What was your experience in the pairs with different languages?

Enjoy the Break ☕

And be back in time.

Session 3

Focus: Separation of concerns

Facilitator: Adam Zielinski @adam0x5A

Separation of concerns - Why? 🤔

“the only available technique for effective ordering of one’s thoughts, that I know of” (Dijkstra, 1974)

Reduce complex problems into a series of manageable layers and components.

More degrees of freedom (to introduce changes, reuse, deployment, …)

Separation of concerns - Design to make our life easier! 🥳

Reduce Coupling: Separate things that are different into separate classes.

Coupling is measured by the number of relations between the classes. That is, the coupling increases as the number of calls between classes increase or the amount of shared data is large.

Improve Cohesion: Put things that do the same thing together.

Functional, Sequential, Communicational, Procedural, Temporal, Logical, …

Separation of concerns - How? ⚙️

Identify “who is responsible for what?”


  • Clarify responsibilities between Teller and ShoppingCart.
  • Separate view, formatting and logic.
  • What about Law of Demeter violations in ReceiptPrinter? (“only talk to friends”)

Extra Challenges

Use only keyboard shortcuts, no mouse 🐭

for navigation and refactoring

Visualize 📦

Visualize the coupling (e.g. Control / Data Coupling)

Find a Partner! 👀

Deliberate Practice and Learning 🤓

Retrospective 🤔

  • Which concerns could you identify?
  • Have you introduced Abstract Data Types (Interfaces)? If so, which?
  • How many tests would you have to alter?
  • Could you visualize the coupling of classes?

Enjoy Your Lunch! 🥗🌽🥬🥟🍛🧆

Session 4

Focus: Improve class design by applying principles

Facilitator: Claus Aichinger @clausaichinger

Requirements Change :-/

Feature requests:

  • Introduce special deals database
  • Support HTML receipts
  • Allow discounted bundles

What now? 🪢👀

Yes, decouplings sounds good. But… 🤔

How? 🤷

Apply principles!? 🪢✂️🧵

I’m not a great programmer; I’m just a good programmer with great habits.

Kent Beck in Refactoring: Improving the Design of Existing Code

Yes! Improve Class Design

Apply so called SOLID principles:

The Single Responsibility Principle (SRP)

A class should have one, and only one, reason to change.


A module [class] should be responsible to one, and only one, actor.

The Open Closed Principle (OCP)

You should be able to extend a classes behavior, without modifying it.

The Liskov Substitution Principle (LSP)

Derived classes must be substitutable for their base classes.

The Interface Segregation Principle (ISP)

Make fine grained interfaces that are client specific.

The Dependency Inversion Principle (DIP)

Depend on abstractions, not on concretions.

What does it mean? 🧐

For example:

  • SRP: Split up
  • OCP: Inject collaborators (dependencies) in constructor
  • DIP: Express collaborators through interfaces
  • ISP: Provide different interface depending on usage

Decouple using SOLID 🧩

And pave the way for new features…

Suggestion: SRP and ShoppingCart

Relates to previous session.

Suggestion: SRP and ShoppingCart.handleOffers()

Relates to feature request.

Suggestion: OCP & DIP and SupermarketCatalog

Relates to feature request.

Suggestion: OCP and ReceiptPrinter

Relates to feature request.

Find a Partner! 👀

Deliberate Practice and Learning 🤓

Retrospective 🤔

  • Did you focus on a feature? Which?
  • Did you focus on a class? Which?
  • Which SOLID principle did you apply?
  • How did “apply principle” influence your development?

Enjoy the Break ☕

And be back in time.

Session 5

Focus: Separating a Domain into Bounded Contexts

Facilitator: Roland Germ @rolgerm

Decoupling into functional Areas

  • Which grouping of the domain did you identify in the 1st session today?
  • How should we split a domain in functional areas?

Domain and Bounded Contexts

  • A Domain consists the whole model
  • Large models are divided into subdomains or bounded contexts driven by separating business needs
  • A bounded context is a projection of the problem space into the solution space
  • Code that combines two bounded contexts gets convoluted because it’s mixing two separate vocabularies together (“Martin Fowler”).

Bounded Contexts of the Supermarket Domain

Anti-Corruption-Layer - a clear boundary between bounded contexts

The journey from direct dependencies

To dependency inversion


Multiple Anti-Corruption-Layer building a Hexagonal Architecture


  • Start by creating directories for the separate domains.
  • Decide which code belongs to a domain and move it to the right location (this includes moving methods/functions)
  • Create your anti-corruption-layers between the domains (start with the simplest).

Extra Challenge: Don’t share the Product between domains

The Product is somehow a shared model. But in future the Product could be enhanced and each domain needs its own view or selected data of a Product.

  • What is needed to identify a product in a domain?
  • Which domain does the Printer belong to?

Find a Partner! 👀

Deliberate Practice and Learning 🤓

Retrospective 🤔

  • Which domains did you create ?
  • Which dependencies do you have finally?
  • How did name the name the ports and adapters?
  • What constructs hindered you?
  • What do we achieve by applying a hexagonal architecture

Our retreat is coming to an end…

Final Retrospective 😉

  • What did you learn?
  • What did you enjoy?
  • What did surprise you?
  • What do you take away?

Global Day of Coderetreat

A day of deliberate practice and learning!

🛒🧾🛍️       💡🤝🤓       🪢✂️🧵      🥳

Thank you for joining! Your feedback is greatly appreciated.