I was exchanging tweets today with Liam on how to decide when to use private methods and when to put the logic in a new class. This got me thinking about rules, or at least, rules as applied to software development.

I love rules. I’m a rules addict. I find them strangely liberating; they restrict my options so that I can better focus on the creative aspect of whatever I’m doing. They seem to promise repeatability, predictability, and a degree of mechanical perfection that just needs to be nudged together by the developer.

Luckily for me there’s no shortage of rules. There’s SOLID, the 4 rules of simple design, DRY, Tell Don’t Ask and a whole bunch of step-by-step patterns and refactorings to mindlessly apply. ;)

Of course, it’s never quite that simple. Rules should come with a disclaimer, WARNING: Some assembly required.

No matter how many books I read, how many blogs I subscribe to, or how many patterns I memorised, a nice design never really seemed to naturally emerge from all that knowledge. So I tried quizzing experts on the rules they use. And pretty much without fail the answer was “it depends”. You give them a specific case, they give you an answer. You ask for a rule, and they tend to reply with words like “generally” and “favour”, not a specific procedure.

At a course a few years back I even quizzed the instructor until I managed to distil the procedure for getting beautiful designs from BDD. The instructor himself couldn’t explain the procedure, as he said much of the decisions are based on context developed from experience. Of course, that didn’t stop me trying to get to the rules at the heart of it. Nor did those rules assure my success at producing good designs.

Rules are the question, not the answer

Much as I generally dislike some of the grandiose metaphors that are typically attributed to software development by software developers, one that sticks out as quite relevant here is the Japanese martial art concept of Shu Ha Ri, which describes the three stages of learning required to master a discipline. (At least as I understand it. Please correct any egregious errors I make :))

The first stage, Shu, is all about rules. The beginner memorises the rules and applies them dogmatically. They may not see opportunities, or be able to take advantage of them, because they are sticking to the rigid forms they are learning.

The second stage, Ha, is when the beginner gains enough experience and has internalised the rules enough to start pondering the reasons behind the rules. They slowly begin straying from the rules as they start to notice the shortcomings when applying them to the myriad of situations the world throws at them. They also start to gain a better sense of appraising the relative success or failure of these experiments, and so start to apply rules on a case-by-case basis.

The final stage, Ri, is when the practitioner has risen above the rules. Every situation is dealt with on its merits. An observer may notice many elements of the rules in action, but the practitioner is merely doing what is required of the situation as governed by their experience; the context they have built up by applying and deviating from the rules.

While all this may seem a little twee, I can’t count the large number of times I have talked to people that really seem to know their stuff, and found they seem to have this uncanny knack of seeing straight to the heart of a problem and solving it in an elegant, seemingly effortless way. I can see many of the rules present in their approach, yet their solution never seems to be one I could simply derive by applying the rules or a specific formula. In hindsight, the solution tends to seem obvious; but never before I’ve seen it.

This has led me to believe that rules are the question, not the answer. They are what starts us on a path of enlightenment. It is only once we have memorised the rules and start noticing their limitations that we start asking ourselves why the rules are there and how they work. Once we start this questioning, we start gaining some mastery of the discipline. And it is only after we no longer need the rules that we are truly proficient, and we have uncovered the answer of how to write good software.

And, as many consultants will tell you, that answer is “it depends”. ;)

So now what?

Well, I’m trying to break my rules addiction. I like to think I’ve spent way too much time in the Shu phase due to it’s inherent safety (rather than as the result of fundamental incompetence), and that it’s time to start looking past the safe-haven of those rules. More than anything I think this comes down to writing loads of code, trying out new approaches, taking risks and questioning the meanings and motivations behind the rules.

How much time do you spend looking for rules on how to develop software right? If the answer is “lots”, maybe it’s time to let go of them?