Theyre Just Rules

If a rule isn't working, the team can remove it from the rule list.

Elizabeth: You're pirates! Hang the code, and hang the rules. They're more like guidelines, anyway. --PiratesOfTheCaribbean

This does not mean that an individual can disregard a rule if s/he thinks it isn't worth following. The team can change 'em, but you can't break 'em.

On C3, a team releasing software discovered that two (of 30,000) UnitTests failed. On examination they found that the Sybase server had not responded, and concluded that it was down. They assumed that it would come back up and the tests would work again. The word that this was the case "got around", so that a number of teams released their code with these tests failing.

Someone who hadn't heard the word looked into the problem. Turns out that the address of the Sybase server had been permanently changed. If the code had been pushed to the production system, production would have gone down.

A big part of XP itself is to change itself. If you find yourself tempted to break a rule then you and the other developers need to have a meeting to discuss why the XP process isn't working and then change it. Fix it before it becomes a problem and everyone is breaking the rules.

-- Extract of discussion between RonJeffries, DonWells and BenAveling who has since refactored this mercilessly and moved the bulk of it to ExtremeRules (but still needs to refactor with ItsJustaRule)

http://www.xprogramming.com/Practices/justrule.htm

Aren't rules made to be broken?

"Rules are meant to be made, followed, and broken." --JaneRoberts

See ExtremeProgrammingCorePractices and TheyreJustRules.

Related to ThreeLevelsOfAudience, ShuHaRi

Eager Neophyte: But, shouldn't we add UnitTests to this disgusting hairy spike we just researched?

[RefactorMe:

Mentoring Pair: Forget it. Everything else has tests. We spent most of our time on this task researching the library, and we only ended up with 11 lines of code. We cou'dna tested it first because we didn't know how the library worked yet. When we bond it to the real program we'll notice there are no tests yet.

Eager Neophyte: But but but --

Coach: I have a better way to say it. "They are just rules".

Following the rules builds a climate and system, but the latter is on the CriticalPath. Discipline is not an end it is only a means to an end.

This smells like ItsJustaRule. In this case the Mentor has not explained well and the coach is wrong. Coding a spike solution doesn't require UnitTests in advance. But the UnitTests have to be written before the learning from the spike is used to create production code.

Remember, mentors aren't masters.

ColorOutsideTheLines doesn't apply to the ExtremeRules, or to any other rules that the team as a whole has chosen. You can (collectively) change the rules, but don't (individually) break them.

Remember, masters aren't mentors.

I guess I fit in the class with Eager Neophyte. Isn't the intent of the spike solution intended to prove something? Doesn't the UnitTest specify what is to be proved? What have you accomplished with the spike solution if you cannot show that it solved some problem?

As I understand it, a spike is a means of learning something that you didn't know before (maybe to provide a better estimate to a story than "dunno - I haven't used that scary technology before"). So all you take away with you is your new knowledge. -- DanNorth

Let me propose:

Rules are meant to be followed until a clear alternative that works better is found.

In other words, don't break a rule without a solid justification.

Maybe they should be called GuideLines? then instead of rules.

"Rules are for the guidance of wise men and the obedience of fools." --DouglasBader

When I was a kid, I found an encyclopedia in the school library where you couldn't read the letter range for each volume - A, B, C, etc. The librarians had taped the book's Dewey Decimal System label over the letters. I asked a librarian why they did that, and she officiously responded "Oh, that's because our State Regulations say we have to put the sticker the same distance up on each book, 2 inches!"

Of course I didn't respond. By that age I knew better than to engage adults who actually needed the explanation "That regulation exists so you can scan the DDS numbers, which are irrelevant on an encyclopedia, and you could have just moved the stickers up, to preserve eye-scan at 2 inches, duh!" --PhlIp

As long as we're throwing quotes around,

"Look, that's why there's rules, understand? So that you think before you break 'em." -- (Terry Pratchett, Thief of Time)

That's about as much as you can say about most rules, guidelines, style manuals, etc. in the programming world. If a rule inconveniences you, and you want to break it, do not do it. Consider why the rule was exists! Understand what could happen if it is broken! Most importantly, remember who enforces the rule, assuming that it is enforced at all.

Then break it.

Also:

"Perdita thought that not obeying rules was somehow cool. Agnes thought that rules like 'Don't fall into this huge pit of spikes' were there for a purpose." -- (Terry Pratchett, Carpe Jugulum)

CategoryCodingConventions