Quality Vs Prescription Rules

First attempt

Some software development rules of thumb seem to be "quality" rules. Applied to two pieces of code, a "quality" rule will tell you which is better. Applied to one piece of code, a "quality" rule is too vague - it won't tell you anything. Sometimes, "quality" rules are named for mnemonic purposes (i.e. catchy) so they can't always be taken literally. Example: CodeWithoutExceptions is a "quality" rule that says the code with fewer exceptions is better.

Some rules of thumb seem to be "prescription" rules. They tell you how to achieve quality. Applying a "prescription" rule to one piece of code helps you improve that one piece of code. Example: DontConvertExceptions? is a "prescription". Following it will help you achieve fewer exceptions.

Both types of rules seem to be helpful. Although maybe there is a grayscale between "quality" rules and "prescription" rules. Maybe rules tend toward being quality rules or tend toward being prescription rules.

Maybe listing useful "prescription" rules as part of the description of a "quality" rule would be helpful. Hmm. This is a little too black and white. Maybe just listing related rules as part of a rule description would be helpful.

It reads to me that most of the XP rules are prescription rules. I think CodeWithoutExceptions is a pretty clear command, or prescription. It would be based on a quality rule along the lines of "exceptions make code more difficult to maintain and extend", i.e., in general, code without exceptions is superior to code with exceptions, along the dimension of readability, comprehension, etc., as needed for maintenance and extension. I see the same with DoTheSimplestThingThatCouldPossiblyWork. The trouble with that one is that any two engineers I have ever gotten to sit down together think that different things are simplest, and the argument starts from there. But the XP rule is clearly prescriptive. Ditto WorstThingsFirst (put three people in a room and there will be 1-4 opinions about what is worst - but it is clearly prescriptive), and OnceAndOnlyOnce, and so on.

There is a quality assertion behind each of these directives, and that is part of what makes XP so interesting - they are announcing preselected quality preferences out loud, and announcing directives that should steer people toward the preferred quality measure.

Not surprisingly, other people (a) disagree about the quality preferences, (b) disagree that the directives lead to the quality preferences, and / or (c) don't understand the directives. I tend to belong to class (c) (WorstThingsFirst sounds great, but could mean anything, Do The Simplest Thing is up for grabs as to meaning), in those few cases where I disagree with XP. --AlistairCockburn

Hmmm. You have a valid point about all rules being prescriptive (and therefore applicable to one piece of code). I’m going to try again. --StanSilver

Second attempt

Software development rules of thumb are often articulated in short phrases. These phrases serve three purposes:

Easy to remember and say
Indicate some quality gradient that has been found useful ?"a is better than b"
Indicate steps to take to move along the quality gradient that have been found to work

A phrase plus a page of explanation will hopefully accomplish all three purposes. A phrase by itself may compromise among the three purposes. Often the last suffers.

Thus, if you can remember a rule of thumb and apply the rule to a single piece of code, the rule may only tell you in which direction (e.g. more of this, less of that) to search for better code. The rule may not tell you steps to take to move in that direction.

Knowing a direction in which to improve code, without knowing the steps to take, is still useful. A common use of such a rule is to do (somewhat directed) trial and error to come up with different pieces of code, and use the rule to compare the pieces to determine which is better. Repeat until you can’t make further progress.

This is still missing something along the lines of

Also, if the rule doesn't define it's quality gradient enough (e.g. what exactly is simplest, what exactly is worst) it is up to the user of the rule to use their own definition.

I got more value out of the first version. I find this quite an insightful page.

I think some of the XP slogans are really quality rules disguised as prescriptive rules. Further: they are meta-quality rules. That is, they are rules which compare two qualities and say which matters more.

For example, DoTheSimplestThingThatCouldPossiblyWork isn't just saying that other things being equal you should chose the simpler code. It is saying you should do that even when other things are unequal. It is saying that efficiency, ability to cope with anticipated requirements etc are less important than simplicity -- DaveHarris

Very much agree. This is a thought-provoking page!

Regarding Dave's remarks just above, mostly yes. The "Simplest" rule is saying that when you don't have an actual requirement to the contrary, simplicity is more important than anything else. There might be an actual requirement for a specific performance, and a measurement to show that the code in question was the problem. In the case of anticipated future requirements, we say simplicity (and refactoring) is more important.

Or perhaps we are saying that the best way to anticipate needs for performance and future change is to write simple, well-factored code. Dave's dern near the mark, for sure. --rj

I find DoTheSimplestThingThatCouldPossiblyWork is also a generative rule. If I am stuck for a way to proceed, the question "what is the simplest thing which has a chance of passing?" helps get me going. It generates solutions to a greater extend than CodeWithoutExceptions.

I think a better terminology than "Quality Rules" and "Prescriptive Rules" would be "Evaluation Guidelines" and "Procedures." This adds clarity to what is being discussed.