Project Lionheart: The Story So Far…

Development has started, though things got off to a rocky start. The team chose to go with conventional tiers pattern for the runtime structures and layers for the code, but there are still many decisions to make. Many team members use different words to describe the same elements in the architecture. As a result, our design discussions end with everyone nodding heads in agreement only to learn later that each person took away a different conclusion.

The code is already a wreck. It reflects the team’s lack of understanding of the design decisions made so far. The patterns you thought the team selected for the architecture are nowhere to be found within the system.

After realizing the problems, you call an impromptu whiteboard jam (described) in an attempt to build consensus around the design decisions and extract a common meta-model. During the whiteboard jam, you encourage teammates to describe the system precisely. Eventually, we settle on some good names for the concepts, elements, and relations in the models. After the meeting, you formalize the team’s conclusions by capturing the meta-model in our wiki.

Now that we have a common meta-model, it’s time to refactor the code so that it matches the models we want. Knowing that pair programming is an excellent opportunity to teach architectural principles, you pair with teammates as you fix structures in the code. Luckily it is still early in the system’s life, so the refactoring is straightforward.

As you pair with different teammates, you learn that not everyone agrees with or understands the current architecture. Before we get much further along, you decide it would be wise to explore our architecture options in a collaborative workshop.