Extreme Rules

This my presentation of the ExtremeRules, as originally presented by DonWells and discussed by RonJeffries and others. I've refactored away a lot of the attributions but I hope I've left in the ideas. These rules are critical to ExtremeProgramming. I also see most of these rules as valuable for any SoftwareDevelopment project. -- BenAveling

The point of the rules isn't to control what we do, it is to inform us how to do it. It's to remind us of the best known way to do things, and to make us aware when we're out on a limb.

These rules exist because they keep the code base clean. They require discipline and they repay that discipline many times over. They require effort in the same way that SharpenTheSaw requires effort. It may seem easier to just start cutting but it isn't. The nature of ExtremeProgramming is that breaking these rules costs more than it saves.

ExtremeLifeCycle

Customers create UserStories.
The PlanningGame is used for scheduling.
There will be an IterationPlanning meeting at the beginning of each iteration
There will be a StandUpMeeting every morning.

ExtremeCoding

Code may not be released unless it:

is formatted to agreed CodingConventions (Kent Beck's SmalltalkBestPracticePatterns is suggested.)
has been coded by PairProgramming.
has UnitTests
has passed all UnitTests at 100%.
has been integrated with the latest base-line. (A SingleReleasePoint is recommended.)

Code may not be released if it

is too complex.
Adds Functionality Early (does not DoTheSimplestThingThatCouldPossiblyWork)

Code which breaks these rules must be backed out and redone.

ExtremeDiscipline (Not so much discipline as a change in attitude.)

Developers must

Customers must

Translate UserStories into scenarios and test data for AcceptanceTests.
Review AcceptanceTests results and make the go/nogo decision before production release.
Be available to discuss UserStories in detail with developers.
Make decisions about scope and priority during the PlanningGame.

Following these core rules allows a lot of the traditional error prevention rules of HeavyWeightMethodologies? to be discarded. Without them the code base is not reliable enough to allow for IterativeDevelopment. Instead, PhoneBooks? of formal requirements, design and test documentation are needed, at far greater cost in time and effort. When you say, "I need to break this rule" you might as well be saying "Let's deliver the software late this time!"

You can try out some stuff on your own, but you can not release it. You must throw it away and start over. You might think this would be a waste, but it is not. The quality of the code is much better than your very best work going it alone and we must not forget the proverb: Anything you did yesterday you can do over again today in 15 minutes, and it will be better.

ExtremeLifeCycle

The PlanningGame must be used because

it provides management the schedule predictions they need
it provides buy-in from both Business and Developers
it produces parcels of work that are the right size for XP; not too big, not too small
it gives a handle for tracking progress which keeps management calm

There must be a meeting at the beginning of each iteration because

it keeps the schedule achievable
it keeps developers committed
it tells the developers what needs to be done
it tells the customers what will be done
it provides the baseline of estimates that allow prediction of when the entire release will be done

A StandUpMeeting is held each morning where you convey only the problems and solutions of the previous day. No discussion, those happen after the meeting. This keeps the team from being surprised by what the rest of the team is doing. The overhead of the time taken for meetings is more than paid for by time saved in not duplicating work, keeping everyone working on the same thing and being able to leverage each others knowledge.

ExtremeCoding

All code released to the team is coded by PairProgramming because

the reduced chance of making mistakes more than pays for apparent duplication of effort.
it keeps people focused on the work they are doing
it helps skills transfer
it avoids having only person who knows why something was done or how it works.

All code released to the team has UnitTests because it is essential for CleanCode. UnitTests aren't up front effort at all. You get to required quality faster with UnitTests than without. You get the confidence to RefactorMercilessly with UnitTests. You have to RefactorMercilessly so that DoTheSimplestThingThatCouldPossiblyWork and YouArentGonnaNeedIt will work.

All code released to the team has to have passed 100% of UnitTests because it is essential for CleanCode.

All code is released at the SingleReleasePoint because it is good for CleanCode.

ExtremeDiscipline

AcceptanceTests are run at least daily, or overnight, to be sure that the whole system works at all times, and that working code hasn't broken other code elsewhere. ChryslerComprehensiveCompensation ran them daily. If you wait a week, you don't find out for a week. The acceptance tests do not necessarily have to run at 100% if you have added tests for functionality not implemented or you have not yet addressed problems that rarely occur. It is however, the customer who gets to decide what score on the acceptance tests is approved for production release.

When a bug is found a UnitTest or AcceptanceTest is added or extended to catch it should it come back because it is essential for CleanCode.

Never add functionality early because in all likelihood, YouArentGonnaNeedIt and it makes your code larger. Thus maintenance costs increase. Also, IMHO, unused code means untested code which means bugs show up. Keeping code simple means small means CleanCode.

RefactorMercilessly because CleanCode means a reduced chance of making mistakes later and more than pays for the up front effort and the increased chance of making mistakes now. Refactoring is about quality, flexibility, and development speed which come from reduced fear.

ContinuousIntegration and ReleaseOften because CleanCode more than pays for the up front effort. The longer you wait between integrations/releases, the more integration you have to do, especially with CollectiveCodeOwnership (another rule). So don't wait.''

Some other local rules that could be appropriate are

All released versions are saved in a binder. VcapsProject local rule.
No newspapers allowed. C3 local rule.

All released versions are archived because if anything goes wrong you want to be recreate as closely as possible the customers set-up. (Either in binders, floppy disk, or CDs.)

C3 found that when people brought in newspapers, a lot of time was spent reading and discussing them, by people who would otherwise not have wasted that time. So we decided "no newspapers". This has nothing to do with RonJeffries' statement that "Once in a while I have to whack someone with the rolled-up newspaper to get them to behave. ... We've seen no negative effects."

Also, do you want to add that work must start at 9 and must end at 5? Given the reliance of being able to call a meeting if an exception occurs it seems dangerous to allow pairs to keep working once everyone else goes home.

No, because if a pair needs a meeting and can't have it, they'll wait until they can.

All of these rules are good things, but what about 'BusinessReality?'? Am I the only one who thinks that doing things right sometimes takes a priority to doing things now? Am I the only one who would like to add a rule that says "If you do break any of these rules then you must make sure that the rest of the team knows", or have other people found that you really can stop people breaking rules? Maybe I just need a larger NewsPaper?

When you get into it you don't feel like it is up front effort, it seems to take less. The pieces of the puzzle come together and the big picture is revealed; you feel like you are getting huge amounts of work done for little effort.

Large portions of functionality are designed using CrcCards that refers to anything which requires forethought, affects lots of the system or that the ProgrammingPair? does not have sufficient resource to design alone. Small enough pieces just get added without fuss, the design grows organically. You can generally trust people to tell them apart and there is indeed some gray area where either way is fine. XP projects have a different feel to them in that it is acceptable to stand up and say "I don't know how to do this. Can we get some cards?"

Q Why specify only code "released to the team"? Is SoloProgramming ever permitted? What if one half of a pair is absent? You can try out some stuff on your own, but you can not release it. You must throw it away and start over as a pair. You might think this would be a waste, but it is not. The quality of the code is much better than your very best work going it alone and we must not forget the proverb: Anything you did yesterday you can do over again today in 15 minutes, and it will be better.

Q. What if the tester knows why the test failed? Then the tester fixes it. Many of the rules have gray areas and are OK that way, this rule does not. If you allow UnitTests to fail you put into motion an avalanche of bugs that you will not have time in your schedule to repair later.

Not sure binders are the best way to go. I'd prefer floppy disk or CDs. This is a local rule created in response to needing to have an audit trail outside of the code repository (EnvyDeveloper). The simplest thing that could possibly work was chosen. We noticed that when a developer went to release some code a sheet of paper with the names of the classes and their versions was carried to the SingleReleasePoint. We had the developers drop said sheet of paper onto a pile. Every so often the manager would collect them, punch three holes into them, and put them into a binder. The audit trail showed everything our management wanted to see, does not require EnvyDeveloper knowledge to view, and costs no additional effort.

The VcapsProject ran AcceptanceTests right along with the UnitTests every time someone wanted to release some code. We were fortunate to have an acceptance test suite that ran very fast. That's not luck

do you want to add that work must start at 9 and must end at 5? Flextime seems to be OK. We could add the rule no overtime, but not performing HeroicProgramming is more of the attitude adjustment I was referring to.

but what about business 'reality'? The business reality is that XP and its rules will help you be much more productive. Breaking the rules will slow you down. When you say, "I need to break this rule" you might as well be saying "Let's deliver the software late this time!" -- DonWells

When you don't want to follow the rules you must ask your programming partner to explain them to you.

People break the rules all the time. It's just that it is not OK to break them. They get broken through mistakes and carelessness, because we're human. (If they are broken through unwillingness to play by the rules, IMO the individual should leave the team. (StBenedictsRule)

I notice that a certain someone has replaced "code may not be released if it was HardToWrite" with "... if it is too complex". I acknowledge your superior experience, but for me, HardToWrite is easier to recognise than too complex. On the other paw, I guess HardToWrite code is always TooComplex, while too complex code may not have been HardToWrite. -- BenAveling

I have seen too many programmers with eyes all red, heads bowed down from exertion trying to stamp out that last bug. To any observer it is obvious they are trying too hard. To them they are focused and do not notice. Having a PairProgramming partner helps. What we must worry about is the complexity issue. Complex code is often the result of implementing the first thing that comes to mind, then trying to extend it without refactoring or backing it out and trying something else. Simple requires refactoring and thinking and can actually be much harder to write than complex. -- DonWells

I agree with you on complex code. But I'm not sure I'm convinced that simple code can be hard to write. So long as it's kept simple, doing the RightThing should be, well, simple. It can be difficult to find the RightWay? to do it, but once the right way is found - the writing should come naturally, shouldn't it?

Perhaps the question I should ask is 'Which is danger sign is easier to notice, complexity or hardness?' Doesn't everybody think their own code is simple, at the time? -- BA

It is perception. If you could go from no code to simple code without a single misstep it would be very easy. That is not, in my experience, how simple comes into being. You must write automated UnitTests. You must try a few ideas and back up. You might need to get a few people together for CrcCards. Then try a few more ideas and back up some more. Then you proceed down a path that seems good. As you add more functionality you realize it is not the simplest thing. You stop and refactor. Then add some more and refactor some more. It takes persistence, forethought, and lots of ideas, which is the hard part. In retrospect, when you look at the finished product it does seem easy and clean, but it takes real work to get there.

On the other hand hacking something together is easy. You just code it up. No tests, no thinking, no starting over, no refactoring. Just finish it. The code will be complex, difficult to understand, and hard to get running correctly, but you are done.

I might spend exactly the same amount of time in either approach. But the perception is that the time I spend after announcing "I am done let's see if it works" belongs to some other phase. This gives us the feeling that hacking something together was easy.

I myself like to put lots of good ideas into the code. I also like to write UnitTests as I go. So for me I notice complex more than hard. -- DonWells

CategoryExtremeProgramming CategoryCodingConventions