Turn All The Knobs To Seven

ExtremeProgramming originated when KentBeck decided to "turn all the knobs to ten" for the development practices he knew to be effective. However, it is acknowledged that XP has certain limitations -- for example, it is really optimized for small teams.

I think that XP's currently acknowledged limitations are pretty severe, making it useless for a large percentage, maybe even most, projects. However, I think XP is also chock full of good ideas, so it seems to me that they must be applicable in other contexts.

One way XP might be modified to work in an XP-unfriendly environment is turn TurnAllTheKnobsToSeven. XP people will most likely claim that even if this works it won't work anywhere near as well as turning the knobs all the way up, so what would be the point? One reason this might be useful is that it might be more robust in the face of external pressures that the development team can't control. In all fairness, it might just not work at all. However, I'd like to see some thoughtful discussion about how XP might be modified to deal with problems outside its current domain. I certainly don't mean to restrict the discussion to just what happens if we TurnAllTheKnobsToSeven (that was just the best topic name I could think of since AlmostExtremeProgramming is already taken).

-- CurtisBartley

The title of this page got me to thinking about an acquaintance who used to be in a Rock band that played the occasional gig in New York City. He told me that when they set up, they always turned all the amplifier knobs all the way up. It struck me at the time that there's something wrong with that, not because it's too loud (which it would be for me) but because it's an indication of limited choices. Something in the mentality said that "extreme" is more valuable than "balanced", a concept that doesn't fit for me.

It is likely that in an instrument amplifier, the equalizer ties up a considerable fraction of the knobs and turning them all up means that none of the bands are cut, so the eq doesn't interfere. Naturally volume is adjusted in the P.A. after DI or micing. Depending on the gear, turning that up may or may not be a good sound. I do agree that running out of scale means there was not enough room for adjustment.

