Bytesize Architecture Sessions

The more you do something, the better you get at it. It applies to software architecture too. How to do it more often?

People new to a codebase and those less experienced with programming generally have incomplete or incorrect mental models about the codebase. One would expect that as time passes, the mental models should become correct, how about being more deliberate about it?

Here is an easy to try option: Run a Bytesize architecture session:

• An hour long recurrent meeting with your team. Bi-weekly at the start and you can phase it to once a month as people run out of things to draw.
• Decide together a subset of the architecture you want to draw. This is not a test, it’s an opportunity to learn together about what you know and, most importantly, what you don’t know.
• Set a timer for 5 minutes.
• Separately, everyone draws in a piece of paper, this is “Alone Together” time. If you don’t know something, leave it blank.
• When the timer goes off show each other what you drew. Yes, it’s kind of scary.
• Discuss and find consensus on what is the resulting diagram should be. Finally record the diagram(s) created somewhere (e.g: draw.io, miro, plantuml, etc)

It is normal to forget some parts. Together you can make a better picture.

Outcomes

• Understanding of whatever you decided to focus on the session will increase. Now you have concrete questions, and generally you can find the answers in the code.
• Deliberately thinking about architecture with a cadence keeps the ideas fresh in people’s mind.
• The resulting diagrams become a design tool that is inherently familiar to the team, since they created it.
• The resulting diagrams highlight obvious areas for improvement.

What do you need to run a session

• Cup of tea / coffee / water
• 1 hour with your team
• pen and paper or an online board
• Psychological safety (essential)

What is this practise trying to address

• In most teams there is at least one person that has a high fidelity image of the architecture in their heads. It is common for other people in the team to defer questions and decisions about the architecture to that person, this is great (is it tho?) until that person is not available.
• If everyone in the team has the same or similar picture of the architecture in their heads, they will make better decisions on their day to day.
• I have tried this for a few years and it has proven super useful. Teams are happy to build this together and get a feeling of ownership.