Design & Development Principles - XP - Quality Circle - Part 2

This is the second post of the Quality Circle.

As a reminder; CIRCLES!

This post is going to talk about the Green Circle.

Another reminder is the tight interconnection between all of the components.

Quality Circle

The quality circle is what is what I consider the aspects of the day to day development that drive the code quality to where it should be. These are the prime practices.

  • Coding Standard
  • Collective Ownership
  • Continuous Integration
  • Sustainable Pace
  • System Metaphor

In this post, we'll cover the last three practices

Continuous Integration

Continuous integration is constantly integrating change into your work. If Git's being used; then push/pull often.
An advantage of mob programming and having a single Work In Progress (WIP); there's CONSTANT continuous integration. It's the continuous integration of ideas instead of the frequent integration of ideas. At large scale, multiple mobs, then you'll still be doing Continuous Integration. Push your changes, pull their changes. Who ever has the merge issue needs to resolve. The more frequent you do the push/pull the less issues will arise. The big advantage of mobbing in this is that you'll very unfrequently get multiple mobs working in code close enough to cause a conflict. If there is; maybe the mobs should coordinate, collaborate, and work together while working in the same space...

The usefulness of continuous integration is that you'll avoid merge hell. Days lost trying to merge work from multiple branches. Accidently choosing the wrong section; or losing work. Then tests fail; or worse... they pass.
Merge conflicts are a chance for bugs to get into the system. Avoid this; avoid the bugs.

One of the things I've found to be a major factor arising to merge hell is crunch mode. Having to work late, or rushing through the work to just "get it done". This causes less frequent integrations, as you're prone to get hyper focused on your task... Leading to merge hell.

Sustainable Pace

To avoid the pitfalls that come with trying to "get it done" - work at a sustainable pace. The need for late nights or crunch mode is a failure of management. The project, people, timeline, scope, ect wasn't managed correctly and is trying to be fixed by making people work more - which often introduces more issues into the code base... slowing it down even more.

Working at a sustainable pace is the best way to get a product out the door. I'm sure we'll all agree to this; including management; and yet - We've all probably experienced having to work late nights to get things done.
Sometimes there are deadlines that need to be met; but that effort is rarely met by additional time to clean up the debt.

Working a team for higher output today is going to kill output tomorrow. The mess from today will either need to be cleaned up; or it'll continue to fester and rot the code base making future work go slower and slower until... "rewriting it will be faster". That's the state you want to avoid; and it comes from working at a sustainable pace. A sustainable pace is tightly coupled with all of the Keyboard Circle working habits. If you're not working a sustainable pace; then those are going to go away. Once they are going away, the code base starts to rot. If you don't resolve this rot; it festers and spreads... Without proper maintenance, which can't be done if it's not a sustainable pace... the code becomes fragile and unwieldy. The team will stop wanting to work in it. Once a team is uncomfortable working with code - it never really improves. It might be patched and something stuck on; but it isn't quality... It shows, and it starts to demoralize the team...

System Metaphor

One of the big reason I've gone through some renaming on the (mostly-)UI Pattern, the Hotel Pattern, is to support an effective metaphor. This helps understanding of what the components do; understanding of what the project does.
The better naming you can do; the easier it is to grasp what's going on. It's why we name variables in a way that relates to what information they hold - Understandability. Metaphors are not always easy to come up with. There should be no expectation of perfection; but pick one that works; run with it. As the system is developed and used; if a better metaphor shows up; use it. Without really knowing the system and how it's being used; metaphors are not always obvious. With familiarity and experience, better names show up. The Hotel Pattern started out named for each of the layers; and it required a lot of explanation. The new style requires a comment to explain why that name, and it makes sense. Even if there's a lot more to it; it makes enough sense that the system/module implementing it can make better sense to someone being introduced to the code.

This is what can help with the Ruthless Refactoring. Like metaphors might be able to produce an abstraction. Metaphors help drive coding standard naming; it's one tightly coupled set of practices.


The Quality Circle of the XP Design and Development principles are very tightly coupled with the Keyboard practices. You can't really have one without the other. These are not practices that succeed in isolation. They support each other. Not always making one easier; but making it harder to slip and not be as diligent about doing them.
Working at a sustainable pace allows all the keyboard aspects to be done. There's no impending rush that would pressure a team to not do some.
Continuous Integration drives coding standards so it's easier to see how things should be merged; and prevents ruthless refactoring from becoming merge hell.
The System metaphor helps drive similarities to enable more ruthless refactoring. Metaphors simplify sharing the knowledge during pair+ programming.
Collective Ownership enables everyone to do anything day to day and prevents blockers for progress.
Coding standards ensure we're all writing code the same to prevent churn and mental hops required when the code changes form.

All of the Quality Circle practices support, encourage, and make it more difficult to not do the Keyboard Circle practices. The Keyboard Circle in turn; support and promote the Quality Circle as ways to ensure a healthy product.

The very tight coupling of these practices is what allows XP to be an excellent system for the quick production of quality software.

Quinn Gil

Quinn Gil

Seattle Code Crafter. Quinn beats the drum of FAST Agile, Extreme Programming and Object Oriented Design through MicroObjects. He blogs for fun and frustration of exploring new concepts.

Read More
Design & Development Principles - XP - Quality Circle - Part 2
Share this