I realize that "turning all the knobs up to ten" is just a metaphor for taking certain practices further than usually done. Nonetheless, the title above has slightly more appeal for me when I'm in the mood to do careful and thoughtful work (not when I'm in the mood for recklessness). More and more, I like to do my software work carefully and thoughtfully. (And by the way, for some reason, seven is exactly the right number for me, but I can't tell you why.) (SevenPlusOrMinusTwo, perhaps?)

Incidentally, rotary-style level knobs on audio gear commonly have zero-gain at 2 o'clock, which is the 7th position up from zero. That dedicates 70% of the scale for the range from nothing to full volume, and 30% to "head room" for when you need an extra boost.

When you've turned the knobs up to seven, you're still free to adjust any knob up or down, which is a freedom (at least metaphorically) lost when you peg out completely. This may be just poetry, but something deep inside me says that most of the time, it's better to save something in reserve. Steering means being able to adjust in more than one direction. For what it's worth... --WaldenMathews

Clarification: I'm not implying that ExtremeProgramming keeps nothing in reserve; I'm just diddling with the imagery here. -WM

That's why smart people get an amplifier where each knob GoesToEleven.

I suggested that the dials go way beyond ten. Someone suggested that I didn't know what was being talked about. My advice is to think about whether the XP dials are about more or whether they are perhaps about something different. But maybe I don't know what's being talked about. --RonJeffries

But isn't the story that Kent Beck decided to take certain good practices and "turn the knobs all the way up to ten"? If that's the case, then it is about more with respect to those particular knobs. Doing better than before may be the outcome, but as I understand it, there's no direct way to turn that "knob" up. Maybe you could expand a bit on "something different", above. --WaldenMathews

OK. What are the dials? Seems to me that he went on with things like "if code reviews are good, we'll review the code all the time - pair programming." So perhaps the dials are the practices, since pair programming is one. Then is "all production code is written by two people at the same machine," the ten-spot on the dial, or does the dial go further. (I'm not thinking that it goes to three people, or that it goes to non-production code, though I suppose it might.)

Is it the "code review" dial and not the pair programming dial? Then what is beyond pair programming in the code review realm?

So what are the XP dials, and are they really up to ten? --RonJeffries

The example of pair programming seems like a good one. Reviewing all the time by working always in pairs may maximize the time spent together by those two people, but does it necessarily maximize the attention to finding mistakes? Is it possible to optimize both flow and caution at the same time? Relaxing the rule about how production code is written might better allow those same two people to optimize either flow or caution, based on their judgment of the situation. That would be an example of turning the knob to seven. They have room on either side to adjust. "Seven" is a number that says "this is important, but use your own judgment how important case by case". "Ten" is good promotion, but methodologically it seems like dogma -- WaterFall revisited, if you will (I won't!). --WaldenMathews

Well, it can hardly be optimal to take the extreme approach to anything.

Disagree... the optimal way to get press coverage is to be extreme. That includes the ski slopes as well as politics.

I have heard discussion of XP's "limitations" that suggest you might need to do more - more documentation, more planning, more QA. I've never heard anyone suggest that its limitations would cause you to need to do less testing, less communication, less planning, etc. What limitation of XP would cause you to want to do less than it suggests? Thanks. --AnonymousDonor

I'm not sure I understand the question. What I'm suggesting when I say turn the knobs to "seven" is that you have a methodology that looks a little more conventional. In some cases this might mean doing more and in other cases less than what XP requires, depending on which way "the knobs go". For example, you might want more documentation, more upfront planning, and less unit-testing. Here are some reasons why this might work better for a particular project than pure XP would:

More Documentation

You have a geographically dispersed team. You can't rely on face-to-face communication and pair programming to communicate how the system works. However, maintaining documentation is still expensive, so you are careful about what artifacts you are creating, and you don't try to keep them up-to-date if you don't need to.

More Planning

You have done this kind of application before. You don't need fancy UML diagrams or stacks of detailed requirement documents, but you can plan the architecture in some detail because you know what you needed in the past. You do not have to get it exactly right, though, because it's relatively cheap to make minor changes to the initial design.

Less Unit-Testing

The application is UI heavy which is hard to unit test -- and you have a dedicated QA team to thoroughly test the UI anyway. Only limited unit testing for the underlying model is really necessary, and full coverage is not a requirement, because the aggressive UI testing planned for the end of the project will give you good code coverage of the underlying model as well.

-- CB

These are interesting ideas, and help clarify the "Seven" notion. Thanks. Some questions: On "more planning", which I think maybe means more design in the XP sense, since planning is the release and iteration planning "game" process, would that really be MORE planning, and if so how is the dial at seven? You're right that what I referred to as "Planning" is actually "Design". I'm not sure it's a good example anyway, maybe because I'm actually used to doing less design than XP recommends. Anyone have any suggestions for making it a better example?

I can see that "More Documentation" is "Less Communication", sort of, and "Less Unit Testing" is certainly less.

Good examples. Thanks!

I don't quite understand the More Documentation part for the geographic dispersion example. Wouldn't you still want More Communication (i.e. more phone calls, more video conferences, etc.) or like RonCrocker's example, More Modularity so that you can live with Less Communication? I guess you may need more UpFrontDesign to get More Modularity but I'm not sure that's captured accurately by "More Documentation".

Here's another example

In XP the customer makes the decision about what features go into each release. An alternative would be that the iterative approach is retained, but during early iterations -- say the first half of the project -- the development team makes those decisions based on the initial requirements and expediency. During the second half of the full product cycle the customer becomes more involved in making decisions about what goes in and what's left out.

-- CB

The point you seem to be making is that by taking all development 'practices' to the extreme, you are in fact making the software development process less agile because there is less contingency for external constraints on the way we work.

Your examples are very common ones. Let me add the increasingly common scenario that the whole development team resides in a different country/culture to the customer. I'm thinking of development that is outsourced to countries like India or China. There are good commercial reasons to do this, but it breaks the ExtremeValues.

My question is "What exactly do I do when I can't (for reasons outside my control) do XP? Is seven high enough, or will it just result in a half-baked project?"

-- ColinCassidy

However, I'd like to see some thoughtful discussion about how XP might be modified to deal with problems outside its current domain.

At least some of the currently acknowledged XP limitations are about what hasn't been tried yet, as opposed to what has been tried and that failed.

Here is my thoughtful discussion: You can experiment a little with more paperwork, and more planning, but whatever you do, please, please don't take away my fixed time intervals, my refactoring, or my unit tests, or I, for one, won't work for you.

In other words, I don't mind working on a possibly-slower-than-need-be project, but I do mind working on a project that I worry might not succeed.

This is what I'm trying... not sure whether to put it here or in XpLite :-)

One of my requirements is that most personnel, specially the seniors, must be in 2 or 3 projects at the same time. We know it is sub-optimal but we don't have enough senior staff to avoid that yet.

ProgrammerTest like XP (full coverage, always 100% pass, what is not tested should be removed) and TestFirstProgramming
No automated CustomerTest
PlanningGame for new projects when we can sell it; otherwise, do it internally with one management person representing the customer, maybe consulting over phone.
OnSiteCustomer is still a pipe dream :-( but one person internally (not a dev) represents the customer at all times
No BigDesignUpFront - but since we usually don't have either of the two above, we therefore need written specifications. We try to avoid thinking of these as a design, however ;-)
PairProgramming for all production code on new projects; only for stumbling blocks for projects that are already on the way (I would prefer to enforce full PairProgramming, but it's a major cultural shift to get trough)
ContinuousIntegration using a RevisionControlSystem (GnuArch for us)
DesignImprovement / RefactorMercilessly
We do write comments in the code, but we consider them a smell for potential refactoring. Or in some places we need them because the calls into the framework (which is not under our control) are a bit ugly.
SmallReleases
SimpleDesign
No SystemMetaphor - my team can't grasp the concept (yet). Or maybe our framework is already well metaphorized enough that we can survive without this?
CollectiveCodeOwnership
CodingStandard
SustainablePace usually, but if we have a bad deadline, we can pull all-nighters or work on weekends or whatever. We call this "the nightmare run". But after a nightmare run, everyone in the team gets a number of days off to get back to a SustainablePace rhythm.

So is this TurnAllTheKnobsToSeven or XpLite, or is it more like PrettyAdventuresomeProgramming?

-- LaloMartins

CategoryExtremeProgramming