Rules are important—they exist for a reason. Yet rules can’t anticipate all situations. When established conventions thwart your attempts to succeed, it’s time to break the rules.
How do you know when to break the rules? First, you need to understand them and their reasons for existing. That comes with experience. Once you understand the rules, exercise pragmatic idealism: establish an underlying set of ideals—such as the agile principles—based on practical results. Embrace your ideals, but ground them in pragmatism. For example, “We want to avoid integration hell” is a pragmatic result that leads to the ideal of “We will never check in code that doesn’t build or pass its tests.”
With the guidance of your principles, question existing conventions. Ask yourself, “Why do we follow this rule? Do we really need it?” Modify, work around, or break the rules that prevent you from achieving success.
Remember, though, that organizational support is central to success. If you break a rule, you might step on someone’s toes. Be prepared to explain your experiment. You’ll find it’s easier to get away with breaking rules when you’ve demonstrated that you’re trustworthy and effective.
Rule-breaking exists more in XP folklore than in XP practices. For example, early XP teams told stories of coming in to work on a weekend to dismantle cubicle walls, assuming that it would be easier to ask forgiveness than permission. Ron Jeffries, one of XP’s earliest proponents, is famous for saying, “They’re just rules”[58] in regard to the XP practices. He later clarified his statement:
They’re not rules, OK? They’re techniques. They’re tools we apply. They’re habits. They’re practices—things we practice.... They are, however, darn good things to know how to do, and do well.[†]
One of the seemingly inviolate rules of XP is that you always keep code quality high. It’s even an agile principle (see Eliminate Technical Debt” in Chapter 15). Yet even this rule is just a rule.
As cofounder of a brand-new startup, I had an opportunity to show our software at an industry conference. We had a spike solution (see Spike Solutions” in Chapter 9) that demonstrated some concepts of our software, but it had no tests. We had four weeks to produce a compelling demo.
The right thing to do would have been to redevelop the spike using proper test-driven development. In another situation, I would have done so. Yet in this case, my partner wasn’t as familiar with TDD as I was. I had other time commitments and couldn’t do much development work. Our choices were for me to forgo my other commitments and use TDD, introduce technical debt by developing the spike, or have no demo for the conference.
We chose to develop the spike. Breaking the rules didn’t bother us as much as the fact that developing the spike would incur large amounts of technical debt, but the trade-off seemed worthwhile. We created a great demo to show, and the product was a big hit at the conference. Then we came home and felt the pain of our decision. Four weeks of accumulated technical debt stalled our little startup for almost three months. That’s a long time.
Still, breaking the rules was the right decision for us under the circumstances. The buzz we generated around our product made the cost of technical debt worthwhile. The key to our success was that we carefully and knowledgeably broke a rule to achieve a specific purpose. We were also lucky. None of our competitors introduced a similar feature in the several months that we spent paying down our debt.
[58] “They’re just rules!”, http://www.xprogramming.com/Practices/justrule.htm.
[†] “I was wrong. They’re not rules!”, http://www.xprogramming.com/xpmag/jatNotRules.htm.