malvasia bianca

(This is a lightly edited version of a post on an internal Sun mailing list on extreme programming).

I just finished reading the Quality Software Management series, by Gerald Weinberg (which I learned about from the XP bibliography), and I heartily recommend it to anybody interested in XP, or for that matter other agile practices. Or at least anybody interested in XP, interested in software management, and with enough free time to read 1500 pages, which I suppose isn’t quite the same thing.

One concrete benefit: it’s gotten me to think a little more about what I like about XP. So if people ask me why I like XP (which I imagine will be the case as I try to move my group further in that direction), I will now have a relatively crisp answer:

1. It puts a lot of emphasis on measurement and feedback (and it measures in in multiple ways).
2. It puts a lot of emphasis on quality (and it strives for quality in multiple ways).
3. People who have used it report favorably on their experience, in ways that I find convincing.

If I were then asked to elaborate, I would say, in regards to the first point, how testing, time estimates, small releases, continuous integration, customer feedback, and pair programming all come into play. And, as regards to point 2, I would talk about how it strives for quality measured by code that does what it is claims to do (as measured by tests), that does what the customer wants (as measured by the customer’s choices in stories to implement), and that is easy to modify (as evidenced by the ease with which XP teams implement new features), and how testing, pair programming, customer feedback, constant refactoring, and the 40-hour week all come into play in the search for quality. (And about how a traditional effort towards quality, namely people with bulgy brains thinking at the start of the project about the perfect way to do things and then telling peons to implement their vision, after which everything will be working perfectly, doesn’t come into play.) I might also refer to books like Weinberg’s that talk about why focusing on quality is a great idea even if you’re largely interested on getting your product out the door fast.

Another concrete benefit: it’s helped me think about my group’s hoped for (by me, if nobody else) adoption of XP, how it’s going so far, and what the next few steps should be. I’ll post on that later.

Here are some things that I found interesting in the books, with links to XP as appropriate:

• He presents a systems thinking / cybernetics approach to software management. This involves writing down diagrams with bubbles representing (more or less) quantifiable things you’re interested in, and arrows between bubbles saying how changing one of the quantities increases or decreases another one of the quantities. (Sometimes always increases, sometimes always decreases, sometimes can increase or decrease depending on the choice of the manager.)

  So, for example, if somebody thinks that writing pervasive unit tests will increase development time, you can imagine them as having two bubbles: “Number of unit tests written while coding” and “Time spent in coding”. And there’s an arrow from the first to the second, showing that if you increase the number of unit tests, you increase the coding time.

  But you can embed that diagram in another, larger diagram by adding two more bubbles: “Time spent finding and fixing bugs” and “Total development time”. And then you draw more arrows, saying that an increase in “Time spent in coding” increases “Total development time”, that “Time spent finding and fixing bugs” also increases “Total Development Time”, and that “Number of unit tests written while coding” decreases “Time spent finding and fixing bugs”.

  At this point, you still have the old path where increasing “Number of unit tests written while coding” increases “Total development time”, but you have another path by which “Number of unit tests written while coding” decreases “Total development time”, so it starts to become conceivable that unit tests really do speed up development, depending on which arrow’s effect is more powerful. (And then, of course, an XP proponent will be tempted to modify the diagram further, showing how unit tests allow you to change code more quickly, etc.)

  The nice thing about this from the XP point of view is that it gives you a good way to show how XP practices that initially look like they might be ineffective or even actively counterproductive turn out to be a good thing. I’ve given an example above; in general, you take a simple diagram that seems to show that a practice is bad (increasing “Pair programming” decreases “Keyboards in use at any given moment” decreases “Code written”) and embed it in a larger diagram (say, including “Code written per hour of keyboard use” or “Quality of code written”) to show how there are subtler, potentially more powerful effects justifying the practices.

  It could probably also be used to discuss how XP practices interact synergistically, so using all of them is much more powerful than you’d think by measuring the effectiveness of each individual practice.

• A lot of the diagrams that he draws end up showing how increasing quality in some sense or other, while having a short-term cost, has a huge long-term (and even medium-term, probably) gain. Which makes me happy, because I like long-term gains, but I also like doing the best job at anything that I can, so it’s nice for the two of them to be reconciled!

• He spends quite a lot of time on psychological issues. One big theme that he returns to is the notion of “congruent action”, having your actions reflect the environment that you’re in and your desired goals. Obviously part of congruent action involves making the right technical and logistic choices, but a huge part of it is realizing when your and other people’s psychological tendencies may be getting in the way of congruent action, and figuring out what to do about it.

  He talks about several different psychological classifications which I found interesting. One particularly useful notion is that of blaming and placating stances. We all know about blaming stances, where, say, a manager blames a programmer for not getting a piece of software written in time for a deadline. But the flip side, the placating stance, is probably just as harmful but much less noticed, where, for example, somebody gives into outside pressure to accept a schedule that she knows is unreasonable. I think that being aware of these two stances (as well as some other stances that Weinberg discusses) will help me a lot.

• He helps me puts XP into a much broader context. He borrows on others’ work to classify software development cultures as “Oblivious”, “Variable”, “Routine”, “Steering”, “Anticipating”, or “Congruent”. (Where the latter cultures are more desirable, where Congruent cultures are currently mythical, and Anticipating cultures are currently extremely rare, and where almost all software shops are Variable or Routine.)

  If I wanted to lift a random software shop from Variable or Routine into Steering, XP is as good a way as I can think of to do it. It’s by no means the only way, but I think it’s a good way, in situations where XP is applicable.

  Also, we don’t support XP as an end to itself; we support XP because it helps us meet certain goals. And Weinberg’s notion of a Steering culture provides a good way to think about what goals might be desirable (hinted at in my list above of why I’m attracted to XP); so, if you find yourself in a situation where XP doesn’t seem to quite fit or there’s some resistance to XP, you can adopt the broader goal of changing your culture to a Steering culture, by taking some pieces of XP but by incorporating other ideas as better fits your culture.

  Once you’ve got all the XP practices, it can help you ask what to do next: think about turning your culture into an Anticipating culture. The truth is, if you’re really doing XP well, you’re probably a long way towards being an Anticipating culture, but there will be ways that you’ll want to improve your organization as a whole that are somewhat outside of the scope of XP. And, if you don’t adopt an actively Anticipating stance, you’re probably in danger of having XP rigidify, and of missing new ideas and ways in which you could improve your culture still further.